Maintenance mode overkill. Please refine usage of it

[bike]

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).

[nacin]

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

[nacin]

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

[bike]

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:"

[dd32]

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

[dd32]

(In [15469]) Only use maintenance_mode() for ( is_multisite()

(plugin|theme) being updated is in use ) with Plugin|Theme Bulk Upgrades. See #14393

[dd32]

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...

[nacin]

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() ||.

[dd32]

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.

[dd32]

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.

[Denis-de-Bernardy]

Replying to nacin:

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

It's usually related to the transport.

[jane]

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

[jane]

No patch, entering beta. Punting.

[SergeyBiryukov]

Related: #24578, #13988

[johnbillion]

#24578 was marked as a duplicate.

[jipmoors]

Related #34676