[wp-trac] [WordPress Trac] #51816: Implement auto recovery mode during auto update cron

[WordPress Trac]

#51816: Implement auto recovery mode during auto update cron
-------------------------------+-----------------------------
 Reporter:  TimothyBlynJacobs  |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Future Release
Component:  Site Health        |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+-----------------------------
Description changed by TimothyBlynJacobs:

Old description:

> We introduced Recovery Mode to allow for a site administrator to access
> their site backend when a plugin is causing fatal errors. This makes it
> possible for the user to deactivate the plugin or update the plugin to a
> fixed version.
>
> With the introduction of opt-in plugin auto updates in 5.5, it would be
> nice if we could ensure that a site could still autoupdate, even if one
> of its plugin was causing fatal errors.
>
> This would need to happen without user interaction, otherwise the user
> could just use Recovery Mode themselves manually.
>
> One of the reasons Recovery Mode is a manual process is to make sure we
> don't fail open and disable a plugin that was providing protections of
> some kind to their site. As such, we'd need to make sure that this auto
> recovery mode would only allow a very limited amount of code to run.
>
> This could probably be all of cron, but I think it'd be good to try to
> further lock it down to when the automatic updater cron action is
> running.
>
> One way to do this would be in `WP_Recovery_Mode::handle_error` to check
> `wp_doing_cron()` and if so to trigger another `spawn_cron` but with a
> recovery mode token appended that could only be utilized when
> `wp_doing_cron()`. That way it wouldn't be exposed if a site was using
> the alternate cron setup.
>
> This wouldn't work for setups that are using an alternate cron runner, or
> using WP CLI to trigger cron jobs. But I think it would be possible to
> make work for users who are pinging `wp-cron.php` manually.

New description:

 We introduced Recovery Mode to allow for a site administrator to access
 their site backend when a plugin is causing fatal errors. This makes it
 possible for the user to deactivate the plugin or update the plugin to a
 fixed version.

 With the introduction of opt-in plugin auto updates in 5.5, it would be
 nice if we could ensure that a site could still autoupdate, even if one of
 its plugin was causing fatal errors.

 This would need to happen without user interaction, otherwise the user
 could just use Recovery Mode themselves manually.

 One of the reasons Recovery Mode is a manual process is to make sure we
 don't fail open and disable a plugin that was providing protections of
 some kind to their site. As such, we'd need to make sure that this auto
 recovery mode would only allow a very limited amount of code to run.

 This could probably be all of cron, but I think it'd be good to try to
 further lock it down to when the automatic updater cron action is running.

 One way to do this would be in `WP_Recovery_Mode::handle_error` to check
 `wp_doing_cron()` and if so to trigger another `spawn_cron` but with a
 recovery mode token appended that could only be utilized when
 `wp_doing_cron()`. That way it wouldn't be exposed if a site was using the
 alternate cron setup.

 This wouldn't work for setups that are using a custom cron runner, or
 using WP CLI to trigger cron jobs. But I think it would be possible to
 make work for users who are pinging `wp-cron.php` manually.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51816#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform