Make WordPress Core

Opened 12 months ago

Last modified 9 hours ago

#58281 assigned enhancement

Rollback Auto-Update (Rollback part 3)

Reported by: afragen's profile afragen Owned by: afragen's profile afragen
Milestone: 6.6 Priority: normal
Severity: normal Version: 6.3
Component: Upgrade/Install Keywords: has-patch dev-feedback needs-testing has-testing-info early
Focuses: Cc:

Description (last modified by 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.

Change History (40)

This ticket was mentioned in PR #3958 on WordPress/wordpress-develop by @afragen.


12 months ago
#1

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

This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.


12 months ago

#3 @afragen
12 months ago

  • Owner set to afragen
  • Status changed from new to assigned

This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.


10 months ago

#5 @afragen
10 months ago

  • Description modified (diff)

#6 @SergeyBiryukov
10 months ago

  • Milestone changed from Awaiting Review to 6.4

This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.


10 months ago

This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.


9 months ago

This ticket was mentioned in Slack in #core-committers by afragen. View the logs.


8 months ago

This ticket was mentioned in Slack in #core by oglekler. View the logs.


7 months ago

#11 @kirasong
7 months 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.


7 months ago

This ticket was mentioned in Slack in #core-test by oglekler. View the logs.


7 months ago

#14 @peterwilsoncc
7 months 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 months 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.

@afragen commented on PR #5287:


7 months 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!

This ticket was mentioned in Slack in #hosting by javier. View the logs.


7 months ago

#19 @peterwilsoncc
7 months 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.


7 months ago

#21 @afragen
7 months 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.

Last edited 7 months ago by afragen (previous) (diff)

This ticket was mentioned in Slack in #core by oglekler. View the logs.


7 months ago

#23 @costdev
7 months 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 @kirasong
7 months 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 ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.


6 months ago

This ticket was mentioned in Slack in #core-upgrade-install by afragen. View the logs.


6 months ago

This ticket was mentioned in Slack in #core by afragen. View the logs.


6 months ago

This ticket was mentioned in Slack in #core-upgrade-install by pbiron. View the logs.


5 months ago

This ticket was mentioned in Slack in #core by afragen. View the logs.


5 months ago

#30 @annezazu
3 months ago

Checking in here as we're less than a month out from beta 1. Is this still slated for 6.5? I want to ensure it's covered for testing if so.

#31 @costdev
3 months ago

@annezazu Thanks for checking in!

Yes the feature is still slated for 6.5. Unfortunately, I've been snowed under with agency work and haven't had time to circle back. In the Upgrade/Install Slack channel, I've reached out to other committers to see if they might have bandwidth to take a look at the PR.

With eyes and possible input from more committers, this feature can absolutely land in 6.5.

#32 @swissspidy
3 months ago

There hasn't been any traction here recently and beta 1 is only a week away. Do you perhaps want to raise this in dev chat, maybe with some testing instructions?

#33 @costdev
3 months ago

@swissspidy Thanks for flagging the lack of updates posted on the ticket!

There were additional rounds of testing done after I reached out in Slack. @peterwilsoncc will also be doing additional testing today. Let's wait and see if Peter finds any issues and see how this feature looks for getting into Beta 1.

#34 @costdev
3 months ago

  • Keywords has-testing-info added

Testing instructions can be found here.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 months ago

#36 @swissspidy
2 months ago

  • Keywords early added
  • Milestone changed from 6.5 to 6.6

No traction here since testing instructions were added.

Let's ensure we get this in early in 6.6 instead!

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-upgrade-install by afragen. View the logs.


12 days ago

#39 @audrasjb
9 hours ago

Thanks for the great work on this feature!
I added a few comments in the PR :)

#40 @audrasjb
9 hours ago

Thanks for the detailed testing infos!

I tested the PR with the this-plugin-should-not-be-used plugin and the rollback works as expected and the upgrade-temp-backup is empty at the end of the process.

I also tested the PR with a plugin located on custom repositories (with or without a fatal error in the new version) and it looks like it works fine as well.

Note: See TracTickets for help on using tickets.