Opened 5 years ago
Closed 5 years ago
#48850 closed feature request (fixed)
Plugins Screen: introduce "Automatic updates" column / option
Reported by: | jeherve | Owned by: | audrasjb |
---|---|---|---|
Milestone: | 5.5 | Priority: | normal |
Severity: | normal | Version: | 3.7 |
Component: | Plugins | Keywords: | has-patch has-screenshots |
Focuses: | administration, multisite | Cc: |
Description
WordPress 3.7 introduced us to automatic updates for Core, themes, plugins, and translations. It also brought us filters like auto_update_plugin
that allow site owners to automatically update specific plugins if they want to.
WordPress 5.1 went a step further with Fatal Error Protection, and 5.2 made managing any failures caused by broken plugins even easier with Recovery Mode.
At this point, I think it has become relatively safe for a site owner to use the auto_update_plugin
filter to enable autoupdates for any or all of their plugins. It removes one of the burdens of site management, and in case of failure (such as a plugin introducing a fatal error with an update) it is relatively easy to access the dashboard and remove the plugin.
All that said, I would like to suggest making plugin autoupdates even more mainstream by adding a new column to the Plugins screen, where one could toggle autoupdates on / off for just about any plugin.
Attachments (30)
Change History (136)
This ticket was mentioned in Slack in #core by noisysocks. View the logs.
5 years ago
#2
@
5 years ago
That is a very good way of adding auto updates for plugins! As one could then select the plugins that are most stable for auto updating.
I have earlier made this issue: #45783
It basically adds an auto updates section to the existing Dashboard -> Updates screen.
#3
@
5 years ago
Hi there,
I really love the proposed approach but I'd like to propose another way to handle this feature: as a very first step for allowing auto update management in WordPress Admin, we could also use the bulk edit selector.
Screenshot and patch (first workaround) coming below ⏬
#4
@
5 years ago
- Keywords has-patch needs-testing has-screenshots needs-design added
In 48850.diff
, as a first workaround and a proof of concept:
- Allow admins to enable/disable automatic updates by using the plugins bulk selector.
- Display admin notices when enabling/disabling auto updates on existing plugins.
- Display a text to show that selected plugins are now updating automatically.
- Store auto updated plugins in a site option.
- Make basic controls on the user’s capabilities
The nice point is that we don't add another column to the plugin table list, and the patch is pretty simple. It doesn't need AJAX and it doesn't add a lot of code to the existing codebase. But it will of course need some improvement: it's the first time I try to play with updates/autoupdates so I guess some parts of this patch are probably _doing_it_wrong
;-)
When testing this patch/workaround, please don't forget autoupdates are not running immediately (but twice a day, I believe).
Also adding needs-design
keyword as I guess it would be nice to add a dashicon or better wording/visual indications here and there :)
Cheers,
Jb
@
5 years ago
Move the "Automatic update activated" text in the plugin description column and add a dashicon
#5
@
5 years ago
- Keywords needs-design-feedback added; needs-design removed
In 48850.1.diff, I moved the text in the plugin description column and I added a dashicon.
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
5 years ago
#7
@
5 years ago
FWIW I like this second approach better. There is more space available in this location.
I haven't tested the patch but in a quick look there needs to be a the third parameter for in_array( needle, haystack, true )
.
#8
@
5 years ago
The Capture d’écran 2020-01-05 à 00.34.35.png looks really nice and clean without making a major change on the screen but I think that we also need a way to "sort" the auto-updated plugins as well similar to the Active / Inactive statuses.
Unfortunately on sites with a lot of plugins the list will eventually become a bit hectic to go through 1 by 1 trying to read a small message to see which plugin has auto-updates on or off.
Since this screen never used any type of sorting on the table itself we can follow the current convention and add 2 extra sorting links for "Auto-Updates On"/"Auto-Updates Off" (I'm not sure about the wording at all by the way :D ).
Any thoughts on this?
#9
@
5 years ago
48850.2.diff adds the strict in_array comparisons as @afragen mentioned and adjusts some minor CS fixes.
As well as introduces the 2 extra lists as "Auto updates on" "Auto updates off" as mentioned in my previous comment (8) for an easier test/look.
#10
@
5 years ago
Thanks @xkon, yes I think it's worth adding these 2 filters, this is a nice enhancement for sure!
#11
@
5 years ago
In 48850.3.diff
:
- Add autoupdate information to update-core.php screen (see screenshot above).
@
5 years ago
Plugins update screen: add time until the next scheduled update for plugins that have an available update.
@
5 years ago
update-core.php screen: add time until the next scheduled update for plugins that have an available update.
#13
@
5 years ago
In the last two screenshots (see above), I added the time until the system will perform the autoupdate.
Patch proposal coming later today.
@
5 years ago
Adds time before the next scheduled update in both update.php (plugins screen) and update-core.php (updates screen).
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
5 years ago
#16
@
5 years ago
I suggest changing from "Automatic update activated" to "Automatic update enabled" (or something similar) to avoid confusion with the "Activate/Deactivate" link below the plugin's name. The fact that both places use the verb "Activate" might make some users think that these two are related actions/labels.
Related to me previous point, is the "Bulk actions" dropdown the only place where I can activate/deactivate automatic updates for a plugin? I think that also having this setting near the label would make it more obvious, at least when one wants to make a change to just one plugin.
This ticket was mentioned in Slack in #core by francina. View the logs.
5 years ago
@
5 years ago
48850.5.diff : Replace Activate/Deactivate with Enable/Disable and add Enable/Disable Autoupdate action for each plugin in Plugins screen
@
5 years ago
Replace Activate/Deactivate with Enable/Disable and add Enable/Disable Autoupdate action for each plugin in Plugins screen
#18
@
5 years ago
Thanks for your feedback @nrqsnchz, that totally makes sense to me.
In 48850.5.diff
:
- Replace Activate/Deactivate with Enable/Disable
- Add individual Enable/Disable actions for each plugin
See also the related screenshot shared right above.
#20
@
5 years ago
@audrasjb is it possible to add some do_action
s after updating the options?
An example:
do_action( 'wp_autoupdated_plugins', $autoupdated_plugins )
Also, you'll maybe want to take into account multisite networks. I suggest using update_site_option
and get_site_option
so that auto-updates can occur on a network level as well.
#21
@
5 years ago
- Focuses multisite added
- Keywords dev-feedback added; 2nd-opinion needs-design-feedback removed
Thanks @ronalfy, I added support for multisite installations in 48850.diff
.
I think actions and filters should come in a second time, after a proper review of the existing patch.
Also removing design feedback as the Design team already provided their feedback on Slack.
This ticket was mentioned in Slack in #core-multisite by audrasjb. View the logs.
5 years ago
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
5 years ago
#25
@
5 years ago
Hey everyone,
here's some feedback regarding the enable/disable automatic updates action.
I see that you're going with the link below the description of the plugin.
I think, since every action regarding the plugin lives under the title, maybe we should think of a solution and keep all the actions together under the title. People are used to find actions there, so maybe we could use that to our advantage?
Also, although I love icons, no other plugin action has an icon, so that might be a consistency issue to think about.
#26
@
5 years ago
That's a great feature, good job 👏
I have read the patch, it seems pretty solid, good code.
#27
@
5 years ago
Latest 48850.6.diff seems to be throwing a couple of syntax errors for me, could someone else apply the patch as well for a cross-check :-) ?
#28
@
5 years ago
For some reason 2 of the } else {
seems to be causing these issues for me. Even PHPCS throws out warnings. Deleting and re-writing just the word else
resolves it 😂.
Do tell me if the latest works for you just in case it's something only with my setup. Seems really weird though and first time I see a char encoding issue like this to be honest.
Only 2 instances of the else
word are doing this.
Parse error: syntax error, unexpected '{' in D:\laragon\www\wp-core\src\wp-admin\plugins.php on line 190
And
PHP Parse error: syntax error, unexpected '{' in D:\laragon\www\wp-core\src\wp-admin\includes\update.php on line 493
Not sure yet if I should update the patch so just informing for now 🙂.
#29
@
5 years ago
I wasn't going crazy as it seems. Had a quick DM with @audrasjb and while viewing 48850.6.diff those else
didn't had spaces between curly braces on the right side but nbsp chars instead as it seems 🤷♂️. I accidentally saw it while viewing the diff and showing all spaces/tab chars also.
48850.7.diff adjusts those 2 and fixes these errors, nothing else was touched.
#30
@
5 years ago
Quick feedback on 48850.7.diff:
- To simplify the code you can always use
get_site_option()
. It falls back toget_option()
for non-Multisite. In a Multisite plugins can only be updated on the network screen, so it shouldn't use the single site option there anyway. - There's no need to add the string for automatic update information via another placeholder (
%7$s
) to the existing string. Just print it afterwards. - I think the option name should be
wp_auto_update_plugins
since it contains plugins to auto update.
#31
@
5 years ago
Thanks for the investigations @xkon
@ocean90 those points are very useful, thanks!
I should be able to fix them later today.
#32
@
5 years ago
This looks like a great first step. I think over the year it can be iterated but seems a good use of the same UI. As some feedback, I wonder if the arrow circle is even needed or works at that size, but that's to see in experience.
I do think @klou has a valid point about actions being beside the plugin title. I wonder what this limits though? I'd probably recommend removing the icon if it was moved to the side.
#33
@
5 years ago
Hm, actions usually are seen as 1-line I believe throughout the admin area and unfortunately the text here is kinda large by itself to at least fit at the same line and have Deactivate | Settings | Docs | Enable Automatic updates
, don't you think? Also we have to take under account plugins that might be adding more links there :/.
Except if the naming gets shorter i.e. Enable Auto Updates ( or as in the filter Auto Update On/Off but this will be confusing as a switch most likely).
One iteration of "looks-like" a 2-liner ( since the comments are long and might've been missed on scrolling fast :D ) on the left side is similar to autoupdate-2-bulk-edit.png with a notice right under the title but I personally think that it looks better & reads more easily where it is on the latest patches.
#34
@
5 years ago
I took a closer look by creating two wireframes.
The first wireframe I placed the icon and Automatic text below the text under the title.
The second wireframe I placed them under the description.
(The text is a bit squashed in both columns.)
The most important actions in the plugin screen are the links below the title. It is good to keep this area more spacious.
There is more consistency in the Plugin title column. The Description column contains a lot more variation and can easier also contain additional text without it feeling as crowded as the Plugin column.
But then again important actions would also remain in the plugin column.
#35
@
5 years ago
Thanks all for contributing to the discussion.
In the meantime, I added 48850.8.diff
, which addresses the concerns @ocean90 raised in Comment:30.
- Simplify the code by using
get_site_option()
instead ofget_option()
- Remove a useless placeholder.
- Rename the option to use
wp_auto_update_plugins
since it contains plugins to auto update. I also renamed the corresponding PHP variables.
#36
@
5 years ago
@klou @karmatosed @paaljoachim thanks for your design feedback 👍
I'm not convinced by the idea of moving the button-link in the "Plugin" column. Indeed, the text of the link is pretty long, and I think it just can't be both shorter and understandable/accessible.
Also, we have to think about translations.
For example (in those examples, I'll use fr_FR but I'm pretty sure the issue also exists in other languages!), "Enable automatic update" will be translated as "Activer les mises à jour automatiques" in French :-) Pretty long, but we just can't make is shorter. Even worst: there is no short equivalent to "Auto Update" expression in French.
Therefore, I'd say we keep the action in the Description column. And I initially added the dashicon to make it more discoverable because it's in the Description column :-)
Does it makes sense for you? Any opposite thoughts on this?
(in any case, I think we shouldn't use the short version "auto update" at all, even in the filters on the top of the page but that's another question)
#37
@
5 years ago
Correct me if I'm wrong, but despite the fact that "enable automatic updates" is quite big, I don't think that it will break into 2 lines, because of the fluidity of the second column.
I think the wording of this action should be: "enable/disable automatic updates" as a link. I would prefer automatic from auto because I think it'll be clearer for the translators to scan it and translate it in other languages without any issues.
Also, I think we should always group the core actions of a plugin ( activate / enable automatic updates ) and then let the plugin authors add their own actions.
@karmatosed Regarding the use of icons, instead of using an icon for the actual link, we could use it in front of the plugin title, to indicate it has automatic updates enabled.
#38
@
5 years ago
I've been digging into the auto-update internals this week to understand everything about how auto-updates works in its current state. I haven't tested this patch thoroughly yet, but here are some things that we'll need to add to the patch (there will be some overlap for this feedback with the theme ticket over at #49199).
First, an email must be sent to the site owner when a plugin or theme auto-updates. In the current state, a site owner only receives an email if core auto-updates, someone is running a development version of core (they will then receive emails when plugin, theme, and language pack updates are applied automatically if enabled with the filter), or automatic_updates_send_debug_email
is being filtered.
Second, there will need to be a way for someone to blanket enable/disable this feature for both plugins and themes. A constant will probably be best for this, similar to how it works for core with WP_AUTO_UPDATE_CORE
. WP_AUTO_UPDATE_THEMES
and WP_AUTO_UPDATE_PLUGINS
would follow that naming convention. For now, this should be true
or false
. In the future, we could add support for security
, or maybe even minor
/major
. When the auto-updates are enabled with one of these constants, the admin should indicate this somewhere. "Auto-updates are enabled for all plugins", or something to that affect.
If it is disabled with a constant, then I don't think it has to mention auto-updates anywhere in the UI.
I'll post more feedback as I continue to dig in!
#39
@
5 years ago
One last thought for now. When auto-updates are attempted, it checks if the install appears to be under version control.
If this function returns true
, no auto-updates are ever applied. I think in the scenario where a WordPress install appears to be under version control, the user should not be able to enable auto-updates for plugins and themes. I am also thinking the UI elements should be hidden to prevent potential confusion.
#40
@
5 years ago
- Severity changed from minor to normal
- Status changed from assigned to accepted
Thanks @desrosj those are very valuable thoughts!
In 48850.9.diff
:
- Added
WP_DISABLE_PLUGINS_AUTO_UPDATE
constant to disable auto updates - Added
wp_is_plugins_auto_update_enabled()
PHP function to check wether the plugin auto updates are enabled or not on the website - Added
wp_plugins_auto_update_enabled
filter - Added some conditional statement so the auto update UI stuff is hidden is automatic updates are diseabled
It works fine on my side :-)
(also: removing minor
severity as it's one of WordPress Core projects for the beginning of 2020)
#41
@
5 years ago
- Milestone changed from Awaiting Review to 5.4
@desrosj concerning version control system check, I'd suggest to address that concern in another ticket, to keep this one focused on its main goal.
Maybe I'm wrong, but looking at #41078 (which was previously closed as maybelater
), it looks like the concern you raised is not limited to the auto update feature, but also to themes and plugin editions, etc.
(Not related: I forgot to move this ticket to 5.4, so now it's in the milestone)
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
5 years ago
This ticket was mentioned in Slack in #core by valentinbora. View the logs.
5 years ago
#44
follow-up:
↓ 47
@
5 years ago
Second, there will need to be a way for someone to blanket enable/disable this feature for both plugins and themes. A constant will probably be best for this, similar to how it works for core with WP_AUTO_UPDATE_CORE. WP_AUTO_UPDATE_THEMES and WP_AUTO_UPDATE_PLUGINS would follow that naming convention. For now, this should be true or false. In the future, we could add support for security, or maybe even minor/major. When the auto-updates are enabled with one of these constants, the admin should indicate this somewhere. "Auto-updates are enabled for all plugins", or something to that affect.
Would auto plugin updates disabled via WP_AUTO_UPDATE_PLUGINS
prevent updates that are listed as autoupdate => true
in the version check response from being automatically updated as well?
#45
@
5 years ago
In 48850.10.diff
:
wp-includes/update.php
: Add a pre-check to avoid updating plugins ifWP_DISABLE_PLUGINS_AUTO_UPDATE
constant is set to false
wp-admin/includes/class-wp-plugins-list-table.php
: Edit filters and variables wording for consistency
#46
@
5 years ago
I'm 80% through a deep review of everything here. Some small feedback that can be addressed outside of the improvements that I am working on:
- We need to standardize the term "auto-update". I confirmed with @chanthaboune that it should be hyphenated. I looked at the documentation already found within the core auto updater, and it was all over the place (auto update, auto-update, autoupdate). After we make this consistent in the new code and documentation we are introducing, it should be added to the spelling best practices page and a new ticket can be created to fix the current inconsistencies.
- For multisite, I believe in my testing I was able to toggle a plugin's auto-update on and off within a site dashboard. This should only be available on the network admin plugins screen for the primary network, and only network admins should have the ability to turn auto-updates on or off.
#47
in reply to:
↑ 44
;
follow-up:
↓ 48
@
5 years ago
Replying to TimothyBlynJacobs:
Would auto plugin updates disabled via
WP_AUTO_UPDATE_PLUGINS
prevent updates that are listed asautoupdate => true
in the version check response from being automatically updated as well?
The way I was thinking of it was:
- The constant disables the UI aspects of the feature and defaults all plugins to
$update = false
ortrue
. - The only way to toggle a plugin's auto-update status when the constant is defined would be to use the
auto_update_plugin
filter (or a new filter that I am debating adding).
The way the core auto updater works is similar.
- Constant value becomes the default update value.
- There is a filter to change the value provided by the constant.
- There are filters for changing whether to allow each the minor, major, and dev version to update.
#48
in reply to:
↑ 47
;
follow-up:
↓ 50
@
5 years ago
Replying to desrosj:
The way I was thinking of it was:
- The constant disables the UI aspects of the feature and defaults all plugins to
$update = false
ortrue
.- The only way to toggle a plugin's auto-update status when the constant is defined would be to use the
auto_update_plugin
filter (or a new filter that I am debating adding).
Would that mean that a plugin could itself override any value set in the constant by using the filter? I'm not sure that's a good thing - I could perhaps see the argument that a plugin author might want to disable auto-updates for their plugin, but would we want them to be able to turn them on even if the site owner has chosen to turn them off?
You could of course still override that again with another filter using a later priority, but that would require you to know you needed to do so in the first place.
#49
@
5 years ago
The constant disables the UI aspects of the feature and defaults all plugins to $update = false or true.
Gotcha, that makes sense to me, thanks!
#50
in reply to:
↑ 48
@
5 years ago
Replying to markparnell:
Would that mean that a plugin could itself override any value set in the constant by using the filter? I'm not sure that's a good thing - I could perhaps see the argument that a plugin author might want to disable auto-updates for their plugin, but would we want them to be able to turn them on even if the site owner has chosen to turn them off?
The filter to accomplish this (and this scenario) already exist in core today. The only difference is that a normal every day user cannot indicate whether they want auto-updates. Plugins and themes should be respecting the choices of the site owners unless there is good reason to. One use case I can think of is an incompatibility with another plugin or a version that breaks backwards compatibility. In these instances, blocking an auto-update may be a reasonable action.
Some of the potential issues that arise from exposing this feature with a UI will require some monitoring to see what plugin authors do. There may be a few scenarios that arise that may require an update to the .org plugin guidelines. For example, "You promise to respect the user's preference when it comes to auto-updating" may be something to add. They should also never modify a user's choice when it comes to another plugin or theme (like a competitor's).
#51
follow-up:
↓ 53
@
5 years ago
I am surprised to see the ability to enable/disable auto-updates presented so prominently.
Has it been discussed someplace other than Slack to not have any UI for this, not expose it to end-users, and simply opt-in everything by default? Especially considering how much agitation the idea of exposing a UI for Core caused at the time.
As we’ve all likely learned from years of using operating systems on computers and phones, update fatigue does not just hit us from the updates themselves, but also from deferring every decision to the user when the natural desire is nearly always going to be “please let the machine do the work for me so I don’t have to.”
What I do not prefer about these design iterations, is that these links are being offered to users alongside other normal actions, as if we are making it easy for them to be toggled.
Programs like WordPress should not make running out-of-date code easy to do, and if a plugin cannot be trusted to be update automatically, users will not know that until it’s already too late anyways, and by that time fatal error protection will have likely prevented the majority of failures.
If the decision has already been made to make them toggleable, auto-updates are the kind of on-off feature that seem ripe for using an actual Toggle UI control for. I know Gutenberg offers one, and they’re pretty easy to do with just CSS:
https://www.w3schools.com/howto/howto_css_switch.asp
Imagine them in their own right-most column in the list table, with a master on/off toggle as well.
@
5 years ago
Remove autoupdate on plugins screen if the website is a multisite and not on network admin website
#52
@
5 years ago
For multisite, I believe in my testing I was able to toggle a plugin's auto-update on and off within a site dashboard. This should only be available on the network admin plugins screen for the primary network, and only network admins should have the ability to turn auto-updates on or off.
Thanks @desrosj, good point!
In 48850.11.diff
:
- Remove autoupdate options if the website is a multisite and if we are not on Network admin website.
#53
in reply to:
↑ 51
@
5 years ago
Replying to johnjamesjacoby:
Has it been discussed someplace other than Slack to not have any UI for this, not expose it to end-users, and simply opt-in everything by default?
I do not think there has been a discussion around plugin/theme auto-updates specifically. With the introduction of Site Health and the WSOD protection, there are now mechanisms for every day users to troubleshoot issues that may arise from auto-updating. That, combined with being named in the 9 projects for 2019 (which has carried over into 2020), and the desire to make it easier for users to keep their sites up to date have been the driving factors.
I'm happy to have the discussion (I have been playing devil's advocate and thinking it through in my head). But, as far as I know, making plugins and themes opt-in by default is not an option.
Especially considering how much agitation the idea of exposing a UI for Core caused at the time.
Can you clarify this? Do you mean the auto-update discussions that have happened recently? Just want to be clear about which agitation you are referring to.
If the decision has already been made to make them toggleable, auto-updates are the kind of on-off feature that seem ripe for using an actual Toggle UI control for.
I am not completely in love with including the enable/disable link where it is now. The icon also feels out of place to me because no other action links on the page have icons. My preference is including it in the row of actions under the plugin name and not including an icon. But I defer to the design team there.
#54
@
5 years ago
the desire to make it easier for users to keep their sites up to date have been the driving factors
Maybe there is a misunderstanding. Allowing users to disable individual plugin & theme updates will not help them keep their sites up-to-date more easily.
making plugins and themes opt-in by default is not an option
Why not?
Can you clarify this? Do you mean the auto-update discussions that have happened recently? Just want to be clear about which agitation you are referring to.
Not recently. When WordPress core originally started auto-updating minor releases, a large amount of feedback came in from people wanting a user interface toggle to disable them. Instead of being listened to and understood, those people were publicly made to feel like they were advocating running insecure and out-of-date software. The feature was committed without a UI (as it exists today) and many different plugins were created and approved to provide a UI for it instead.
I defer to the design team there.
Maybe we shouldn't, and instead should be suggesting & submitting other design ideas? Is this the correct place to do that?
#55
@
5 years ago
@johnjamesjacoby thanks for sharing your thoughts 👍
Maybe we shouldn't, and instead should be suggesting & submitting other design ideas? Is this the correct place to do that?
For the moment, the idea was to start with the existing UI, and to refine that after the feature is fully functional. The good thing with the current implementation is that we know that it's ok from design and accessibility perspective.
New patches with alternative design options are very welcome. In any case, we'll need a design review on eventual alternative design options.
…also, deep code review and testing is more than welcome 🙏
#56
follow-up:
↓ 57
@
5 years ago
For the moment, the idea was to start with the existing UI, and to refine that after the feature is fully functional
What do you mean by "existing UI"? I see a few suggestions in this ticket, none of which are in WordPress already.
we know that it's ok from design and accessibility perspective
I really do not think that it is, though. The feedback in this issue I happen to agree with, that the words are too long, the icon is foreign (and not really the correct one to use), the links are awkwardly positioned next to other links that serve other different purposes, all of which together result in a design that does not look elegant or appealing or easy for users to identify and interact with without a high probably of trial & error. (Maybe it's accessible, but I don't see anything in this ticket that confirms that specifically.)
also, deep code review and testing is more than welcome
When everything is undecided and in-flux, code review seems premature. Personally, I'm always happy to help (and only trying to be helpful) but I have a hard time reviewing some parts (code) and not others (design) because it's all equally important, and they both rely on each other.
The question I still have, is why is this toggle being advocated for? Why is a UI necessary?
I would like to suggest making plugin autoupdates even more mainstream by adding a new column to the Plugins screen, where one could toggle autoupdates on / off for just about any plugin
What user wants to go through 50 plugins and click 50 links and enable them all manually? (Bulk Edit helps, but still feels weird to me for reasons that are hard to put into words right now.) Once they're on, what problem will come up that will make them visit the plugin screen and disable one or many of them later?
I am all-in on the idea of giving administrators control over their installations, but I have a hard time imagining a scenario where anyone would know ahead of time that they need to manually disable an automatic update on a specific plugin to avoid some future breakage.
What I can imagine, is auto-updates triggering some breakage, causing a user to naturally disable future auto-updates for that plugin. Now they've opted out of receiving the fix automatically. I am afraid that the solutions proposed here are enabling the problem they set out to originally address:
make it easier for users to keep their sites up to date
New patches with alternative design options are very welcome
👍👍👍
#57
in reply to:
↑ 56
@
5 years ago
Replying to johnjamesjacoby:
For the moment, the idea was to start with the existing UI, and to refine that after the feature is fully functional
What do you mean by "existing UI"? I see a few suggestions in this ticket, none of which are in WordPress already.
I meant: starting with something that doesn’t add new styles or extra columns or new control that doesn't exists yet in Core, but to clarify: it's totally ok to propose the same patch with alternative design :)
we know that it's ok from design and accessibility perspective
I really do not think that it is, though. The feedback in this issue I happen to agree with, that the words are too long, the icon is foreign (and not really the correct one to use), the links are awkwardly positioned next to other links that serve other different purposes, all of which together result in a design that does not look elegant or appealing or easy for users to identify and interact with without a high probably of trial & error. (Maybe it's accessible, but I don't see anything in this ticket that confirms that specifically.)
I can confirm it's ok from an accessibility point of view, and the design team already discussed the current patch during meetings. But I know they are not totally comfortable with the current proposal so alternatives are very welcome. In any case, the ticket is open since weeks, so other design should be proposed as soon a possible to help this moving forward.
Basically, I don't think it's realistic to add a completely new UI control.
also, deep code review and testing is more than welcome
When everything is undecided and in-flux, code review seems premature. Personally, I'm always happy to help (and only trying to be helpful) but I have a hard time reviewing some parts (code) and not others (design) because it's all equally important, and they both rely on each other.
I personally think we need a solid code basis first, but I have to admit it's very personal as well :)
What user wants to go through 50 plugins and click 50 links and enable them all manually? (Bulk Edit helps, but still feels weird to me for reasons that are hard to put into words right now.) Once they're on, what problem will come up that will make them visit the plugin screen and disable one or many of them later?
To change autoupdate system for 50 plugins / 50 clicks at once, they should probably use the bulk edit select, just like they probably do when they want to update/activate/deactivate multiple plugins at once.
Concerning the opt-in choice, this is in the scope of the plugins/themes autoupdate project since the beginning, and it was proposed as opt-in in 2019 in the 9 projects for 2019 post. This is why that ticket is based on opt-in :-)
#58
follow-up:
↓ 60
@
5 years ago
Concerning the opt-in choice, this is in the scope of the plugins/themes autoupdate project since the beginning, and it was proposed as opt-in in 2019 in the 9 projects for 2019 post. This is why that ticket is based on opt-in :-)
According to that post (thanks @desrosj for the link):
Providing a way for users to opt-in to automatic plugin and theme updates
When I read this project goal, it does not imply to me that individual plugins & themes should have their own toggles.
The other related project goal also says:
Providing a way for users to opt-in to automatic updates of major Core releases
In my imagination, these two together, along with how WordPress already works, lead me to believe and expect that minor releases for plugins & themes would auto-update, and majors would be opt-in. (I understand that not all plugins and themes use the same numbering scheme for their releases, but that's a different technical challenge that can be solved without additional design overhead.)
Links for every individual plugin and theme seems, to me, to be working in the wrong direction for the right reasons. Naturally, my concerns are that the wrong efforts are being put in, and that if I'm wrong about that, I still don't like the idea anyways because I don't think it makes much sense. 😆
Design wise, my major concern - the crux of the issue - is that nothing visually conveys the state of a plugin or theme having auto-updates on or off; it's just words.
When plugins are active or inactive, the list-table row changes color. A Gutenberg style Toggle provides the visual appeal of a switch being either on or off, where-as words are just words, and require too much deep attention to be glanceable. Users will toggle them off and forget about them. It will happen, and it's directly against the project goal.
#59
@
5 years ago
- Keywords needs-design added
What a lot of great thoughts added to this. Just a little note from a design perspective I am going to take a look at mapping this, specifically what needs a design and what has one, where are our spots to cover. Once that is done I'll put something up here and look into potentially some mocks as the starting point.
Tomorrow in the weekly design meeting this can also be a talking point. I hope this helps start thinking about possibilities. I am aware we have a limited timeframe, so let's focus on a cupcake - delicious and what we need for the first release. Just like with site health, we can iterate over the year. However, we do need foundations in place and flow that works.
#60
in reply to:
↑ 58
;
follow-up:
↓ 61
@
5 years ago
Replying to johnjamesjacoby:
Providing a way for users to opt-in to automatic plugin and theme updates
When I read this project goal, it does not imply to me that individual plugins & themes should have their own toggles.
The other related project goal also says:
Providing a way for users to opt-in to automatic updates of major Core releases
In my imagination, these two together, along with how WordPress already works, lead me to believe and expect that minor releases for plugins & themes would auto-update, and majors would be opt-in.
Good point, I would have the same expectations. Not sure if individual toggles are really necessary here.
#61
in reply to:
↑ 60
@
5 years ago
Replying to SergeyBiryukov:
Good point, I would have the same expectations. Not sure if individual toggles are really necessary here.
I see arguments for both sides here. Trying to think this through in my head to fully envision this side. Without a toggle for individual plugins, how would a user disable automatic updates for a specific plugin after blanket enabling auto-updates?
#62
@
5 years ago
Yes @desrosj. And I can also easily imagine several realistic use cases.
Here is some of them:
- Users who experimented some issues with one of the plugins they use, and who don't trust them so much (even if they are objectively wrong).
- Users who want to deactivate updates for a specific plugin because it was modified with the plugin editor screen (this possibility is proposed by default in WordPress admin so we should take it into account).
- Users who don't want to update some "critical" plugins before they have been tested in a staging, preprod, development or even their local environment.
- Users who don't want to update some "critical" plugins because they think (even if they are wrong) that it's better, for this "critical" plugin, to wait few days to see if a patched release is provided by the plugin author after a major update.
Same goes for themes. @johnjamesjacoby @SergeyBiryukov I personally think this is why we should leave the possibility to toggle autoupdate item by item.
@johnjamesjacoby
In my imagination, these two together, along with how WordPress already works, lead me to believe and expect that minor releases for plugins & themes would auto-update, and majors would be opt-in.
Maybe I'm wrong but I believe there is no standardized difference between major and minor for plugins. Plugin authors can use WordPress versioning naming system, SemVer or even just the date they released their new version (like 20200205) or other custom versioning systems.
#63
@
5 years ago
I took some time as I said would and have come up with some things would be great to get feedback on. I, for now, am focusing on plugins in mocks but whatever we do also applies to themes.
First, let's look at the flows. Props to @audrasjb for surfacing these.
- How a user controls updates (note green are actions they want, grey screens)
- When a user is informed and in yellow 'what' method.
- Developer control for auto-updates (this one I feel uneasy in clarity)
- Admin control for auto-updates (considering multisite)
I also began exploring on the plugin screen what 'multiple updates' could look like and as you can see a column feels pretty nice here and would allow us to easier have the checkbox and bulk action. I really like idea we use our existing bulk actions as that is understood. It does make it a less 'visual' process and feels very functional, but that also seems to align with this interface. There is then space to give different messages and separate actions, it makes it conscious over hidden.
These are very rough mocks so apologies about their franken-mock nature, just trying to get ideas out rapidly.
One problem we need to consider is repeating UI, a sea of links or toggles is possibly less of an issue than the checkboxes that are already accepted.
- Do people agree these are correct?
- Anything missing? I bet there is so let's correct that now!
- As we dive into this working out what we need to communicate where is also key, the words we use will soothe or not, so it's critical.
#64
@
5 years ago
Awesome work @karmatosed thanks!
I have some questions/suggestions:
- You use "pause/paused" for plugins that don’t have autoupdates enabled. I think "disable/disabled" makes more sense since the autoupdates are still in the state they were before 5.4: disabled. Nothing was paused. Please note: maybe I'm wrong, as you knows I'm not a native English speaker at all :)
- The new column looks good to me, but in that case I don't think we should keep anything in the description column.
- In your schema/graphics, I think you forgot some use case where developer are able to disable/enable/setup autoupdates settings by using filters and constants.
- I think it should also include the flow for multisites/network installs
I should be able to work on the new autoupdate column and send a patch tonight, after the devchat :-)
#66
@
5 years ago
In your schema/graphics, I think you forgot some use case where developer are able to disable/enable/setup autoupdates settings by using filters and constants.
At what step do you see that? Similarly, any ideas on the multisite flow would be great to work through.
#67
in reply to:
↑ 65
@
5 years ago
Replying to karmatosed:
Ah yes, on the only showing in the column that was my intent but trying to show a comparison. To be clear this is what you would see:
Ok! Thanks. In that case, I guess we'll want to add a control (button, link, checkbox…) to enable autoupdates for each item :)
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
5 years ago
#70
follow-up:
↓ 79
@
5 years ago
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 theCore_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. InCore_Upgrader
, the code goes a step further by determining whether the update being attempted is a major, minor, or development update and 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 onlysecurity
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 accompanyingWP_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?
#71
@
5 years ago
I left some comments in the Figma file, but wanted to bring the larger thoughts here for discussion.
- Depending on how important we believe this to be, it might be better to pull the auto-updates out into their own column, as one mockup indicates, rather than including it below the plugin description.
- If the auto-updates are in their own column, it makes it easier to scan and sort if needed.
- Because these rows already include some form of checkbox, I suggest we veer away from checkboxes and stick with simple links.
Basically, I'm in favor of this mockup from Tammie. http://cldup.com/wvlkxhi9TH.png
Some of the settings in that mockup are a bit off, but I believe it conveys the right amount of interactive elements and messaging for the user.
#72
follow-up:
↓ 75
@
5 years ago
Question: Should users be able to turn auto-updates "on" for an inactive plugin or theme?
If this has been discussed above, I apologize if I missed it.
#73
@
5 years ago
Can we somehow utilize the Shiny Updates UI elements for this?
It may not be possible, may not stand out enough, or may cause confusion. But this is something that is already in core and feels "natural" from already being included for several years.
"There is a new version of X plugin available View version details or update now. Enable automatic updates to receive updates automatically."
Not advocating against adding new UI elements, but just seeing if there are elements we can use that users are already accustomed to.
#74
@
5 years ago
Can we somehow utilize the Shiny Updates UI elements for this?
Good question. Unfortunately, the only time Shiny Updates show up is when an update is needed. For auto-updates we want the possibility to turn them on to always be visible. For this reason, I don't think using Shiny updates is the right solution. Even if we added it there AND made it visible, the user would learn to ignore it. Then when an update was requested, the user may not even notice.
One thing I noticed in the mockups was that I wasn't sure how to turn "on" an auto-update. So I revised the mockup a bit more. The messaging is under the description, and the interactive element is in its own column. Does this feel right, or should that be switched adding the interaction under the description and the status in the column?
#75
in reply to:
↑ 72
@
5 years ago
Replying to mapk:
Question: Should users be able to turn auto-updates "on" for an inactive plugin or theme?
If this has been discussed above, I apologize if I missed it.
Yes, plugins that are not active definitely need to be updated (with or without autoupdates, inactive things with security issues can lead to security exploits in some cases).
This ticket was mentioned in Slack in #core by david.baumwald. View the logs.
5 years ago
#78
@
5 years ago
I wonder, could we have 'enable' in the column for the situations where it's not enabled? My personal preference I think would be to have one section to go to for updates, that feels like the updates column.
#79
in reply to:
↑ 70
@
5 years ago
Replying to desrosj:
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.
Related: #34676
#81
@
5 years ago
@karmatosed Thanks for the mockup. I think we should use the term "Auto-update", and not just "update" as they are two different things.
If the idea is to mix the two actions (update a plugin and activate automatic update for this plugin), I think both of them need to appear in the interface. Also, I don't think we can "pause" an update.
I'll try to add a mockup as well to better explain it, based on the current screen and with the extra column.
#82
@
5 years ago
@mapk @karmatosed I tried to generate a mockup that uses a dedicated "Autoupdates" column and with simplified wording / action links. See screenshots above.
It also shows all the situations we'll have:
- A plugin is activated, up-to-date, and autoupdates are disabled: show enable autoupdates link
- A plugin is activated, up-to-date, and autoupdates are enabled: show disable autoupdates link
- A plugin is activated, needs to be updated, and autoupdates are disabled: show enable autoupdates link
- A plugin is activated, needs to be updated, and autoupdates are enabled: show disable autoupdates link and show the next scheduled update time ("in 57 seconds" in my mockup)
There is other configurations but there are the main configurations we have to handle visually.
#83
in reply to:
↑ 80
@
5 years ago
Replying to karmatosed:
An idea of what this might look like:
I want all those plugins! Especially Bunny Sparkles and Hamster Parade!
Seriously, though -- I like this column approach. Much harder for people to miss the fact that these auto-updates are a thing.
#84
follow-up:
↓ 85
@
5 years ago
I think that final solution works pretty well, @audrasjb.
My only concern is that because these links are all under the Column, "Automatic updates", do we need to repeat "autoupdate" with every link? Is "Enable" and "Disable" enough? Basically these two links work as the "on" and "off" switches... I'd just like to make sure they provide enough feedback to the user that the user realizes their autoupdates are "on"
@karmatosed, I'm not sure, in regards to this row in your mockup, how I would disable the autoupdate.
I'd also like to make sure we use the wording "enable" and "disable" so that these links don't get confused with the other "Activate" and "Deactivate" links under the plugin name.
#85
in reply to:
↑ 84
@
5 years ago
Replying to mapk:
My only concern is that because these links are all under the Column, "Automatic updates", do we need to repeat "autoupdate" with every link? Is "Enable" and "Disable" enough? Basically these two links work as the "on" and "off" switches... I'd just like to make sure they provide enough feedback to the user that the user realizes their autoupdates are "on"
Good point @mapk, thank you. You're right, this extra wording looks kinda repetitive, but I personally think it's necessary to make it very clear that "Enable" stands for "Enable autoupdate" and not "Enable plugin/theme" (even if it doesn't make sense as "Activate" is the correct wording, in English), especially when the user directly scroll down in the plugins listing and doesn't have the column heading in their viewport.
That's also why I think it's better to use "Enable (autoupdates)", since "Activate" is already used for for plugin activation. But we have to add "autoupdates" as I many languages doesn't have different wording for "activate" and "enable".
Of course, we could also have a "Autoupdate ON/OFF" toggle, but we don't have this control on WP Core, only in Gutenberg. I think it's safer to use the existing controls (button-links) for 5.4 and iterate later :)
@karmatosed, I'm not sure, in regards to this row in your mockup, how I would disable the autoupdate.
I'd also like to make sure we use the wording "enable" and "disable" so that these links don't get confused with the other "Activate" and "Deactivate" links under the plugin name.
Yeah, that :)
#86
@
5 years ago
You're right, this extra wording looks kinda repetitive, but I personally think it's necessary to make it very clear that "Enable" stands for "Enable autoupdate" and not "Enable plugin/theme"
This makes sense. @audrasjb, do you think the link that says "Disable autoupdate" is enough to convey to the user that the auto update is "on" for that plugin? I think it might be because it follows a similar pattern for the "Activate" links under the plugin name.
Of course, we could also have a "Autoupdate ON/OFF" toggle, but we don't have this control on WP Core, only in Gutenberg. I think it's safer to use the existing controls (button-links) for 5.4 and iterate later :)
I would love to get to a toggle control for this in the near future. I believe it would communicate the action much more clearly than a link.
#87
@
5 years ago
What about this as an iteration:
I realise it's adding another layer there but it might be useful in this case.
#88
@
5 years ago
This is so close right now!
Here's a revised mockup taking into account a bit of copy editing, positioning, and colors. This latest one displays simple messaging, and follows other link layout patterns.
Layout patters to decided on:
- Inline messaging and link.
- Text aligned messaging and link.
- Left justified messaging and link.
#89
@
5 years ago
I really like the idea behind this ticket, but I fear that given the various proposals for what the UI could/should be it's too late for 5.4, with beta 1 coming up very soon.
I do, however, there is still time for the "infrastructure" things that @desrosj brings up in #comment:38 and #comment:79
- emailing site admin when plugins/themes auto-update
WP_AUTO_UPDATE_PLUGINS
andWP_AUTO_UPDATE_THEMES
constants
As for the constants, I also think it would be useful to allow them to accept arrays, e.g.
<?php // enable auto-update for specific plugins, disable it for all other plugins. define( 'WP_AUTO_UPDATE_PLUGINS', array( 'plugin_1', 'plugin_2' ) );
#90
follow-ups:
↓ 91
↓ 96
↓ 97
@
5 years ago
@desrosj I've taken a quick look at 48850.12.diff, here are my notes.
- 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. - For plugins that use semantic versioning and therefore may have breaking changes between versions (such as WooCommerce), do we need to modify the .org API to return
offer_minor
andoffer_patch
to allow for the plugin additional control over how it may be auto updated - To prevent
malicious-plugin
from messing what's offerer togood-honest-plugins
, do we need to use PHP Reflections to limit filters running on the the plugin to the plugin itself. This is super complex I know but keep in mind the offered file can be changed from wp.org to malicious.org via filters. This is perhaps a topic for another time.
Generally, if WP_AUTO_UPDATE_PLUGINS === false
and sites using version control then the auto-updates UI ought not be displayed.
Sorry for the lateness of my notes on the ticket. I do agree with the comment above that this is probably too late for 5.4, unfortunately given everyones hard work. Could it be released as a feature plugin between 5.4 and 5.5?
#91
in reply to:
↑ 90
@
5 years ago
Replying to peterwilsoncc:
Sorry for the lateness of my notes on the ticket. I do agree with the comment above that this is probably too late for 5.4, unfortunately given everyones hard work. Could it be released as a feature plugin between 5.4 and 5.5?
Thanx for mentioning the feature plugin alternative! I debated saying something about that in my comment. In fact, a feature plugin could offer several of the different UIs that have been proposed, allowing testers to switch back-and-forth between them to better evaluate the pros/cons of each in the context of real sites, rather than in the abstract.
#92
@
5 years ago
Having it as a feature plugin for a few months is a very good alternative to adding it to WordPress 5.4. As it would give the new update feature more space to mature. It would also get time to gather feedback from users on possible adjustments before an improved version can be included in WordPress 5.5. Important features should have some time to be tested before they are officially included in core.
#93
@
5 years ago
I really like the idea of this as a feature plugin, the process needs working out for it but makes aa lot of sense.
#94
@
5 years ago
I also think that with all the back & forth discussions (which is awesome) being the 7th today this isn't becoming optimal for 5.4 I believe.
Pushing it a bit further atm seems like the best option since plenty of questions & iterations have been raised on both Plugin/Theme tickets and a featured plugin would be easier on testing and getting feedback outside of Trac as well.
(Shall we start converting to a plugin haha? 😁)
#95
@
5 years ago
Howdy,
Thank you all for sharing your thoughts on this feature.
You'll see some new patches in the next few hours. It's not that we don't hear the opinions about moving it to 5.5 or keeping it in 5.4. I just need to keep the momentum on the current work on this feature.
#96
in reply to:
↑ 90
;
follow-up:
↓ 98
@
5 years ago
Replying to peterwilsoncc:
To prevent
malicious-plugin
from messing what's offerer togood-honest-plugins
, do we need to use PHP Reflections to limit filters running on the the plugin to the plugin itself. This is super complex I know but keep in mind the offered file can be changed from wp.org to malicious.org via filters. This is perhaps a topic for another time.
That sounds like it would apply to core updates too. Basically, any installed plugin can do pretty much anything to the site and its database, even without messing with another plugin's updates.
#97
in reply to:
↑ 90
@
5 years ago
Replying to 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 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.
#98
in reply to:
↑ 96
@
5 years ago
Replying to SergeyBiryukov:
That sounds like it would apply to core updates too. Basically, any installed plugin can do pretty much anything to the site and its database, even without messing with another plugin's updates.
Agreed and something that came up in the discussion @desrosj and I had. A red herring for the reasons you mentioned.
#99
@
5 years ago
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.
WRT this, and AFAICT the current patch, I'm concerned that users would use this constant because they want to hide the UI, but would have ended up opting-out of forced security updates from .org. IMO, the value of autoupdate
in the API response should trump. Users could then continue to opt-out of auto updates all together using the existing AUTOMATIC_UPDATER_DISABLED
constant. And setting WP_AUTO_UPDATE_PLUGINS
to false would hide the UI.
It also looks like the current patch removes support for autoupdate
entirely, even if the constant is not set.
#100
@
5 years ago
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.
This ticket was mentioned in Slack in #core by david.baumwald. View the logs.
5 years ago
#104
@
5 years ago
Hi, let's make the plugin compatible with configuration through the code too.
GitHub Issue: https://github.com/WordPress/wp-autoupdates/issues/82
#105
@
5 years ago
Work on this has continued in the WordPress Auto-updates feature plugin (via it's GitHub repo).
The development of the feature plugin is close to being "feature complete" and we are getting ready to put together a merge proposal.
New Automatic update field in the Plugins screen