Opened 5 months ago
Last modified 4 days ago
#58281 assigned enhancement
Rollback Auto-Update (Rollback part 3)
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.5 | Priority: | normal |
Severity: | normal | Version: | 6.3 |
Component: | Upgrade/Install | Keywords: | has-patch dev-feedback needs-testing |
Focuses: | Cc: |
Description (last modified by )
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.
Change History (24)
This ticket was mentioned in PR #3958 on WordPress/wordpress-develop by @afragen.
5 months ago
#1
This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.
5 months ago
This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.
3 months ago
This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.
3 months ago
This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.
2 months ago
This ticket was mentioned in Slack in #core-committers by afragen. View the logs.
3 weeks ago
This ticket was mentioned in Slack in #core by oglekler. View the logs.
2 weeks ago
#11
@
2 weeks ago
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.
This ticket was mentioned in Slack in #core by oglekler. View the logs.
9 days ago
This ticket was mentioned in Slack in #core-test by oglekler. View the logs.
9 days ago
#14
@
8 days ago
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.
This ticket was mentioned in PR #5287 on WordPress/wordpress-develop by @costdev.
7 days ago
#15
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.
7 days ago
#16
@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!
7 days ago
#17
Closing in favor of https://github.com/WordPress/wordpress-develop/pull/5287
This ticket was mentioned in Slack in #hosting by javier. View the logs.
6 days ago
#19
@
5 days ago
@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).
This ticket was mentioned in Slack in #core-upgrade-install by peterwilsoncc. View the logs.
5 days ago
#21
@
4 days ago
@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
.
This ticket was mentioned in Slack in #core by oglekler. View the logs.
4 days ago
#23
@
4 days ago
- Milestone changed from 6.4 to 6.5
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!
#24
@
4 days ago
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!
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