Rollback Auto-Update (Rollback part 3)

[afragen]

This is Rollback part 3. It began with move_dir() in WP 6.2 for part 1. Part 2 was completed with #51857 in WP 6.3. This brings us to part 3.

Part 3 is Rollback for auto-updates. When manually updating plugins if the plugin has a fatal error on reactivation, the plugin is prevented from reactivating. Unfortunately, during an auto-update, this reactivation check doesn't occur and the the next time the site runs users will see the WSOD.

Rollback Auto-Update performs a similar re-activation check and if there is a fatal error it is captured in an error handler and the previously installed plugin is restored. If this occurs an email will be sent notifying the site admin of the failed update and rollback.

After the rollback, the pending auto-updating for core and theme updates are restarted.

This code is currently running for everyone who has the ​Rollback Update Failure feature plugin installed.

I personally have been testing this using a plugin that will fatal if the update occurs. The plugin is on my test site, active, and set to auto-update. I have been running like this since the beginning of the year.

The PR is slightly different than the code in the feature plugin. Please test, run the feature plugin on your site, and review the code in the PR. Mostly give us your comments and feedback.

props @costdev and @pbiron for continuing code review, rubber ducking, and sanity checks.

This PR adds the rollback auto update functionality to core. This is already part of the ​Rollback Update Failure feature plugin.

This requires ​PR2225.

Trac ticket: https://core.trac.wordpress.org/ticket/58281#ticket

[mikeschroder]

Thanks everyone for your work on this!

I left a couple of questions / comments in a review on the PR.

I'm going to try to do some further manual testing, but I don't currently see any blockers for getting a first run of this committed into trunk so that we can get wider testing.

[peterwilsoncc]

I've tested ​the linked pull request on our old friend Chassis running on VirtualBox and am seeing some apparent timeouts.

I wrote up a mini-plugin to ​increase the frequency the update cron jobs run so I didn't need to wait twelve hours for each round of testing. This allowed me to use wp-cron.php for events to emulate real world circumstances.

I then installed the following plugins:

• akismet 4.1.10
• gutenberg 16.5.1
• jetpack 11.3.2
• mailpoet 4.0.1
• soliloquy-lite 2.5.2.8
• woocommerce 7.0.0
• wordpress-seo 19.7
• wpforms-lite 1.7.0

Running with the pull request checked out, the updates were failing with the setup mentioned above. Aksimet, Gutenberg and Jetpack would update but the rest of them would fail to upgrade.

As the upgrade failed, no email notification was sent and the auto_updater.lock option would stay in the database preventing the next run from completing.

I am wondering if the PHP request is timing out. In wp-cron.php, one of the first things that runs is ​fast-finish code to prevent the requests from blocking sites. I am wondering if this is preventing the timeout from being extended when the updates begin running.

The biggest concern when plugins update automatically is that they may contain a fatal error that crashes a website.

This performs two loopback requests, one to the dashboard, and one to the homepage, in an attempt to detect such fatal errors.

Should a fatal error be detected, the update is restored to the previously installed version.

@costdev and I have been testing all combinations of plugins, fataling plugin, and themes with this, even @peterwilsoncc's list of plugins.

It tests out great!

Closing in favor of ​https://github.com/WordPress/wordpress-develop/pull/5287

[peterwilsoncc]

@costdev @afragen I tested the ​refreshed PR with the list of plugins I included in comment #14

With the plugins inactive, the updates ran successfully and I got the auto update email.

With the plugins active, it appears to have stalled after the WooCommerce update and I did not get the auto update email and the auto_updater.lock option remains. wordpress-seo and wpforms-lite were not updated.

With the plugins active I get 190ish queries on the plugins admin screen so it makes sense that being active may cause problems as the site is doing a lot more work than while they are inactive.

The backups of the successfully updated plugins remain in the upgrade-temp-backup/plugins folder.

As usual, this is testing on VirtualBox (using ​Chassis).

[afragen]

@peterwilsoncc I've run this using all of your plugins and several others, 14 in total including 2 plugins that will throw fatal errors.

My runs on LocalWP and the WP docker env have both been successful and the upgrade-temp-backups/plugins is empty.

Perhaps it's the method you use to help trigger the update? On LocalWP I'm able to use @costdev's cli-force-auto-updates.php plugin. On Docker I use npm run env:cli cron event run wp_version_check.

[costdev]

With additional testing, issues were reproduced.

Issues occur when browsing the site during an auto-update, and investigation is ongoing to find a solution. We'll continue work and try again for WordPress 6.5.

Thanks to all for your work and interest in Rollback Auto Update so far!

[mikeschroder]

Thanks so much @costdev @afragen @peterwilsoncc and everyone who has been working on and testing this feature.

I agree that given the regression in updates (updates not happening that would have succeeded) with the feature applied, and Beta 1 today/tomorrow, it makes sense to punt this to 6.5.

I'm planning to continue to follow this, and happy to help out in 6.5!