WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 4 weeks ago

Last modified 3 weeks ago

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

first-exploration-enable-auto-updates.png (87.8 KB) - added by audrasjb 4 months ago.
First exploration: Enable auto-updates
first-exploration-disable-auto-updates.png (86.2 KB) - added by audrasjb 4 months ago.
First exploration: Disable (previously enabled auto-updates
Auto-update-WP-core.jpg (212.6 KB) - added by paaljoachim 3 months ago.
Enable auto updates for WordPress
Enable-auto-updates-of-WordPress.jpg (536.9 KB) - added by paaljoachim 3 months ago.
An adjustment.
enable-auto-updates-of-WordPress-updates-screen-checkbox.jpg (276.1 KB) - added by paaljoachim 2 months ago.
Another suggestion. This with a checkbox.
Next-WordPress-release-auto-update.jpg (91.6 KB) - added by paaljoachim 2 months ago.
A new suggestion giving the user the option when or if to automatically update to the next WordPress release.
Auto-updates-of-WordPress-option1.jpg (92.6 KB) - added by paaljoachim 2 months ago.
Option 1.
Auto-updates-of-WordPress-option2.jpg (91.6 KB) - added by paaljoachim 2 months ago.
Option 2.
Core-Auto-Updates-1.jpg (90.5 KB) - added by paaljoachim 2 months ago.
Core Auto Updates 1 - with a submit button.
Core-Auto-Updates-2.jpg (89.2 KB) - added by paaljoachim 2 months ago.
Core Auto Updates 2 - with a submit button
Core-Auto-Updates-General-Settings-1.jpg (109.1 KB) - added by paaljoachim 2 months ago.
Mockup of adding Core Updates 1 settings to Settings -> General screen.
Core-Auto-Updates-General-Settings-2.jpg (107.5 KB) - added by paaljoachim 2 months ago.
Mockup of adding Core Updates settings version 2 to Settings -> General screen.
50907.diff (4.0 KB) - added by audrasjb 7 weeks ago.
First technical implementation
Capture d’écran 2020-10-08 à 01.46.22.png (364.4 KB) - added by audrasjb 7 weeks ago.
First technical implementation screenshot
50907.1.diff (30.8 KB) - added by audrasjb 6 weeks ago.
New iteration based on what we shared with @karmatosed
screencapture-localhost-8888-wordpress-develop-wordpress-develop-build-wp-admin-update-core-php-2020-10-15-12_50_56.png (494.3 KB) - added by audrasjb 6 weeks ago.
New screen (including section margins)
screencapture-localhost-8888-wordpress-develop-wordpress-develop-build-wp-admin-update-core-php-2020-10-15-12_49_28.png (509.3 KB) - added by audrasjb 6 weeks ago.
Notice after saving auto-updates settings
screencapture-jeanbaptisteaudras-grimpe-wp-admin-update-core-php-2020-10-15-13_06_49.png (370.2 KB) - added by audrasjb 6 weeks ago.
Use case: there is an available Core Update
Currrent thinking.png (102.8 KB) - added by karmatosed 6 weeks ago.
Blue sky idea: copy not to be taken as final
2020-10-15 at 15.14.png (15.9 KB) - added by karmatosed 6 weeks ago.
50907.2.diff (6.0 KB) - added by helen 6 weeks ago.
Patch refresh attempt, manual diff editing
50907.png (11.6 KB) - added by aaroncampbell 5 weeks ago.
Screenshot with 50907.2.diff
50907.3.diff (5.9 KB) - added by aaroncampbell 5 weeks ago.
Updated heading and button text to match mock-up
50907.2.png (9.9 KB) - added by aaroncampbell 5 weeks ago.
Screenshot with 50907.3.diff (updated text)
50907-missing-form-closing-tag.patch (417 bytes) - added by imath 5 weeks ago.
Screen Shot 2020-10-21 at 3.58.28 PM.png (187.5 KB) - added by garrett-eclipse 5 weeks 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.
50907.4.diff (629 bytes) - added by aaroncampbell 5 weeks ago.
Recommended copy change
Screen Shot 2020-10-27 at 15.43.27.png (51.7 KB) - added by desrosj 4 weeks ago.
50907.5.diff (494 bytes) - added by audrasjb 4 weeks ago.
Core auto-updates: fix a small inconsistency between a notice and the section title.
one.png (136.2 KB) - added by karmatosed 3 weeks ago.
two.png (121.0 KB) - added by karmatosed 3 weeks ago.
3.png (136.7 KB) - added by karmatosed 3 weeks ago.

Change History (134)

#1 @pbiron
4 months ago

  • Keywords needs-design added

This ticket was mentioned in Slack in #core by sergey. View the logs.


4 months ago

@audrasjb
4 months ago

First exploration: Enable auto-updates

@audrasjb
4 months ago

First exploration: Disable (previously enabled auto-updates

#3 @audrasjb
4 months 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 @whyisjake
3 months 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.


3 months ago

#6 @jnylen0
3 months 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: @JoshuaWold
3 months 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.


3 months ago

#9 in reply to: ↑ 7 @pbiron
3 months 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).

Last edited 3 months ago by pbiron (previous) (diff)

@paaljoachim
3 months ago

Enable auto updates for WordPress

#10 @pbiron
3 months ago

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/

#11 @paaljoachim
3 months 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.

Last edited 3 months ago by paaljoachim (previous) (diff)

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


3 months ago

#13 @hellofromTonya
3 months 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.


3 months ago

#15 @johnbillion
3 months ago

  • Version changed from trunk to 5.5

#16 @karmatosed
3 months ago

  • Keywords needs-design-feedback added; needs-design removed

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


2 months ago

#18 @karmatosed
2 months 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.

#19 @karmatosed
2 months ago

  • Keywords needs-design added; needs-design-feedback removed

This ticket was mentioned in Slack in #core-auto-updates by audrasjb. View the logs.


2 months ago

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


2 months ago

@paaljoachim
2 months ago

Another suggestion. This with a checkbox.

#22 @paaljoachim
2 months 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.

Last edited 2 months ago by paaljoachim (previous) (diff)

#23 @dd32
2 months 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
Last edited 2 months ago by dd32 (previous) (diff)

#24 @johnbillion
2 months 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.

@paaljoachim
2 months ago

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

#25 @audrasjb
2 months 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 @audrasjb
2 months 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.


2 months ago

This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.


2 months ago

This ticket was mentioned in Slack in #core-editor by pbiron. View the logs.


2 months ago

#30 @paaljoachim
2 months 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.


2 months ago

#32 follow-up: @carike
2 months 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).

