[wp-trac] [WordPress Trac] #48850: Plugins Screen: introduce "Automatic updates" column / option
WordPress Trac
noreply at wordpress.org
Tue Feb 11 02:29:53 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 |
PR Number: |
-------------------------------------+-------------------------------------
Comment (by pento):
Reading over this ticket, I'm seeing a lot of uncertainty over how the
`WP_AUTO_UPDATE_PLUGINS/THEMES` constants should behave, which appears to
be driven by there not being a defined use case: rather, everyone has a
different idea of how they should work, to fit how they can imagine them
being used.
I think it's worth considering the history here: The
`AUTOMATIC_UPDATER_DISABLED` and `WP_AUTO_UPDATE_CORE` constants were
included back when auto updates were first introduced to WordPress. They
were intended to be a hard short circuit for a feature that had not yet
been proven in an actual release. Today, auto updates have been running in
production on millions of sites for 6+ years, including many sites that
enable auto updates for Core, plugins, and themes. To me, this says that
there's no longer a need for an additional short circuit, as it would just
be duplicating the behaviour of the existing filters, and the UI proposed
in this ticket.
So, rather than prematurely causing complications, I would advise not
adding these constants.
Given that the UI will only be visible to admins (or site admins on MS), I
don't think there needs to be a specific option to hide the UI, either.
This isn't ruling them out in the future, but my suggestion is to release
this UI, then see if there's significant demand for behaviour that could
only be covered by these constants. The only such use case that has come
up in this ticket is the possibility of malicious plugins quietly
overriding the setting, which I agree is a red herring.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/48850#comment:100>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list