Better handling for forced plugin autoupdates

[dd32]

When an auto-update for a plugin is forced from WordPress.org (for security purposes), and the update is not to the latest current release, we're forced to adjust the API response in a way which can confuse some WordPressers

For example, Let's say ACME Widget has released three major versions, 1.0, 2.0, 3.0 and a security vulnerability is found that allows an RCE attack. Since each version of the plugin is significantly different they release 1.1, 2.1, 3.1 and request the Plugins Security team to perform an autoupdate.

Currently, the flow is that a site with 1.0 installed is:

• Yesterday the UI showed an update to 3.0
• Today the UI shows an update available, 1.1 NOT 3.0
• If possible, the Auto Update will push the site from 1.0 => 1.1, and email the user about the update occurring.
• If not possible, the site will just show 1.1 as the latest release (Although WordPress.org will show 3.1)
• Once the site is running 1.1, they'll see an update to 3.1.

I would like to adjust this so that:

• The UI always shows the latest version, 3.1
• The autoupdate attempts to push the site to 1.1
• The site isn't forced to go 1.0 -> 1.1 -> 3.1 to upgrade manually, and can instead upgrade from 1.0 directly to 3.1

This causes confusion for some people when they receive an email saying a plugin was autoupdated, but it wasn't to the latest version of a plugin, and even more confusing when the latest release was a few days ago.

#51695 would be of benefit here too, as the email will then include a note that it was a security update.

The way I envision this happening, is adjusting the API response for plugins/themes.
For example, here's a current response:

{
  "plugins": {
    "acme/widgets.php": {
      "id": "w.org/plugins/acme-widgets",
      "slug": "acme-widgets",
      "plugin": "adme/widgets.php",
      "new_version": "1.1",
      "url": "https://wordpress.org/plugins/acme-widgets/",
      "package": "https://downloads.wordpress.org/plugin/acme-widgets.1.1.zip",
      "autoupdate": true,
   }
}

and here's what I'm thinking:

{
  "plugins": {
    "acme/widgets.php": {
      "id": "w.org/plugins/acme-widgets",
      "slug": "acme-widgets",
      "plugin": "adme/widgets.php",
      "new_version": "3.1",
      "url": "https://wordpress.org/plugins/acme-widgets/",
      "package": "https://downloads.wordpress.org/plugin/acme-widgets.3.1.zip",
      "upgrade_notice": "Fix a bug",
      "autoupdate": [ {
          "new_version": "1.1",
          "package": "https://downloads.wordpress.org/plugin/acme-widgets.1.1.zip",
          "upgrade_notice": "Security update, fix bugs",
      } ],
   }
}

Notes

• The additional data is minimal and not duplicating existing fields
• The plugins update API would need to be bumped to a 1.2 endpoint, to change the output based on the client revision.
• If the site has auto-updates enabled for the plugin, it'd attempt the 3.1 update rather than the minimal 1.1 first.
• The API response supports the ability to have multiple versions presented, but currently this is based on the assumption of a singular item, just a bit of future proofing.

An attached PR explores this idea, although will be pending implementation on WordPress.org prior to it being testable. I've got a draft 1.2 endpoint that works like this, and will follow up with that next week pending feedback from others.

Trac ticket: https://core.trac.wordpress.org/ticket/53333

[dd32]

An attached PR explores this idea, although will be pending implementation on WordPress.org prior to it being testable. I've got a draft 1.2 endpoint that works like this, and will follow up with that next week pending feedback from others.

Just noting that the /plugins/update-check/1.2/ API is now available for testing, if anyone wants to look into it.. but without an active auto-update in progress, it's hard to test it. I'll see if I can get a plugin setup that will have an auto-update available for testing.

As far as I can tell, although I've not tested it, this should work with any plugins which define a 3rd-party plugin update mechanism, as long as they intercept/alter the plugins/update-check/*/* requests or use the other core filters added for the Update URI headers.

This change should be made early in a release cycle, and not rushed.