[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