WP5.6 | Auto-Update Implementation Change

Hey Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org.! Last week in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. there was a lively (and lengthy) discussion on the auto-updates UIUI User interface (transcript). This post summarizes the discussion and most reasonable options for moving forward, considering timing, availability, and level of effort for suggested changes.

Summarized Concerns

  • Is this implementation aligned with our long term goals: to have auto-updates widely available in order to increase the collective health of all WordPress sites, minimize the maintenance burden for users, and have greater security across the entire ecosystem.
  • Is this implementation aligned with our short term goals: to continue our existing progress around auto-updates for minor releases, plugins, and themes.
  • A desire to avoid reverting elements of the UI and auto-updates after the release.
  • There were a vast array of concerns around the implementation.

Path Forward

One of the clearest things that came up in the conversation during coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat is that this is a complex technical task, and there will be a need for some long term, dedicated time to keep driving this work forward. Specifically, there is a shared concern that there is a technically non-trivial combination of reassurance and repair features that need to be defined and executed on and will need a dedicated product owner (transcript).

This Release and Next

  • WP5.6: Provide some updates to the design of the UI.
  • WP5.6: For existing installations, the behavior will remain the same as it is today: opted-in to minor updates by default, but a user must opt-in to major updates (constants and filters that are already in use by hosts or agencies will still take precedence).
  • WP5.6: For new installations, default behavior will change: opted-in to minor updates by default and opted-in to major updates by default.
  • WP5.6.1: Revisit the UI to revise based on feedback.
  • WP5.7Add a nudge on the Site Health screen for anyone opted out of major updates.
  • WP5.7Add auto-updates opt-in to installation flow.

Future Release Suggestions

  1. WP5.x: Add a nudge to opt-in on the updates page and a path to opt-out on Site Health.
  2. WP5.x: In a future release, have a renewal flow after a certain period of time.

Planning for the Future

The subject of auto-updates has resulted in many complicated discussions. As I reminded the release squad, decisions like these require us to remember that we’re contributing to over 30% of the web, and we have to balance our immediate needs with long term planning.

It’s important that whatever we implement isn’t taking us further away from our long term goals of having seamless, auto-updates across the project. Auto-updates can help us have a more secure WordPress ecosystem, and in turn can help change the public perception of WordPress being an unsecure choice for users of any skill level.

To provide some clarification on the nine project goals set out in 2019, the wording there is specific about implementing “opt-in to automatic updates of major Core releases”. However, the long term goal (for Matt as well as many of the contributors to WP3.7) was to have all installations opted-in to auto-updates of WordPress core by default, and that is still the long term goal.

Props to the WordPress 5.6 release squad for bringing such care to this discussion, and to @helen for helping me on the implementation wording. Special thanks to @audrasjb and @davidbaumwald for editing, and @andreamiddleton, @daisyo, and @cbringmann for proofreading!

#5-6, #auto-updates