Cancel

Sarah Gooding

WordPress 5.6 to Add UI for Enabling Major Version Auto-Updates, Contributors Discuss Adding a Filter to Hide It

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_updates filter 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_core capability (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.

If you want to contribute to the conversation, check out the dev note on the new auto-updates interface for major versions and the Trac ticket for a filer that would hide the UI.

Category: ,
Tags: ,
7

7 responses to “WordPress 5.6 to Add UI for Enabling Major Version Auto-Updates, Contributors Discuss Adding a Filter to Hide It”

  1. Why does WordPress insist on forcing updates? Didn’t they learn anything about the forced alpha version update a few days ago?

    WordPress feels less and less like self-hosted blogging system and more like Windows 10, where the corporation behind it has total control of one’s PC.

    Create forum topic from comment

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

    I’d like to point out that this is not an accurate summary of my current stance as expressed on the ticket. From my comment:

    ” The update page is ONLY accessible to those WITH the update_core capability.

    It’s not that the users are unlikely to access the page with the new UI. It’s that this page is only accessible by Administrators (by default), and these users actually should be presented with this information.

    By default, only Administrators have this capability. If a site owner does not want auto-updates for major versions, then they should use the constant to enforce only minor updates (or none, if desired).

    Rather than allow this UI to be hidden entirely, I’m arguing that it would potentially be a better user experience to instead disable the form when auto-update behavior is being controlled by the constant and inform the user (who will always be a trusted individual because they have the update_core capability) of how the site will behave when new major and minor versions become available for auto-updating.

    Create forum topic from comment

  3. Could the note be dynamic, with three options? Read the current version (it’s stored as a variable somewhere), then add three options/checkboxes:
    – automatically update to 5.6 when it comes out.
    – automatically update to 5.5.4 when it comes out.
    – remember these settings after the next update.

    And a link to a wordpress.org post explaining the differences more fully.
    And only available to Admin users, of course.

    Create forum topic from comment

    • Something like that would actually make sense, including clear options for both major and minor updates and remembering the setting after one update or not. Could also use the text to explain major and minor, as in (assuming a start from 5.6, and checks representing defaults):
      [ ] automatically update to the next major version (5.7)
      [x] automatically update to the next minor version (5.6.1)
      [x] remember these settings after updating
      But, of course, since it’d make sense, not to mention also make it easier for users to get back more, it won’t happen.

      Create forum topic from comment

  5. Depending on how well the theme is coded and how the plugins are being kept up to date, I think it’s a great feature for website maintenance companies or for multiple site admins.

    I have already started using the auto-update feature for plugins and I’m always up to date (same day or next day updates), so it’s a pretty solid setup. Being a theme/plugin developer myself, I try to keep on top of all the plugins I’m using by always reading the changelogs and the upcoming (or deprecated) features. This way I’m not taken by surprise when a major update is due.

    Create forum topic from comment

  6. Auto-updates prevent site admins and site managers seeing any of the new benefits that are shipped with plugin and theme updates and they prevent them knowing whether security holes have been patched. This is a disservice to end users. How are site admins and site managers to know to check for data breaches or content graffiti? When plugins that integrate with 3rd party services are updated and they require new API keys or re-authorisation with 3rd party services, how do site admins and site managers know they need to act unless they get a notice to tell them?

    The auto-update needs a rethink before it’s universally enabled or before it’s generally available to be enabled.

    1) Website developers and site maintainers need a way to disable auto-updates through wp-config.
    2) Plugin and theme developers need a simple way to notify site admins of feature additions and security patches via an admin messages/notices page in the Dashboard. Not just a Dashboard notice but an inbox for admin notices.
    3) Changelogs need to be emailed to site admins and site maintainers.
    4) There needs to be a way to set the recipient of update notice emails (and error emails) in the site settings admin page.
    5) The system that checks whether a site is down needs to be external to WordPress core. This way the error messaging system will not be dependent on the functioning of WordPress core.

    I’m about 50/50 on whether auto-updates are a good idea. Maybe a little more against than for. I will be more comfortable with auto-updates when the feature has been given more thought. It’s a good idea but badly executed.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.