[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