Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#50907 closed task (blessed) (fixed)

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

Reported by: whyisjake's profile whyisjake Owned by: audrasjb's profile 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 years ago.
First exploration: Enable auto-updates
first-exploration-disable-auto-updates.png (86.2 KB) - added by audrasjb 4 years ago.
First exploration: Disable (previously enabled auto-updates
Auto-update-WP-core.jpg (212.6 KB) - added by paaljoachim 4 years ago.
Enable auto updates for WordPress
Enable-auto-updates-of-WordPress.jpg (536.9 KB) - added by paaljoachim 4 years ago.
An adjustment.
enable-auto-updates-of-WordPress-updates-screen-checkbox.jpg (276.1 KB) - added by paaljoachim 4 years ago.
Another suggestion. This with a checkbox.
Next-WordPress-release-auto-update.jpg (91.6 KB) - added by paaljoachim 4 years 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 4 years ago.
Option 1.
Auto-updates-of-WordPress-option2.jpg (91.6 KB) - added by paaljoachim 4 years ago.
Option 2.
Core-Auto-Updates-1.jpg (90.5 KB) - added by paaljoachim 4 years ago.
Core Auto Updates 1 - with a submit button.
Core-Auto-Updates-2.jpg (89.2 KB) - added by paaljoachim 4 years ago.
Core Auto Updates 2 - with a submit button
Core-Auto-Updates-General-Settings-1.jpg (109.1 KB) - added by paaljoachim 4 years 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 4 years ago.
Mockup of adding Core Updates settings version 2 to Settings -> General screen.
50907.diff (4.0 KB) - added by audrasjb 4 years ago.
First technical implementation
Capture d’écran 2020-10-08 à 01.46.22.png (364.4 KB) - added by audrasjb 4 years ago.
First technical implementation screenshot
50907.1.diff (30.8 KB) - added by audrasjb 4 years 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 4 years 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 4 years 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 4 years ago.
Use case: there is an available Core Update
Currrent thinking.png (102.8 KB) - added by karmatosed 4 years ago.
Blue sky idea: copy not to be taken as final
2020-10-15 at 15.14.png (15.9 KB) - added by karmatosed 4 years ago.
50907.2.diff (6.0 KB) - added by helen 4 years ago.
Patch refresh attempt, manual diff editing
50907.png (11.6 KB) - added by aaroncampbell 4 years ago.
Screenshot with 50907.2.diff
50907.3.diff (5.9 KB) - added by aaroncampbell 4 years ago.
Updated heading and button text to match mock-up
50907.2.png (9.9 KB) - added by aaroncampbell 4 years ago.
Screenshot with 50907.3.diff (updated text)
50907-missing-form-closing-tag.patch (417 bytes) - added by imath 4 years ago.
Screen Shot 2020-10-21 at 3.58.28 PM.png (187.5 KB) - added by garrett-eclipse 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.
50907.4.diff (629 bytes) - added by aaroncampbell 4 years ago.
Recommended copy change
Screen Shot 2020-10-27 at 15.43.27.png (51.7 KB) - added by desrosj 4 years ago.
50907.5.diff (494 bytes) - added by audrasjb 4 years ago.
Core auto-updates: fix a small inconsistency between a notice and the section title.
one.png (136.2 KB) - added by karmatosed 4 years ago.
two.png (121.0 KB) - added by karmatosed 4 years ago.
3.png (136.7 KB) - added by karmatosed 4 years ago.

Change History (134)

#1 @pbiron
4 years ago

  • Keywords needs-design added

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


4 years ago

@audrasjb
4 years ago

First exploration: Enable auto-updates

@audrasjb
4 years ago

First exploration: Disable (previously enabled auto-updates

#3 @audrasjb
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 @whyisjake
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 @jnylen0
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: @JoshuaWold
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 @pbiron
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).

Last edited 4 years ago by pbiron (previous) (diff)

@paaljoachim
4 years ago

Enable auto updates for WordPress

#10 @pbiron
4 years 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
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.

Last edited 4 years ago by paaljoachim (previous) (diff)

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


4 years ago

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

#15 @johnbillion
4 years ago

  • Version changed from trunk to 5.5

#16 @karmatosed
4 years ago

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

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


4 years ago

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

#19 @karmatosed
4 years ago

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

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

@paaljoachim
4 years ago

Another suggestion. This with a checkbox.

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

Last edited 4 years ago by paaljoachim (previous) (diff)

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

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

@paaljoachim
4 years ago

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

#25 @audrasjb
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 @audrasjb
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 @paaljoachim
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: @carike
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).

@paaljoachim
4 years ago

Core Auto Updates 1 - with a submit button.

@paaljoachim
4 years ago

Core Auto Updates 2 - with a submit button

@paaljoachim
4 years ago

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

@paaljoachim
4 years ago

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

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

Last edited 4 years ago by paaljoachim (previous) (diff)

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 @davidbaumwald
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 @dd32
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

@audrasjb
4 years ago

First technical implementation

@audrasjb
4 years ago

First technical implementation screenshot

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

Last edited 4 years ago by audrasjb (previous) (diff)

#41 @karmatosed
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 @davidbaumwald
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_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
4 years ago

New iteration based on what we shared with @karmatosed

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

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 4 years ago by karmatosed (previous) (diff)

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


4 years ago

@karmatosed
4 years ago

Blue sky idea: copy not to be taken as final

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

#52 @helen
4 years ago

  • Type changed from enhancement to task (blessed)

#53 @hellofromTonya
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.

@helen
4 years ago

Patch refresh attempt, manual diff editing

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

@aaroncampbell
4 years ago

Screenshot with 50907.2.diff

#56 @afragen
4 years ago

Perhaps title should read Core auto-updates setting?

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

@aaroncampbell
4 years ago

Updated heading and button text to match mock-up

@aaroncampbell
4 years ago

Screenshot with 50907.3.diff (updated text)

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

#65 @helen
4 years 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
4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

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

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

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

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

Version 0, edited 4 years ago by aaroncampbell (next)

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

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

#77 @afragen
4 years ago

I like that @garrett-eclipse

#78 @SergeyBiryukov
4 years 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
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 @aaroncampbell
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 @aaroncampbell
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.

@aaroncampbell
4 years ago

Recommended copy change

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

#85 @aaroncampbell
4 years ago

In 49285:

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

Props marybaum, kebbet.
See #50907.

#87 @SergeyBiryukov
4 years 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
4 years 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 years ago

#90 @desrosj
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.

@audrasjb
4 years ago

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

#91 @audrasjb
4 years ago

  • Keywords needs-dev-note added

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

#92 @SergeyBiryukov
4 years 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 years ago

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


4 years ago

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

@karmatosed
4 years ago

@karmatosed
4 years ago

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

@karmatosed
4 years ago

#101 @kebbet
4 years ago

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

#102 @audrasjb
4 years 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.