Posted on

Help Test the Rollback Update Failure Feature Plugin Ahead of WordPress 6.1

“Life-buoy in harbour” by Ashley Coates is licensed under CC BY-NC-SA 2.0.

The developers of the Rollback Update Failure feature plugin put out a call for testing over the weekend, with the aim of getting it included in WordPress 6.1. The goal of the plugin is to offer a safety mechanism in core for when updates or auto-updates fail. Instead of leaving the user’s site in a broken state, the rollback update failure feature will restore the site to a usable state.

Successful updates are the default experience for most WordPress users. The auto-updates team embraced the challenge of creating a fallback for users who experience the most common issues with updates, which include having a plugin folder’s content be get deleted and the plugin being no longer active, along with the scenario where a plugin cannot completely update, resulting in a PHP fatal message or “white screen of death.”

For the past 19 months, Andy Fragen, Colin Stewart, and Paul Biron have been leading development and testing. They settled on a solution that is awaiting feedback from core committers.

“It was determined that copying the current plugin to an alternate location and in the event of an update failure, copying it back into wp-content/plugins, would be the least resource intensive method,” Fragen said. “This does require one additional plugin copying operation and two if there is a update failure.”

The auto-updates team needs broad testing and feedback from people using different hosting companies at all price ranges. The process involves setting up a test environment with the WordPress Beta Tester plugin set to Bleeding edge and Nightlies, and the Rollback Update Failure plugin installed. Testers will then download old versions of a bunch of plugins and test single and bulk updates. A filter is available for forcing an update failure. Testers will be asked to record the time required to perform plugin updates.

More testing details and instructions are available in the call for testing post, with a few example results in the comments for reference. If the feature plugin gets enough broad testing, it may finally have the right timing and momentum to be committed for WordPress 6.1.

Posted on

WordPress 5.6 Beta 4 Delayed, Auto-Updates Implementation Changed

Earlier today, release lead Josepha Haden announced the team was pushing back the release of WordPress 5.6 Beta 4 to Thursday, November 12. The beta release was slated to go live today. Questions around the readiness of the auto-updates feature held the beta update back. However, those questions are now resolved.

Haden followed up the Beta 4 announcement with a more in-depth picture of how auto-updates will change for WordPress 5.6. She summarized the current concerns, laid out a path for version 5.6 and 5.7, and discussed plans for the future. The auto-updates feature is not something that will be complete overnight or in just one release. There are complex technical hurdles that must be jumped and a need for a dedicated focus in upcoming releases.

Much of her post focuses on the tactics going forward. However, she mentioned in our chat that she does not want the community to lose sight of the big-picture, vision-setting aspects of the project.

“The subject of auto-updates has resulted in many complicated discussions,” she wrote. “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.”

The short-term plan is to allow current WordPress users to opt-in to major updates while enabling auto-updates for both minor and major releases for new installations. Some changes to the auto-updates UI are also in the works along with a plan to revise based on feedback in WordPress 5.6.1.

In WordPress 5.7, which is several months away, the goal is to add a nudge on the Site Health screen for anyone opted out of major updates. We could also see a setting to opt-into updates as part of the WordPress installation flow for new sites.

The big picture that Haden is talking about? That is to make sure that all WordPress installations are receiving auto-updates, that these updates are seamless, and that users are running a secure version of WordPress.

Nearly two years ago, WordPress project lead Matt Mullenweg outlined nine goals for 2019. One of those goals was to provide users a method of opting into automatic updates of major releases. It has taken WordPress a while to get there, but it is on the cusp of launching this feature that many have looked forward to.

Haden also further clarified that goal. She said that the long-term plan for both Mullenweg and the other original feature contributors was to always have auto-updates for major releases enabled by default.

Apart from those who already prefer to opt-out of any sort of automatic updates, some users’ trust in the system eroded a couple of weeks ago. The WordPress auto-update system updated sites to version 5.5.3-alpha instead of 5.5.2 — WordPress currently automatically updates only minor releases. While there was no difference between the two versions and the core team quickly resolved the problem, the damage to user trust was already done.

This was not an ideal leadup to the December launch of auto-updates for major releases.

However, one hiccup — one that was effectively not an issue — seven years after WordPress 3.7 launched with security and maintenance updates is not too bad. The system has been a boon to making the web a more secure place. Ultimately, that is what auto-updates are all about. The big goal is to make sure that all WordPress sites are running on the most secure version available.

“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,” wrote Haden. “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.”

Posted on

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.

Posted on

Pantheon Acquires Visual Regression Testing Platform StagingPilot

Panethon, a managed host geared towards Drupal and WordPress sites, has acquired StagingPilot. Financial details of the deal were not disclosed. Nathan Tyler, founder of StagingPilot, and his brother Phil Tyler will be brought into the company.

StagingPilot is a four year old company that runs a barrage of visual regression tests on WordPress sites before they’re automatically updated.

StagingPilot creates a copy of the site and places it into a staging environment. The service then conducts a number of tests that include, checking for visual errors, a white screen of death, and elements on a page disappearing. A number of snapshots are created along with a detailed report on the errors that are discovered.

Josh Koenig, Co-Founder and Head of Product at Pantheon, says the acquisition puts the company within reach of the ‘Holy Grail’ of WebOps.

“Once you have a hundred sites (or heck, even twenty), the grind of keeping up with routine updates can be daunting,” Koenig said. “Our existing WebOps tools let our customers automate a lot of that maintenance, but building and managing that automation is on them. We want our users to automate their operations, not operate their automation.”

Pantheon plans to integrate StagingPilot into its offerings in three phases. First, it will migrate StagingPilot’s technology into its existing managed updates feature and extend it beyond WordPress to support Drupal.

Then, the company plans to fully integrate the service with its organizational features providing substantial benefits to agency partners or those who manage many sites.

The third phase looks to take advantage of services such as Google’s applied learning machines to create AI-driven testing.

Out-of-the box, WordPress only updates minor versions automatically and leaves major updates, plugins, and themes up to the user. One of the most common fears of enabling auto-updates is having something on the site break.

Often, the process of testing updates is left up to the consultant or whoever manages the site. Depending on the size or number of sites being managed, it can become a major time suck.

Hosting companies like Pantheon with StagingPilot, LiquidWeb, and others are easing the fear of auto updates in general and saving people a lot of time by using automatic visual regression testing.

To learn more about StagingPilot and to see Nathan demo the service in-person, check out this episode of WPshowandtell hosted by Jason Tucker.