@paaljoachim
2 months ago

Core Auto Updates 1 - with a submit button.

@paaljoachim
2 months ago

Core Auto Updates 2 - with a submit button

@paaljoachim
2 months ago

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

@paaljoachim
2 months ago

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

#33 @paaljoachim
2 months 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

Last edited 2 months ago by paaljoachim (previous) (diff)

This ticket was mentioned in Slack in #core-auto-updates by paaljoachim. View the logs.


2 months ago

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 months ago

#36 in reply to: ↑ 32 @davidbaumwald
2 months 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 @dd32
2 months 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.


7 weeks ago

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


7 weeks ago

@audrasjb
7 weeks ago

First technical implementation

@audrasjb
7 weeks ago

First technical implementation screenshot

#40 @audrasjb
7 weeks 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

Last edited 7 weeks ago by audrasjb (previous) (diff)

#41 @karmatosed
7 weeks 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.


7 weeks ago

This ticket was mentioned in Slack in #core-auto-updates by audrasjb. View the logs.


6 weeks ago

This ticket was mentioned in Slack in #core-auto-updates by karmatosed. View the logs.


6 weeks ago

#45 @davidbaumwald
6 weeks ago

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
6 weeks ago

New iteration based on what we shared with @karmatosed

#46 @karmatosed
6 weeks 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.

