Add a method to opt-in to core auto-updates.

[whyisjake]

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.

[audrasjb]

First exploration: Enable auto-updates

[audrasjb]

First exploration: Disable (previously enabled auto-updates

[audrasjb]

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.

[whyisjake]

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.

[jnylen0]

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).

[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?

[pbiron]

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).

[paaljoachim]

Enable auto updates for WordPress

[pbiron]

Here's a little history on this ticket:

1. opt-in for core MAJOR updates was first proposed in ​https://make.wordpress.org/core/2018/12/08/9-priorities-for-2019/
2. 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/

[paaljoachim]

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.

[paaljoachim]

An adjustment.

[hellofromTonya]

Moving this one to early to ensure it stays on our radar as it's part of scope for 5.6.

[karmatosed]

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.

[paaljoachim]

Another suggestion. This with a checkbox.

[paaljoachim]

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.

[dd32]

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

[johnbillion]

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.

[paaljoachim]

A new suggestion giving the user the option when or if to automatically update to the next WordPress release.

[audrasjb]

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) :-)

[audrasjb]

Last but not least, I'm clearly opposed to encourage people to wait before updating WordPress.

[paaljoachim]

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."

[paaljoachim]

Option 1.

[paaljoachim]

Option 2.

[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).

[paaljoachim]

Core Auto Updates 1 - with a submit button.

[paaljoachim]

Core Auto Updates 2 - with a submit button

[paaljoachim]

Mockup of adding Core Updates 1 settings to Settings -> General screen.

[paaljoachim]

Mockup of adding Core Updates settings version 2 to Settings -> General screen.

[paaljoachim]

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

[davidbaumwald]

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.

[dd32]

[] 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

[audrasjb]

First technical implementation

[audrasjb]

First technical implementation screenshot

[audrasjb]

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

[karmatosed]

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.

[davidbaumwald]

Discussed this is Slack with @audrasjb and @karmatosed. Two items arose as things to consider:

The first is to add some do_actions 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.

[audrasjb]

New iteration based on what we shared with @karmatosed

[audrasjb]

New screen (including section margins)

[audrasjb]

Notice after saving auto-updates settings

[audrasjb]

Use case: there is an available Core Update

[karmatosed]

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:

[karmatosed]

Blue sky idea: copy not to be taken as final

[audrasjb]

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 :-)

[karmatosed]

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).

[aaroncampbell]

@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?

[hellofromTonya]

The patch is not applying cleanly. JB noted in today's scrub that he'll get a refresh today.

[helen]

Patch refresh attempt, manual diff editing

[aaroncampbell]

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.

[aaroncampbell]

Screenshot with 50907.2.diff

[afragen]

Perhaps title should read Core auto-updates setting?

[karmatosed]

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.

[aaroncampbell]

Updated heading and button text to match mock-up

[aaroncampbell]

Screenshot with 50907.3.diff (updated text)

[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.

[aaroncampbell]

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

[pbiron]

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.

[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?

[helen]

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 :)

Syncing patches for tests and review

Trac ticket: https://core.trac.wordpress.org/ticket/50907

[helen]

In 49254:

Upgrade/Install: Add UI for opting in to core auto-updates for major versions.

Props audrasjb, karmatosed, aaroncampbell, paaljoachim, davidbaumwald.
Fixes #50907.

[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.

[lukefiretoss]

Will there be a constant or filter to disable the WordPress major core updates UI settings?

[imath]

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.

See 50907-missing-form-closing-tag.patch

[aaroncampbell]

@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?

[davidbaumwald]

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.

[lukefiretoss]

@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.

[aaroncampbell]

@lukefiretoss Yep, for us as a managed host taking away that cap made sense and was something that was actually already in place.

[aaroncampbell]

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 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.

[lukefiretoss]

Some content explaining that unless plugins and themes are updated then any major WordPress core update could cause issues on the site.

[garrett-eclipse]

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.

[afragen]

I like that @garrett-eclipse

[SergeyBiryukov]

In 49274:

Upgrade/Install: Add missing </form> tag in auto-updates settings form.

Props imath, ahortin, dd32, afragen.
Fixes #51598. See #50907.

[paaljoachim]

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.

[aaroncampbell]

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.

[aaroncampbell]

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.

[aaroncampbell]

Recommended copy change

[garrett-eclipse]

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.

[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.

[aaroncampbell]

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.

[aaroncampbell]

In 49285:

Upgrade/Install: Improve copy for opt-in to automatic major version updates.

Props marybaum, kebbet.
See #50907.

[SergeyBiryukov]

In 49292:

Upgrade/Install: Account for new WP_AUTO_UPDATE_CORE values in auto-updates settings form.

This updates core_auto_updates_settings() to account for the new beta and rc values for the WP_AUTO_UPDATE_CORE constant.

Additionally, recognize these new values as acceptable in Site Health tests.

Follow-up to [48804], [49245], [49254].

Fixes #51319. See #50907.

[SergeyBiryukov]

In 49293:

Docs: Add missing duplicate hook references for allow_(dev|minor|major)_auto_core_updates filters.

Follow-up to [49254].

See #50907.

[desrosj]

Just noticed two conflicting strings. The notice displayed after saving shows "auto-updates" (plural), but the heading over the setting shows singular.

[audrasjb]

Core auto-updates: fix a small inconsistency between a notice and the section title.

[audrasjb]

Thanks @desrosj, 50907.5.diff fixes this small inconsistency.

[SergeyBiryukov]

In 49345:

Upgrade/Install: Adjust a string in core_auto_updates_settings() for consistency.

Props audrasjb, desrosj.
See #50907.

[hellofromTonya]

Closing as the ticket is done. needs-dev-note is already applied.

[karmatosed]

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.

[audrasjb]

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)

[karmatosed]

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.

[kebbet]

Feedback on copy: "my site" should be "this site", see comment 84.
Design drafts are missing heading and body for translations.

[audrasjb]

Hello everyone,
Just to share some information about the current state of this ticket. We are currently awaiting feedback from project lead before making the final patch for this feature.

[audrasjb]

Related: #51742