Disable maintenance mode when core auto-update fails.

[costdev]

In [58128], additional maintenance mode calls were added to the automatic updates process.

However, there is an ​early return if a 'core' automatic update fails.

Maintenance mode isn't disabled until later in the WP_Automatic_Updater::update() method. This means that maintenance mode may continue to be enabled despite the core update being treated as a skipped update.

Before the early return, maintenance mode should be disabled.

Upgrade/Install: Disable maintenance mode when core auto-update fails.

Additional maintenance mode calls were added to the automatic updates process. However, there is an early return if a 'core' automatic update fails.

Maintenance mode isn't disabled until later in the WP_Automatic_Updater::update() method. This means that maintenance mode may continue to be enabled despite the core update being treated as a skipped update.

This disables maintenance mode before the early return.

@costdev Do you have a mini-plugin I can chuck in to mu-plugins to emulate a failed update before and after?

@peterwilsoncc Try this one: ​https://gist.github.com/costdev/a6a50b492ce664c1365e1a5c6a7e8429

Using the force failure plugin in mu-plugins and without applying this change, I'm not yet able to reproduce a maintenance mode when updating Core from 6.5.4 to 6.6 Beta 3. @costdev am I missing a step?

[costdev]

​PR 6847 adds a call to WP_Upgrader::maintenance_mode( false ) to disable maintenance mode just before the early return.

Hookable points during this process to allow for testing aren't quite clear, and may require hard-coded changes to functions/methods to return the appropriate WP_Error object to force a failure during testing.

Despite this, it's clear that a flow exists where:

• Maintenance mode is enabled. ​Line 474
• The process may hit an early return. ​Line 518
• Maintenance mode is disabled later in the method, after the early return and so won't be hit. ​Line 621

Given this, I think it's safe to consider ​PR 6847 ready for commit ahead of the 6.6 Beta 3 commit freeze in under an hour.

@hellofromTonya What do you think?

[hellofromTonya]

Replying to costdev:

​PR 6847 adds a call to WP_Upgrader::maintenance_mode( false ) to disable maintenance mode just before the early return.

Hookable points during this process to allow for testing aren't quite clear, and may require hard-coded changes to functions/methods to return the appropriate WP_Error object to force a failure during testing.

Despite this, it's clear that a flow exists where:

• Maintenance mode is enabled. ​Line 474
• The process may hit an early return. ​Line 518
• Maintenance mode is disabled later in the method, after the early return and so won't be hit. ​Line 621

Given this, I think it's safe to consider ​PR 6847 ready for commit ahead of the 6.6 Beta 3 commit freeze in under an hour.

@hellofromTonya What do you think?

I bothers me that I can't reproduce the issue. However, logically the change makes sense. Thus, I trust your opinion and assessment. I'm okay for it to be committed.

[costdev]

In 58436:

Upgrade/Install: Disable maintenance mode when core auto-update fails.

In [58128], additional maintenance mode calls were added to the automatic updates process. However, there is an early return if a 'core' automatic update fails.

Maintenance mode isn't disabled until later in the WP_Automatic_Updater::update() method. This means that maintenance mode may continue to be enabled despite the core update being treated as a skipped update.

This disables maintenance mode before the early return.

Follow-up to [58128].

Props costdev, hellofromTonya, peterwilsoncc.
Fixes #61459. See #58281.

Committed in r58436.