Making WordPress.org

Opened 2 years ago

Last modified 2 years ago

#6292 new enhancement

Surface last supported plugin/theme update if latest version(s) not supported

Reported by: flixos90's profile flixos90 Owned by:
Milestone: Priority: normal
Component: API Keywords: needs-patch
Cc:

Description

WordPress core has for a while now prevented updates to plugins for which the minimum WordPress version or PHP version is not supported (see e.g. https://core.trac.wordpress.org/ticket/43987).

While this works reliably, there is the potential of an undesirable situation with that approach though: Since wordpress.org currently only surfaces the very latest update to a WordPress site when it queries for updates, there is no way for the site to get the latest supported version of the plugin if the site does not support the very latest version of the plugin.

Let me clarify by example:

  • Let's say my site is on PHP 7.0.
  • Let's say I use "Super Plugin" version 1.0. I haven't updated in a while, and numerous versions have been released since then.
  • In the meantime, more versions of the plugin, e.g. 1.1, 1.2, 1.3, and so on have been released.
  • At some point, the developers of "Super Plugin" bump the minimum required PHP version to 7.2, as part of the 2.0 plugin release.
  • I now want to update again. But WordPress will just show me version 2.0 of the plugin and tell me that I cannot update to it because my site's PHP version is insufficient.
  • A much nicer experience for the user (and also better for security and other related reasons) would be that WordPress would show the last supported version of the plugin (e.g. 1.9 in the example above) and allow the user to update to that version. This way at least they are up to date as much as possible with their environment.

A potential solution for this could be:

  • WordPress core includes WP and PHP version information of the site in the request for plugin updates (similar for core and theme updates of course).
  • The wordpress.org API then does the following:
    • If the most recent update is not supported by the site, go further back to see whether there is another update relevant for the site that it does support.
    • If so, surface the most recent supported update to the site.
    • If not, continue surfacing the latest update even though it is unsupported. It's good to keep nagging site owners to update their versions to eventually update to that plugin version.

With an enhancement like the above, we would be able to improve the experience here without changing any of the UI, just by slightly more intelligent logic in WordPress core and the wordpress.org API.

I acknowledge that not updating core, a plugin, or a theme for a while is not a great idea in itself, but still, it would be better to still help out these sites with the latest supported version when we can.

Change History (4)

#1 @flixos90
2 years ago

@SergeyBiryukov Curious what you think about this. Would this be relatively straightforward to implement in the plugin/theme updates API? Or is there a complexity there that I might have missed?

Of course if we went with my proposed approach we would also need a related WordPress core enhancement to send the necessary WP and PHP version information (which I believe are already sent in some API requests to wordpress.org anyway), but let's first discuss the feasibility here.

#2 @dd32
2 years ago

Would this be relatively straightforward to implement in the plugin/theme updates API? Or is there a complexity there that I might have missed?

The API's and the Directories themselves are built with the notion that there's only the latest release. There's very limited support for older releases. This is especially more true for the Plugin Directory than the Theme Directory.

This is not a simple change, nor one that is likely to be achieved anytime soon IMHO.

#3 @dd32
2 years ago

See Also: #3236

#4 @schlessera
2 years ago

Just for reference: This is currently breaking lots of tests for WP-CLI on WP 3.7 because of the recent update to the WordPress Importer plugin.

See https://github.com/wp-cli/extension-command/issues/333.

Note: See TracTickets for help on using tickets.