Make / plugin API for closed plugins that are no longer available

[ramon fincken]

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

[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 the info endpoints.

[Michi91]

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 the info endpoints.

I'd love to put some work in this, but the update-check API seems to be closed source :-/

[Michi91]

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 :)

[Michi91]

Related: ​#wp49151 ​#wp30465

[eclev91]

@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.

[dd32]

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)

[masteradhoc]

I'd love to get this further. Currently this is a huge security issue as a user you dont recognize if a plugin is closed / not updated for ages / or if it just doesnt have any update available.

WP really needs a pluginnotice for closed plugins to be sure people get aware of it asap.

[dd32]

#4977 was marked as a duplicate.

[dd32]

In 13620:

Plugin Directory: Expose the plugin closed status through the plugin_information API endpoint.

This only applies to v1.2+ clients, as v1.0/1.1 expect a null response for any error case.

See #7057.

[dd32]

Note: [13620] applies to the info endpoint, not the update-check API.

That requires a few more changes to make work; which is a followup commit.

[dd32]

In 13628:

Plugin Directory: API: Store the closed data in the update-check source table.

Note: This only makes it available to the API, doesn't currently output it.

See #7057.

[dd32]

#7621 was marked as a duplicate.

[eclev91]

What are the thoughts on, rather than replacing the existing API data for closed plugins, supplementing it and still making, for example, old versions available through the API. ​There are applications where being non-destructive here and continuing to supply download links for old versions, for example, is valuable.

[ramon fincken]

adding to a new version is absolutely fine :)

[dd32]

Replying to eclev91:

What are the thoughts on, rather than replacing the existing API data for closed plugins, supplementing it and still making, for example, old versions available through the API.

This isn't something that WordPress.org is going to add support for. When a plugin is closed we do not wish to serve any data about the plugin.

There is a third status for plugins (publish, disabled, closed), disabled which doesn't advertise a plugin (ie. acts like it's closed) but that serves updates. This is often used for plugins that get closed for security reasons, we wish to re-open it to push out an auto-update, but do not wish to host the plugin going forward.

Currently ZIPs are still accessible for closed plugins, but that will also change in the future.

Related: #5496 #7217

[dd32]

In 14152:

Plugin Directory: Standardise on the data exposed for closed plugins.

See #7057.

[dd32]

In 14153:

Plugin Directory: Resolve some closed plugins showing 'Last updated: 55 years ago'.

See #7057.

[dd32]

In 14154:

Plugin Directory: When the close date of a plugin is not known, use the last_updated data as the date instead.

Most of the plugins which are affected by this appear to have been closed before 2018, and so at this point it's better to just consistently return a date to simplify logic.

See #7057.

[dd32]

In 14155:

Plugin Directory: We don't need to return the closure reason label through the update api (we'll return the code), don't store it in the table.

See #7057.