WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 8 months ago

#18826 new enhancement

wp_maintenance() expiration time needs to be filterable

Reported by: jaredh123 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.3
Component: Upgrade/Install Keywords: 2nd-opinion
Focuses: Cc:

Description

.maintenance files expire after 10 minutes if something goes wrong. 10 minutes is a long time, when most upgrading operations are attempted and fail within 20-60 seconds.

I propose three things:

  1. changing the default expiration to 5 minutes (300 seconds)
  2. Adding a filter to allow plugins and themes to filter this time to increase/decrease it
  3. Also, while I was in there, it seems prudent to attempt to delete the file if it has expired. The only argument I could see against this is that possibly it might be expensive if the file can not be deleted and wp attempts to delete the file on every page load. So I can take or leave 3 (and 2), but #2 I think is really important.

Attachments (2)

maintenance.diff (613 bytes) - added by jaredh123 3 years ago.
18826.diff (2.0 KB) - added by dd32 8 months ago.

Download all attachments as: .zip

Change History (5)

jaredh1233 years ago

comment:1 dd323 years ago

  • Keywords 2nd-opinion added; has-patch removed

Adding a filter to allow plugins and themes to filter this time to increase/decrease it

Can't be done there, apply_filters() isn't even loaded yet, and Plugins definitely aren't loaded. Any filtering would have to be on the $time value stored within the .maintainence file itself.

Also, while I was in there, it seems prudent to attempt to delete the file if it has expired.

The main reason that wouldn't be done already, is the fact that not all servers have write access to the directory, would ultimately mean attempting to delete it on every page load.

Deleting the file isn't too much of a problem IMO, given once it's expired it'll skip through that section of code anyway. It'll just get cleaned up the next time an upgrade is attempted otherwise.

changing the default expiration to 5 minutes (300 seconds)

As bad as this sounds: The reason it's set to 10 minutes, is because while most upgrades complete within a few minutes and clean the file up once done, not all do, I've seen a few hosts take >5 minutes for upgrades.

Clearing the timeout too early will cause the site to come back online before the process has finished for some people (the whole reason the maintainence file is there).

The majority of failed install attempts should clear the maintainence lock when it detects a failure, of course, if PHP is simply shut down completely mid-load, there's not much it can do - same for when the FTP connection dies and doesn't reconnect for some.

dd328 months ago

comment:2 dd328 months ago

Attachment 18826.diff​ added

Adds a filter to the timeout value for Maintenance mode, The filter runs during the upgrade process rather than on every page load.

I can't see any downside to this, but at the same time, I feel very little need for it.

Thoughts from others?

comment:3 knutsp8 months ago

If something usually goes wrong at upgrades, then the maintenance maximum downtime should be the least of the problems with that site.

Solves nothing. No need for this filter.

I have seen users forgetting that they started an upgrade and navigates to another page. This may leave WordPress in maintenance mode for the full ten minutes, as the upgrade is interrupted. There should ideally be a warning when trying to leave the upgrade page/process before it has finished, but that will eventually be a new ticket.

On the other hand, I can't see the need for the full 10 minutes either. Could say 8 is just as reasonable and leave it at that for a couple of years.

Note: See TracTickets for help on using tickets.