WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 13 months ago

#14393 new enhancement

Maintenance mode overkill. Please refine usage of it

Reported by: bike Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: needs-patch
Focuses: Cc:

Description

Though many tickets have been posted about the Maintenance Mode not resolving, I think that the problem is on a different level.

It is unacceptable that even a failed upgrade of an inactive theme can break a complete Site or even Network. Case in point: I just followed the upgrade alert for an inactive theme, hosted on the WordPRess theme repository.
(Apparently it had an error (Incompatible Archive. PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature.) But the point is, this should not have put the entire network in maintenance mode for 10 minutes.

Maybe a check can be done for plugins, themes etc: if they are active, then maintenance mode can be used (though I am definitely not a fan of it anyway).

Change History (15)

comment:1 nacin4 years ago

I agree, .maintenance should not be created when inactive themes and plugins are updated.

comment:2 follow-ups: nacin4 years ago

Also, which theme? dd32 has been investigating those errors.

comment:3 in reply to: ↑ 2 bike4 years ago

Replying to nacin:

Also, which theme? dd32 has been investigating those errors.

Did not want to get this off topic, but in this case it was: "An error occured while updating Vinica:"

comment:4 dd324 years ago

  • Component changed from General to Upgrade/Install

Agreed that inactive plugins/themes shouldnt trigger a Maintainence mode situation.

PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature.

Is a error thats really limited to certain hosts right now from what I can see, its not the files specifically, Just a combination of file+server

Is this a 64bit PHP install? What Operating system/etc?

Theres a few issues in this ticket, in future it might be better reported separately..

  1. Maintenance mode when using Bulk actions upon inactive themes/plugins
  2. Maintenance mode when using Multisite can shut the entire network down when not all sites would be affected
  3. incompatible unzip

comment:5 dd324 years ago

  • Milestone changed from Awaiting Review to 3.1

comment:6 dd324 years ago

(In [15469]) Only use maintenance_mode() for ( is_multisite()
(plugin|theme) being updated is in use ) with Plugin|Theme Bulk Upgrades. See #14393

comment:7 dd324 years ago

that should take care of point 1 above.. I'm unsure about how to handle Multisite & Maintenance mode.

My initial thought was, that for Plugin and Theme upgrades, the maintenance mode block could check to see what type of upgrade it was, and then to see if that item is affecting the current blog.

Ie. SiteB's theme upgrade wouldnt affect SiteA, And a plugin upgrade on Sites B, C, D wouldnt affect SiteA.

But I'm not sure at that stage if We're aware enough of Multisite to know the current site being affected...

That might be getting to a point where its just one of those things that Multisite Network Admin's need to be aware of...

comment:8 nacin4 years ago

I think theme/plugin upgrades should only occur via the main blog. Related, #14170 -- we're likely going to limit network activation/deactivation to the main blog.

That doesn't mean you can avoid .maintenance however... There's no way really of knowing whether a plugin is activated at least somewhere without querying every site. So I'm thinking we'll just have to live with is_multisite() ||.

comment:9 dd324 years ago

That doesn't mean you can avoid .maintenance however... There's no way really of knowing whether a plugin is activated at least somewhere without querying every site. So I'm thinking we'll just have to live with is_multisite() ||.

What i was thinking of, was something along the lines of adding to the .maintenance file:

$type = 'plugin' || 'theme';
$items = array('my_super_plugin/plugin.php') || array('twentyten');

and then

if ( $type = 'plugin' || 'theme' ) 
    if ( $item is active on current requested site )
       include maintenance message;

ie. shift the most part of the site checking to the individual sites themselves, For core upgrades, you'd just die straight up obviously.

Just putting it as a possibility as an alternative to taking down everyones site for a upgrade which affects only a subset of sites. That being said, the maintenance mode should only exist for a brief interuption, and administrators need to be aware of that.. So planning upgrades around maintenance periods and/or handling upgrades a different way would be in their best interests regardless.

Last edited 3 years ago by dd32 (previous) (diff)

comment:10 dd324 years ago

The problem with that system, i'm pretty sure, is that the maintenance check runs before WordPress understands what site is current (or at least it should) in which case, it'd involve another block later for Multisite non-core upgrades to handle it.

comment:11 in reply to: ↑ 2 Denis-de-Bernardy4 years ago

Replying to nacin:

Also, which theme? dd32 has been investigating those errors.

It's usually related to the transport.

comment:12 jane4 years ago

  • Keywords needs-patch added

comment:13 jane4 years ago

  • Type changed from feature request to enhancement

Feature freeze is coming up in a few days if anyone is planning to patch the outstanding items listed above.

comment:14 jane4 years ago

  • Milestone changed from 3.1 to Future Release

No patch, entering beta. Punting.

comment:15 SergeyBiryukov13 months ago

  • Keywords Maintenance mode removed

Related: #24578, #13988

Note: See TracTickets for help on using tickets.