Opened 6 months ago
Last modified 12 days ago
#7057 new enhancement
Make / plugin API for closed plugins that are no longer available
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | API | Keywords: | needs-patch dev-feedback |
Cc: |
Description
when we visit for instance https://wordpress.org/plugins/delete-all-comments/#description
It will tell you this "This plugin has been closed and is no longer available for download."
However ..
visiting the wordpress.org API -> https://api.wordpress.org/plugins/info/1.0/delete-all-comments/
shows
"Plugin not found."
Why not
1) at least show a message here that is the same as on the plugin website ?
-> Task for Make
- This ticket
2) also show this in WP->tools and/or WP->plugins and/or WP->dashboard
-> Task for Core (plugins/API).
Because .. right now , if you have such a plugin installed, and you do not visit the wordpress.org page for that plugin. You have *no* knowledge of this data/info at all.
- Ticket available: https://core.trac.wordpress.org/ticket/30465
Change History (8)
This ticket was mentioned in Slack in #meta by oglekler. View the logs.
4 months ago
#3
in reply to:
↑ 1
@
3 months ago
- Keywords dev-feedback added
- Type changed from defect (bug) to enhancement
Replying to dd32:
The
1.0
APIs won't change in their behaviour, although the latest version variant possibly could.
For the core ticket, this would likely be best implemented via the
update-check
API rather than through theinfo
endpoints.
I'd love to put some work in this, but the update-check
API seems to be closed source :-/
#4
@
3 months ago
Maybe also take a view at the video: https://www.youtube.com/live/CkVOyXBP970?feature=share&t=20854 where @oliversild talked about this issue at WCEU 2023
The idea is not only to display "This plugin has been closed and is no longer available for download." etc., but in future maybe also other maintenance informations like author submitted EOL date, keep that in mind while designing :)
This ticket was mentioned in Slack in #meta by michi91. View the logs.
3 months ago
#7
follow-up:
↓ 8
@
7 weeks ago
@dd32 What has historically been the process by which that API is updated and versioned?
I assume the first steps here would be to outline what changes would be required to the result schema. At minimum, I think adding a status
field that is simply text would be a good start. But that could also be an array including some kind of status shorthand/slug, a human-readable message, and an effective date if applicable.
Without more information about how the back end of the plugin repository and existing API work, it's hard to propose anything firmer, and nothing on which to base a PR.
#8
in reply to:
↑ 7
@
12 days ago
Replying to eclev91:
@dd32 What has historically been the process by which that API is updated and versioned?
The version only really changes when the operation of the API changes in a significant way, which would be otherwise improperly handled by WordPress core (Ignoring 3rd-party clients for the most part).
This probably wouldn't justify a version bump, if it would be an additional field being present within the JSON returned.
Without more information about how the back end of the plugin repository and existing API work, it's hard to propose anything firmer, and nothing on which to base a PR.
The best way forward for this ticket from someone without access to the code in question, would be to describe the suggested alteration to the API output, for example, something like:
Currently: { "some-plugin.php": { "error": "Slug not found." } } Proposed: `{ "some-plugin.php": { "error": "Unavailable", "code": "closed-author-request", "reason": "Closed by author request" } }
(Those are just examples, not the actual existing API responses)
The
1.0
APIs won't change in their behaviour, although the latest version variant possibly could.For the core ticket, this would likely be best implemented via the
update-check
API rather than through theinfo
endpoints.