Seems like WordPress 5.1 release is having problem with its main feature – WSOD (White Screen Of Death) protection.
The feature is intended to provide a recovery path for people that upgrade the PHP version and run into trouble due to their themes and plugins not being compatible with the new version. In extreme cases, this kind of incompatibility might lead to the admin not being able to log in at all and therefore no way to perform the most basic recovery attempt of shutting down the offending plugin.
There are a few philosophical problems with this kind of feature:
- If a software has bugs you can not trust it for anything. Since all themes and plugins share the same “execution space” with core, if a plugin is buggy it might be buggy in such a way that will disable the WSOD protection itself.
The only reliable way to implement it is to have a different software which monitors the state of WordPress and can disable by itself the relevant plugins. - Sites rarely have plugins active just because the bring “joy” to the admin. In every well maintained site each plugin has some functionality which is vital to the site and disabling a plugin will most likely mean that the site is going to be down. This kind of decision should not be made by a generic automated process as it might happen that even if at some point an admin can’t log in, it is still more important to keep the front end up.
- It assumes people do not use bloated themes (and if the theme is site specific it might be the right thing to do to develope one). With bloated theme there is a very good chance that the failure happens in the theme and not in a plugin, so what are you supposed to do in that situation? as disabling a theme is equivalent to bringing the site down.
- It is targeted at people that have very little knowledge in how to technically maintain a site, but what exactly are they expected to do if WSOD protection kicks in? It is not likely they have enough PHP knowledge to solve the problems by themselves, and this false sense of security is just going to put them in a situation in which their site is down and they will have to rush to find a developer to fix it ASAP. Totally not calm.
The right way to go about PHP upgrades is to educate users to first test upgrades on a staging site and provide facilities in core to make creation and synchronization with such sites easier.
For the cases where a mistake happened (and we know that s**t is bound to happen from time to time), the better way is to have a “safe mode” like functionality that is fully controlled by the user. Safe mode can’t by itself avoid the problems listed above, but being a user-controlled process the site owner can at least try to plan and bring help before getting into such mode.
Safe mode is planned for version 1.0 of calmPress, but maybe it will be kicked to 2.0 as while it is something very nice to have it is not essential and there are many nontrivial things to do as part of 1.0 as is.