WordPress 5.6 is set to add a UI that allows users to opt into auto-updates for major versions of core. Previously, developers could turn these updates on by setting the
WP_AUTO_UPDATE_CORE constant to
true or by using the
allow_major_auto_core_updates filter. Version 5.6 exposes this setting in the UI to make it more accessible for users.
Jb Audras posted a dev note on the feature yesterday with instructions for how developers can extend it to add more options.
A previous version of this UI specified that the setting refers to major versions:
Keep my site up-to-date with regular feature updates (major versions).
This was changed 11 days ago to remove the wording that tells users which versions the setting controls.
“The idea was to make the wording more general, and maybe easier to understand,” Jb Audras said. “As minor updates are already automatically updated (since 3.7), new users may not understand what is behind the ‘major versions’ term.”
This new wording makes the setting unclear. Users may not understand what “major versions” are but “feature updates” is even less clear. Does it include updates to existing features? Or only the introduction of brand new features? A better option might be to link “major versions” to documentation on HelpHub.
In the current climate, where positive sentiment regarding auto-updates is declining, shipping the new UI with a nebulous term like “feature updates” is not going to inspire as much confidence as explicitly identifying what updates the setting controls.
Audras said he is open to having the wording changed but that so far those testing the beta don’t seem to have a problem with it. String freeze is scheduled for November 10, and after that no more wording updates can be committed.
Contributors are also discussing adding a filter that would allow developers to hide the auto-updates UI for major versions. Mike Schroder noted that this would be especially useful for hosting companies that are handling updates in a different way. Some developers or agencies may want to use the filter to prevent their clients from turning auto-updates on for major versions.
Core Committer Jonathan Desrosiers said he is not in favor of using a filter to hide the UI on a page that is not likely to be accessed by users who have the ability to update core:
If that change is made (disabling the form when the constant is defined or
allow_major_auto_core_updatesfilter is used), then I am not sure the UI should ever be hidden. As raised by @aaroncampbell in today’s weekly meeting, the update page is only accessible to those with the
update_corecapability (trusted users). While there may be valid use cases for wholesale hiding the new feature, I haven’t seen one yet. To me, disabling the form and explaining why the form cannot be used to update the desired behavior is more valuable to the site owner, as they would be better equipped to make an adjustment.