[wp-trac] [WordPress Trac] #48850: Plugins Screen: introduce "Automatic updates" column / option

[WordPress Trac]

#48850: Plugins Screen: introduce "Automatic updates" column / option
-------------------------------------+-------------------------------------
 Reporter:  jeherve                  |       Owner:  audrasjb
     Type:  feature request          |      Status:  accepted
 Priority:  normal                   |   Milestone:  5.4
Component:  Plugins                  |     Version:  3.7
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  administration,
  has-screenshots dev-feedback       |  multisite
  needs-dev-note needs-design        |
-------------------------------------+-------------------------------------

Comment (by desrosj):

 [attachment:"48850.12.diff"] primarily overhauls how the auto-updates were
 triggered in the previous patches by moving that code into the auto-update
 classes. It should be just built in and not added with a filter. In
 summary:

 - UI related changes are not included so that direction can be finalized
 there.
 - If a plugin that is auto-updating is active, then the site is now
 entered into maintenance mode. Previously, this did not seem to be the
 case. After triggering an auto-update, I was able to trigger the WSOD
 protection screen, or cause the plugin to be disabled when visiting the
 plugin screen in the admin because of a PHP error. This should be
 prevented now. Note: it is a bit clunky in that the site will enter and
 leave maintenance mode before and after each active plugin is auto-
 updated.
 - A `Plugin_Updater::should_update_to_version()` method was added. This
 method is meant to have similar responsibilities to the one in the
 `Core_Upgrader` class. It will detect the constant or use the stored site
 option to determine if the current plugin should be auto-updated. It then
 passes the `$update` result through a general filter. In `Core_Upgrader`,
 the code goes a step further by determining whether the update being
 attempted is a major, minor, or development update and
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-core-upgrader.php#L337passes each type through its own filter]. By
 adding this method, it allows plugin auto-updates in the future to become
 more flexible based on the version being offered. Imagine being able to
 allow only `security` releases to be auto-updated for plugins. Minor/major
 was also mentioned above, but I don't think that is currently realistic
 because there is no standardized versioning for plugins. Authors are
 allowed to version however they please.
 - A `WP_Automatic_Updater::after_plugin_update()` method was added to
 perform any required actions after any plugins are auto-updated. This
 again is meant to be similar to the accompanying
 `WP_Automatic_Updater::after_core_update()` method, but perform actions
 specifically for plugins. Right now, it determines if there were any
 successfully updated plugins, any updates that failed, and then triggers
 an email. The accompanying core method tracks when emails are sent out, to
 whom, for which results (fail, pass, etc.), and for which versions. The
 same needs to be considered and added for plugins so that multiple emails
 are not sent for the same plugin updates (especially if a specific update
 fails multiple times).
 - `WP_Automatic_Updater::send_plugin_email()` was added to construct and
 send an email to the site owner when any plugins are successfully or
 unsuccessfully auto-updated. The tone of these emails needs to be
 reviewed. I tried to match the core update ones, but there is not "mixed"
 result for core updates. What guidance should we be giving in the mixed
 updates for plugins? Failed?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48850#comment:70>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform