[wp-trac] [WordPress Trac] #53333: Better handling for forced plugin autoupdates

[WordPress Trac]

#53333: Better handling for forced plugin autoupdates
-----------------------------+-----------------------------
 Reporter:  dd32             |      Owner:  (none)
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Upgrade/Install  |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53333>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform