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

WordPress Trac noreply at wordpress.org
Fri Feb 7 03:55:11 UTC 2020


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

 Replying to [comment:90 peterwilsoncc]:

 I spoke with @peterwilsoncc briefly today and concerns about malicious
 plugins can be considered out of scope for now.

 Updating the API to offer minor and patch versions is also out of scope
 and would require a much larger discussion involving the meta, plugin, and
 theme teams.

 > * If `WP_AUTO_UPDATE_PLUGINS === false`, `should_update_to_version()`
 should return early and never hit the filter. This will prevent developers
 overriding the site owner's hard coded choice.

 My intent in `should_update_to_version()` was to create a
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-core-upgrader.php#L272 flow similar to the one in the Core upgrader
 class]. That method has filters for different version types (minor, major,
 dev). But, not adding a filter to the new plugin
 `should_update_to_version()` will not prevent the scenario described here
 as the `auto_update_plugin` filter already exists and is currently the
 only way to enable auto-updates for a plugin or theme.

 > Generally, if `WP_AUTO_UPDATE_PLUGINS === false` and sites using version
 control then the auto-updates UI ought not be displayed.

 The way this works in my brain is:
 - `WP_AUTO_UPDATE_PLUGINS === false` hides the UI elements.
 - `WP_AUTO_UPDATE_PLUGINS === true` also hides the UI elements, but could
 (should?) mention that auto-updates for all plugins are turned on by the
 constant.

 @pbiron regarding the constants accepting an array of plugins, I think
 that I am against this. The point of the constant is to have an easy way
 to flag the feature on or off in a similar manner to how
 `WP_AUTO_UPDATE_CORE` works (`true` for all, `false` for none, or
 `minor`). Although it requires a little more code, I think that the
 recommendation should be to use a filter for adding specific plugins to
 the list allowed to auto-update.

 I am open to more thoughts on this implementation detail from others
 though.

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


More information about the wp-trac mailing list