http://cldup.com/o41SMRKM0K.png

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:

http://cldup.com/vcQ7J70Tgd.png

Last edited 6 weeks ago by karmatosed (previous) (diff)

This ticket was mentioned in Slack in #core-auto-updates by karmatosed. View the logs.


6 weeks ago

@karmatosed
6 weeks ago

Blue sky idea: copy not to be taken as final

#48 @audrasjb
6 weeks 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 @karmatosed
6 weeks 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 @aaroncampbell
6 weeks 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.


6 weeks ago

#52 @helen
6 weeks ago

  • Type changed from enhancement to task (blessed)

#53 @hellofromTonya
6 weeks ago

  • Keywords needs-refresh added

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

@helen
6 weeks ago

Patch refresh attempt, manual diff editing

#54 @aaroncampbell
5 weeks 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.


5 weeks ago

@aaroncampbell
5 weeks ago

Screenshot with 50907.2.diff

#56 @afragen
5 weeks ago

Perhaps title should read Core auto-updates setting?

#57 @karmatosed
5 weeks 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.

@aaroncampbell
5 weeks ago

Updated heading and button text to match mock-up

@aaroncampbell
5 weeks ago

Screenshot with 50907.3.diff (updated text)

#58 follow-up: @afragen
5 weeks 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 @aaroncampbell
5 weeks 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 @pbiron
5 weeks 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: @pbiron
5 weeks 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.


5 weeks ago

#63 in reply to: ↑ 61 @helen
5 weeks 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.


5 weeks ago

Syncing patches for tests and review

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

#65 @helen
5 weeks ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 49254:

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

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

#66 @helen
5 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#67 follow-up: @kebbet
5 weeks 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 @lukefiretoss
5 weeks ago

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

#69 @imath
5 weeks 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.

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

#70 @aaroncampbell
5 weeks 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 @davidbaumwald
5 weeks 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: @lukefiretoss
5 weeks 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 @aaroncampbell
5 weeks 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 @aaroncampbell
5 weeks 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 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.

Last edited 5 weeks ago by aaroncampbell (previous) (diff)

#75 @lukefiretoss
5 weeks 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.


5 weeks ago

@garrett-eclipse
5 weeks 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.

#77 @afragen
5 weeks ago

I like that @garrett-eclipse

#78 @SergeyBiryukov
5 weeks ago

In 49274:

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

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

#79 @paaljoachim
5 weeks 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 @aaroncampbell
5 weeks 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 @aaroncampbell
5 weeks 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.

@aaroncampbell
5 weeks ago

Recommended copy change

#82 @garrett-eclipse
5 weeks 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: @kebbet
5 weeks 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 @aaroncampbell
5 weeks 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.

#85 @aaroncampbell
5 weeks ago

In 49285:

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

Props marybaum, kebbet.
See #50907.

#87 @SergeyBiryukov
5 weeks ago

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.

#88 @SergeyBiryukov
5 weeks ago

In 49293:

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

Follow-up to [49254].

See #50907.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


4 weeks ago

#90 @desrosj
4 weeks ago

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

@audrasjb
4 weeks ago

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

#91 @audrasjb
4 weeks ago

  • Keywords needs-dev-note added

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

#92 @SergeyBiryukov
4 weeks ago

In 49345:

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

Props audrasjb, desrosj.
See #50907.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


4 weeks ago

This ticket was mentioned in Slack in #core-auto-updates by hellofromtonya. View the logs.


4 weeks ago

#95 @hellofromTonya
4 weeks 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.


3 weeks ago

#97 @karmatosed
3 weeks 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.

@karmatosed
3 weeks ago

@karmatosed
3 weeks ago

#98 @audrasjb
3 weeks 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.


3 weeks ago

#100 @karmatosed
3 weeks 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.

@karmatosed
3 weeks ago

#101 @kebbet
3 weeks ago

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

#102 @audrasjb
3 weeks ago

  • Keywords commit removed

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.

Note: See TracTickets for help on using tickets.