#50907 closed task (blessed) (fixed)
Add a method to opt-in to core auto-updates.
Reported by: | whyisjake | Owned by: | audrasjb |
---|---|---|---|
Milestone: | 5.6 | Priority: | normal |
Severity: | normal | Version: | 5.5 |
Component: | Upgrade/Install | Keywords: | has-patch needs-design-feedback has-dev-note |
Focuses: | Cc: |
Description
With WordPress 5.5 gaining support for auto-updates, let add a new feature for users to opt-in to auto-updates for WordPress core.
Attachments (32)
Change History (134)
This ticket was mentioned in Slack in #core by sergey. View the logs.
4 years ago
#3
@
4 years ago
Above is a first exploration for the main UI.
I think it should takes place on the Update screen.
I used a real button as it is more consistent on this screen, but it's not super consistent with the plugins/themes screen’s auto-updates action link. Not sure it's an issue.
#4
@
4 years ago
I think the language here needs to be a lot simpler. Something like "Keep WordPress up to date automatically."
Major
/Minor
/Core
are dev terms. As a user, I just want WordPress to stop asking me about updates.
This ticket was mentioned in Slack in #core by whyisjake. View the logs.
4 years ago
#6
@
4 years ago
Something like "Keep WordPress up to date automatically."
I'd advise caution here: this language implies that WP is not already kept up to date, which it is (at least concerning security issues and bugfixes in patch versions).
#7
follow-up:
↓ 9
@
4 years ago
Right now WordPress auto-updates security releases. Just to clarify then, is this issue about opt-in for ALL WordPress releases on my site?
This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.
4 years ago
#9
in reply to:
↑ 7
@
4 years ago
Replying to JoshuaWold:
Right now WordPress auto-updates security releases. Just to clarify then, is this issue about opt-in for ALL WordPress releases on my site?
Hey @JoshuaWold ... long time no talk :-)
Yes, this is about providing a UI for opting in to core MAJOR updates.
And just my personal opinion, but the UI should also all users to opt-out of core MINOR updates (which currently can be done via PHP constants and/or filters).
#10
@
4 years ago
Here's a little history on this ticket:
- opt-in for core MAJOR updates was first proposed in https://make.wordpress.org/core/2018/12/08/9-priorities-for-2019/
- it obviously didn't make it in 2019, so it was carried over into the priorities for 2020 in https://make.wordpress.org/core/2019/12/06/update-9-projects-for-2019/
#11
@
4 years ago
In relation to the screenshot I just shared.
I looked at what we have today.
There are groupings for Plugins and below it Themes.
It would be natural to have a WordPress title in the top, and below it the info we see today, and then a button that just says "Enable auto updates for WordPress"
It should probably instead say
"Enable auto updates of WordPress".
The correct language based on the plugins screen would be:
"Enable auto-updates of WordPress".
As it is straight to the point. Pressing the button will automatically keep WordPress up to date. The minor releases are automatically updated. So this button will finally keep the major versions updated. We need to keep the language as simple as possible.
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#13
@
4 years ago
- Keywords early added
Moving this one to early
to ensure it stays on our radar as it's part of scope for 5.6.
This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.
4 years ago
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
4 years ago
#18
@
4 years ago
I would caution against adding another button in this case. Why can't this be a checkbox or toggle option? It's an option right not an actionable button? I really think having 3 buttons of equal interaction hierarchy is a little confusing as far as the experience goes. As a result, I would love explorations that look at what other variations could be done here around not using secondary or primary buttons, seeing it more as an option.
This ticket was mentioned in Slack in #core-auto-updates by audrasjb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#22
@
4 years ago
In the above mockup I switched out the button with a checkbox. Visually it looks better. I also moved "Keep WordPress automatically updated" and the checkbox just below "You have the latest version of WordPress" heading. As it is nice to associate the two with each other.
#23
@
4 years ago
Perhaps something similar to this would work?
◉ Keep my site up to date with regular security and maintenance releases ◎ Keep my site up to date with regular security, maintenance, and feature releases
- Skip the developer focused text (minor/major)
- Focus on the Content of the releases (Security & Maintenance (Minor releases), and Feature (Major releases))
- It's much more explicit as to the current state
- Makes it obvious that they're already receiving security/maintenance updates
- No option to disable WordPress updates, that's plugin territory / for people who know what they're opting in to
- Core can flip the default option to the
feature
release option in the future and existing installs could continue to use the maintenance option.
That could be expanded to something like this, when updates are disabled:
◉ Do not keep my site updated. ⊙ Keep my site up to date with regular security and maintenance releases ⊙ Keep my site up to date with regular security, maintenance, and feature releases Your WordPress installation has updates disabled due to XXXXXXXX.
(I'm imagining ⊙ is an non-selectable disabled radio button in this case, and the Do not option is only shown when WordPress detects they're disabled)
3rd-party toolkits that keep WordPress updates (off the top of my head, such as Plesk Toolkit) can replace that section with their own notice / setting that controls their update methods. Plugins can extend the section to add the Do not keep updated
option, or more advanced things like "Wait for the .1 release for major releases" etc.
edit: I used 'releases' in the above text, but perhaps 'updates' would be a better word.
◉ Keep my site up to date with regular security and maintenance updates
#24
@
4 years ago
Brain dump of the points about the actual update process that I raised during the meeting on Tuesday:
- What happens when a user or admin logs in for the first time after a major version auto update? Normally an admin would be redirected to the About page after clicking the big blue button. They could be in the middle of doing something in the admin area, or see the admin area change before they see the email notification.
- Look at the possibility of a pre-release notification (email or admin area message) saying "WordPress will update to 5.7 in 7 days time". Would need something in the w.org API.
- A minor update rarely has changes that are visible to users but a major could potentially mean a change in UI from one page load to the next.
- Jonathan raised that "Most major updates have database upgrades to perform (though not all)".
- If a Multisite installation opts in to automatic major updates, the db upgrade process still needs to be run on all sites on the network.
- Hosts such as SiteGround auto update major releases on their managed WP hosting plans. It might be worth chatting further with the hosting community team to see if they have feedback from users around when major updates happen or find out what hosts do for major version updates.
- Maybe also the Gutenberg team. If we think of the block editor as a long-running SPA it could need some work around delivering over the air client code updates in the same way that PWAs do, or forcing a reload of the page at the point where a major update happens.
@
4 years ago
A new suggestion giving the user the option when or if to automatically update to the next WordPress release.
#25
@
4 years ago
Looks like a good idea @paaljoachim but it would need a dedicated (and it doesn't exist yet) API to handle the release date. Also release dates can change depending on the release process. I'm also concerned about minor releases. It would be a bit weird to announce the next release date and also announce that WordPress was just updated (minor release) :-)
#26
@
4 years ago
Last but not least, I'm clearly opposed to encourage people to wait before updating WordPress.
This ticket was mentioned in Slack in #core-auto-updates by paaljoachim. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-editor by pbiron. View the logs.
4 years ago
#30
@
4 years ago
We discussed this ticket during the Core Auto Updates office hours.
Here follows two mockups based on that discussion.
Mockup 1.
-radio button - Keep my site up to date with regular security and maintenance releases
-radio button - Keep my site up to date with regular security, maintenance, and feature releases
Mockup 2.
-radio button - Do not keep my site updated (only visible if auto-updates are disabled via the constant)
-radio button - Keep my site up to date with regular security and maintenance releases (greyed out, disabled)
-radio button - Keep my site up to date with regular security, maintenance, and feature releases (greyed out, disabled)
--
Paal Joachim:
Should there be a kind of title above the text?
As an introduction to the radio box options.
pbiron:
yes, I think so...as it's unusual for "settings" to be on the same screen where there are "actions" (e.g., update now)...so something that makes clear the radio buttons are settings and not actions. What exactly what that intro text should say, I'm not sure.
Here is a link to the discussion in the Slack core-auto-updates channel:
https://wordpress.slack.com/archives/CULBN711P/p1601399115005300
I also added a title/text above the radio buttons:
"Choose how to update your site."
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
4 years ago
#32
follow-up:
↓ 36
@
4 years ago
I think the order should be reversed?
Suggestion:
[] Keep my site up to date with regular security, maintenance and feature updates (major versions). [] Keep my site up to date with regular security and maintenance updates (minor versions). [] Keep my site up to date with regular security updates (security releases) (default). [] Do not keep my site updated (not recommended).
#33
@
4 years ago
Thank you for the suggestion, Carike! I will see what other folks say, and adjust the mockups.
I added the above submit button to the Updates screen of option 1 and 2.
As Dion @dd32 brought up the suggestion (in Slack) of adding the settings to the Settings -> General screen I thought it would be helpful to get a feel for how that would look and feel. Which means that I also included two mockups of settings in the General screen.
I am now wondering if Core Updates settings should be included in the Settings -> General screen. Because it gives it more breathing space for additional Auto update options that might at a later time be added.
Slack thread:
https://wordpress.slack.com/archives/CULBN711P/p1601400177022800
This ticket was mentioned in Slack in #core-auto-updates by paaljoachim. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
4 years ago
#36
in reply to:
↑ 32
@
4 years ago
Replying to carike:
I think the order should be reversed?
Suggestion:
[] Keep my site up to date with regular security, maintenance and feature updates (major versions). [] Keep my site up to date with regular security and maintenance updates (minor versions). [] Keep my site up to date with regular security updates (security releases) (default). [] Do not keep my site updated (not recommended).
Not sure about the "not recommended" addition here, as it very opinionated. There are a lot of use cases where not updating is required or updates are controlled by another system.
#37
@
4 years ago
[] Keep my site up to date with regular security and maintenance updates (minor versions).
[] Keep my site up to date with regular security updates (security releases) (default).
Just to note, WordPress doesn't differentiate between security and maintenance releases, they're both minor releases and auto-update currently.
My reasoning on the order was that the significance increases as you down down the list - Top is default (minor versions), Next is a step up (major versions).
Reversing it to be Major -> Minor -> Do not
would make sense if/when the major selection is the default.
Just to re-iterate it again, I really don't support having the Do not keep my site updated
option visible, unless it's the only option selectable (ie. a plugin or wp-config configuration has disabled updates), so we're really only dealing with two options here not 3-4. If a plugin is added that adds that option or others, they can do whatever they want with the ordering and wording..
Including recommendations in the options doesn't seem like what the options are for, and it's not done anywhere else, Site Health probably already includes enough warnings on that one "Updates are disabled due to XYZ" type messages
This ticket was mentioned in Slack in #core-auto-updates by paaljoachim. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
4 years ago
#40
@
4 years ago
- Keywords has-patch added; needs-patch removed
- Owner set to audrasjb
- Status changed from new to accepted
50907.diff
is a first workaround for the feature.
Some notes:
- I agree with @dd32: we should have only two options: opt-in for minor and/or major auto-updates.
- I think this implementation needs to be checked for Multisites, not sure it works well as it.
- I'm still not super fan of having those options in the General settings screen. The update-core screen is the place where we manage Core updates, so we should also manage auto-updates on the same screen.
Cheers,
Jb
#41
@
4 years ago
Thanks for everyone's work, unfortunately on review I do come back to encouraging some deeper exploring of what this is used for. There needs to be a little consideration over what this page is doing and how easy it is going to achieve that.
I really think there is a danger of over-complicating here with the scheduling, but that could be an issue with some formatting. I also agree this leans more into needing a dedicated not only API but section.
Overall, I think reviewing what we have on a few levels is a good way to get a solution and ship to release. The bigger sweeping comments are to consider line-height, spacing and hierarchy. This page is visually complex and contains a lot of content, finding ways to distil that down is crucial.
The biggest pain point for me right now, is the density of the page itself, adding this section has caused the capacity for this page to be reached visually. Is there any option over having multiple save buttons? I really would like us to reconsider how many there are on this page. Could sectioning work? Do all these needs to be seen at the same time? Really I would encourage some exploration that avoids what I am seeing in the current version where we have up to 5 buttons at once on a page potentially.
For now, I am leaving this as needs-design, I am also happy to aid with designs, but I know others are working on things here so don't want to jump in unless that is desirable. Let's discuss and find a way through that results in this section being more workable going forward and small iterations over just adding to it and causing it to become more problematic from an experience view.
This ticket was mentioned in Slack in #core-auto-updates by david.baumwald. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-auto-updates by audrasjb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-auto-updates by karmatosed. View the logs.
4 years ago
#45
@
4 years ago
Discussed this is Slack with @audrasjb and @karmatosed. Two items arose as things to consider:
The first is to add some do_action
s before and/or after the new settings field section for plugins to add their own options for the setting.
The second is that if the constant/filter for major core upgrades is overridden, the setting in the admin becomes useless. This might confuse users on managed hosts that control core updates. If the setting field can't actually affect the setting itself, the form should be hidden/removed altogether.
#46
@
4 years ago
Thank you so much for jumping into this patch with the stream of feedback both here and in Slack @audrasjb. I'm also going to link in the 'ideal state' that with today had some great feedback from @joen.
The plan from here will be to once this ticket is complete, create another with some potential iterations that might not make this release but could improve the updates page in it's entirity.
I think the only changes I would recommend would be this:
This ticket was mentioned in Slack in #core-auto-updates by karmatosed. View the logs.
4 years ago
#48
@
4 years ago
- Keywords early needs-unit-tests needs-design removed
Thanks Tammie! Looks like a great plan!
Removing some workflow keywords, as the patch now has design and I don't think it needs any unit test as it only adds a new UI to existing (but hidden) settings :-)
#49
@
4 years ago
Thanks, @audrasjb. What do you think about iterating the patch with those small adjustments in the attachment above? I totally understand if have to be done after beta (assuming can).
#50
@
4 years ago
@audrasjb it looks like the majority of 50907.1.diff is for changes to community events? Could we get a clean version of the patch for review?
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#53
@
4 years ago
- Keywords needs-refresh added
The patch is not applying cleanly. JB noted in today's scrub that he'll get a refresh today.
#54
@
4 years ago
The abbreviated patch applies cleanly and works for me. The setting is updating as expected and able to be overridden by the allow_*_auto_core_updates
filters.
The UI seems to be mostly in line with the auto updates section in Currrent thinking.png except that it uses the longer "WordPress auto-updates settings" title. I think the "WordPress" is a bit redundant there and prefer the shorter "Auto-update settings" from the image. If we keep the longer one though, I think one or the other of the words needs to drop the s, either "WordPress auto-update settings" or "WordPress auto-updates setting". The former probably makes more sense if we add a beta/RC option (#51319), the latter if we keep it a single checkbox.
Overall the UI is simple and clear though, which I like.
This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.
4 years ago
#57
@
4 years ago
Thanks for posting the screenshot. Great to see this getting into beta. I do feel it doesn't need to say WordPress, but I also think there is some room for improving the copy here to be clear about the intent. This can also be done around repeating words like updates where scheduling is. However, that is something for during beta.
#58
follow-up:
↓ 59
@
4 years ago
@aaroncampbell is this to be a single setting or a group of settings? Thinking about "Auto-update setting" vs "Auto-update settings" and in the saved notice too.
#59
in reply to:
↑ 58
@
4 years ago
Replying to afragen:
Perhaps title should read Core auto-updates setting?
I don't think most users know what "Core" means (or should be expected to). To them it's just WordPress and in this case the whole page has a heading of "WordPress Updates" so just referring to "Auto-update settings" or "Auto-updates setting" seems right.
Replying to afragen:
@aaroncampbell is this to be a single setting or a group of settings? Thinking about "Auto-update setting" vs "Auto-update settings" and in the saved notice too.
That seems to depend on #51319
#60
@
4 years ago
- Keywords commit added; needs-refresh removed
50907.3.diff is not perfect, but it is good enough for beta 1 and since it's a task we can iterate on the design and copy during beta 2.
#61
follow-up:
↓ 63
@
4 years ago
Hate to throw another late wrinkle into this but was just testing the patch and notice that the new setting appears even when define( 'WP_CORE_UPDATE_UPDATE', false )
. Shouldn't the constant being false mean that the setting doesn't display?
This ticket was mentioned in Slack in #core by helen. View the logs.
4 years ago
#63
in reply to:
↑ 61
@
4 years ago
Replying to pbiron:
Hate to throw another late wrinkle into this but was just testing the patch and notice that the new setting appears even when
define( 'WP_CORE_UPDATE_UPDATE', false )
. Shouldn't the constant being false mean that the setting doesn't display?
Seems like we'll need to take a look at those constants holistically after #51319 so we can do that during beta :)
This ticket was mentioned in PR #633 on WordPress/wordpress-develop by helen.
4 years ago
#64
Syncing patches for tests and review
Trac ticket: https://core.trac.wordpress.org/ticket/50907
#67
follow-up:
↓ 74
@
4 years ago
Feedback from a beta tester: The copy of the setting is a bit unclear to me at a first glance. Does the setting affect plugins and/or themes? Could the word ”Core” be added somewhere in the setting area? And a novice might ask: what is a major version? is 5.6 major, is 6.0 major? Might be good with clarification of that too.
#68
@
4 years ago
Will there be a constant or filter to disable the WordPress major core updates UI settings?
#69
@
4 years ago
Hi @helen and everyone.
Congrats for the great work.
I've just noticed, since [49254] trying unsuccessfully to update Gutenberg fr_FR translations that the </form>
closing tag was missing into the core_auto_updates_settings()
function.
#70
@
4 years ago
@lukefiretoss If the user doesn't have the update_core
capability none of it is displayed. For the purposes I've had that worked great. Do you have specific cases where they person should be able to update but should NOT be able to set it up to happen automatically?
#71
@
4 years ago
Referring back to a previous comment, there was discussion about a dedicated filter for hiding the setting altogether. The use-case mentioned was managed WP hosts, where Core updates are handled by the host.
The current_user_can
check could hide the setting, but that doesn't feel direct enough.
#72
follow-up:
↓ 73
@
4 years ago
@aaroncampbell Just for a filter or constant to be able to hide the setting for agencies that manage WordPress core updates for clients or managed hosts which manage WordPress core updates for customers.
#73
in reply to:
↑ 72
@
4 years ago
@lukefiretoss Yep, for us as a managed host taking away that cap made sense and was something that was actually already in place.
#74
in reply to:
↑ 67
@
4 years ago
Replying to kebbet:
Feedback from a beta tester: The copy of the setting is a bit unclear to me at a first glance. Does the setting affect plugins and/or themes? Could the word ”Core” be added somewhere in the setting area? And a novice might ask: what is a major version? is 5.6 major, is 6.0 major? Might be good with clarification of that too.
I hear you on the copy - I do feel like it could use some work. Personally I'm against using the word "core". I don't think most users know what "Core" means (or should be expected to). To them it's just "WordPress" or "my website".
I think that with the page already having a heading of "WordPress Updates" and there being "plugins" and "themes" sections under this with their own headings, most people will probably expect this to be for "WordPress". I would love to see some user testing around this, but I'm not sure who could get that in place in time for release.
As for "major version", that's another thing that I don't think we should expect our users to understand. I'd be in favor of dropping that parenthetical entirely, instead using something like one of these:
1) Keep my site up-to-date with regular feature updates.
2) Keep my site up-to-date with as new features are released.
3) Automatically update my site when new features are released.
4) Update my site for me when new features are released.
#75
@
4 years ago
Some content explaining that unless plugins and themes are updated then any major WordPress core update could cause issues on the site.
This ticket was mentioned in Slack in #core by aaroncampbell. View the logs.
4 years ago
@
4 years ago
Concept to reduce clutter on the page by placing this single-use option into an option tab. The option isn't expected to be used beyond setting or unsetting it and then forgetting about it. NOTE: I love the feature all in all just think we can cleanup the gui. Also the existing copy on the page could be updated to add a link to expand the options.
#79
@
4 years ago
That is a really good idea @garrett-eclipse
Instead of showing it openly in the Updates page one could instead add an Auto-update settings tab. It creates a nice future extendability. For potentially adding in additional auto update options.
#80
@
4 years ago
Regarding the label for the checkbox, @marybaum looked it over and we went through some possible options together to try to find clear descriptive text in the active voice. The recommendation is:
Automatically keep my site up-to-date with regular feature updates.
#81
@
4 years ago
I do agree that the setting is "set it and forget it", but I think we want to make sure it's easily discoverable by users - especially while it's currently opt-in. We know users miss the screen options tab all the time, even when they're actively looking for settings, so I'd rather not see us essentially hide this one in a similar location.
#82
@
4 years ago
Thanks @aaroncampbell I was thinking we'd include a linked text on the screen maybe close to the other update text that would trigger it to open so was hoping that type of convention would be less likely to be overlooked as it would be in the page copy.
#83
follow-up:
↓ 84
@
4 years ago
I suggest a small change: Automatically keep this site up-to-date with regular feature updates
in favor for the latest suggestion in the patch. This sentence is more open and can fit sites that are working as personal websites, and for sites for organisations or a companies.
#84
in reply to:
↑ 83
@
4 years ago
Replying to kebbet:
I suggest a small change:
Automatically keep this site up-to-date with regular feature updates
in favor for the latest suggestion in the patch. This sentence is more open and can fit sites that are working as personal websites, and for sites for organisations or a companies.
I like this.
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#90
@
4 years ago
Just noticed two conflicting strings. The notice displayed after saving shows "auto-updates" (plural), but the heading over the setting shows singular.
#91
@
4 years ago
- Keywords needs-dev-note added
Thanks @desrosj, 50907.5.diff
fixes this small inconsistency.
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-auto-updates by hellofromtonya. View the logs.
4 years ago
#95
@
4 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Closing as the ticket is done. needs-dev-note
is already applied.
This ticket was mentioned in Slack in #core by aaroncampbell. View the logs.
4 years ago
#97
@
4 years ago
- Keywords needs-design-feedback added
I decided to work on an exploration as to how the interface could be iterated. The feedback in recent dev chat lead me to focus on:
- Reducing the load of the interface.
- Thinking about how the experience could adapt from the first experience to the one most wil have when 'on'.
The attachments show the first screen with the placing not that changed, but the second shows a simple message that has a link to turn off. This keeps the functionality but also denotes a change in state, something has changed, something can be changed again. Copy will need to be worked on and I am happy to iterate here based on feedback.
I created these rather rapidly during the core chat to try and visualise some of the points being brought up as they happened, so consider these sketches please.
#98
@
4 years ago
- Keywords has-dev-note added; needs-docs needs-dev-note removed
Thanks for exploring this @karmatosed.
The second option looks good to me and seems technically doable without risk before Beta 4.
To be honest, I prefer the current implementation with exactly the same interface for opt-in and opt-out, but if we as a team, want to disconnect the two states, I think your proposal is good to go.
Thanks!
(PS: I also changed some workflow keywords)
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
4 years ago
#100
@
4 years ago
In the energy of yesterday, I forgot to props @helen for some amazing feedback that led to the above design, so doing that here.
I also have one other option that responds to the position feedback about the updates turning on. This moves it right to the top. Personally, I am not sure if on by default this would be needed, but adding to show all options.
#101
@
4 years ago
Feedback on copy: "my site" should be "this site", see comment 84.
Design drafts are missing heading and body for translations.
First exploration: Enable auto-updates