Two methods will be exampled for automatically detecting the state of “white screen of death”.

Problem ;
When a Plugin is updated, the system can at times end up being not viewable either at the frontend or in the dashboard.
This takes only one plugin to cause the problem.
This problem is easy to get the website working again, for those that know how.
And the plugin that has failed, needs to be fixed after that.
For a user that experiences this for the first time, or any time again when it seems like the first time (hopefully this event happens less than frequent memory would permit), this can b every frightening.
If they only do a short amount of research, they are at risk of deciding to scrap the site (and possibly WordPress) and begin afresh.
Fortunately this state is recoverable, at least for the rest of the site, and possibly including the plugin that has failed on update.
Unfortunately, the skill level or familiarity with webserver workings outside the wordpress environment are required, which makes this a difficult job for smaller users.

Causes ;
The “WSOD” is caused because the WordPress (core?) will not serve up the front end web pages, and also it will note serve up the dashboard pages, all because one ‘previously active’ plugin has had a problem updating its files.
The cause for these problems, includes space limitations, taking too long for the file transfer, interruptions during the process, and more.
It would take much development (relatively speaking) to come up with a solution to each of those causes.

Effects and observations ;
The resulting effect is that no pages get served up at the front or back end.
This is readily observed by the user when the user attempts to request a front or back end page.
For a user that has memories of previously experiencing this, they know that it is not too difficult to do (but is is almost never what they were planning to do during their work).
Now …
just as the user can observation the lack of page content, so can the server.
The server is capable of generating a request for a (front-end or dashboard) webpage, and detecting the result, the form of the result, or the absence of a result.

Method ;
The core of the method is to
i) make the server generate a request for a page
ii) check that the page has suitable content
iii) check if the page has no content, or content similar to the white screen of death (if there is any content).
iv) if there is a detection of a ‘likely’ or ‘definite’ white screen, then disable the recently updated plugin (or plugins)
v) that way front and back end pages still display.

Result ;
Instead of the front end going offline, so no visitors can see anything, and the backend becoming totally inaccessible through the dashboard,
the front end continues to be visible to all visitors, and the dashboard continues to be functional and able to be used for further diagnosis repair and normal work tasks. The dashboard will also report which plugins the problem was caused by, so the user can then activate the non offending plugins.

Various implementations
This core method of WSOD detection can be used in the following ways ;
a) when a single plugin is updated
b) when a group of plugins are updated at the end of all updates
c) when a group of plugins are updated after each next plugin is updated
d) as an automated procedure if the website is detected as being inactive (or not accessed by the logged in users) during the time shortly after an update activity.
e) as a periodic timed automated process, to help automatic recovery after a user has caused a problem when digging through their system. The user may be permitted to adjust the poll period when doing system level adjustments or file management activities. The system may alter the poll periods in accordance with the users detected activity, in readiness of the likelihood of the problem arising.
f) a command line instruction could be used to initiate the process from the website admin panel (for the webspace). This would save a user needing to get into file management (especially if they are not that advanced), and would speed up the return to near normal after the event.

Additional feature to aid the return to total fix;
If a manual method is known to fix a given problem with a plugin update,
then as much as possible, try take the verbose instructions that a user much research to find, then read, understand, and then do (without error), and to convert those into scripts that do it automatically.
And if possible, do that also with the diagnosis methods.

As an example
If the plugin is damaged because not all the needed files are present, or a file is damaged, then that may be detected if the list of files and folders, sizes, and checksums are known, so faults can be detected, then the update can be repeated.
If there are any precautions that need to be done prior to an automated repeat attempt at the update, then of course the user should be prompted, and the checks done.
If those checks can be automated as well, then all the better.

Possible improvement to the robustness of plugin updates ;
A plugin could include information, about what needs to be done, to fix a broken update (e.g. check a database, save previous settings, etc), and possibly include the scripts to do these automatically (either to complete the update, or to revert back to the original).
It would be sensible to have this information transferred at the start of an attempted update, so if there is any problem, then the original remains intact, and if there is a problem then the tools to fix it are already in the possession of the user (and can be presented to the user immediately afterwards), or ideally the repair scripts are ready to run automatically.
This can be implemented independently of the method for detecting the “white screen of death”.

If there are other better methods of detection, and repair, then those could be used instead. But hopefully these suggestions are enough to get some improvement in the update process, so the White screen of Death becomes a far less common experience for the users, saving much time, and improving the robustness of website for the front-end visitors.

Here is the notes from the last PHP meeting, that discussed it recently.

PHP Meeting Recap – June 25th

I did that.
But I am not too keen to get into the nitty gritty (websites, forums, chit and chat) of the development team, as I want to avoid more technical problems than the ones I have experienced in this main site.
metaphorically ;
If somebody slaps one’s hand, then one is not likely to accept that person’s invitation to dinner (though one may choose to maintain a cordial relationship in the street)(one may even accept in future, after time or changes).

Please follow this topic, to help ensure that it gets to the people that would be interested in reading it.

I have also started other topics related to plugin handling, update, and unified approaches that might make WordPress plugin system more robust.

Thank you for helping.

Thanks for that.
I had made fairly good description of the concept at the Trac ticket at
https://core.trac.www.ads-software.com/ticket/44458

I had got the impression that these forums have a few forums which get perused by development teams for wordpress, including ;
a) the “Everything else” forum at https://www.ads-software.com/support/forum/miscellaneous/ and
b) the “Requests and Feddback forum at https://www.ads-software.com/support/forum/requests-and-feedback/, and
c) possibly the “Alpha/Beta/RC” forum at https://www.ads-software.com/support/forum/alphabeta/

I have made gone to the effort to make suggestions for improvements in these forums in the knowledge of that, and have even been informed by some moderators that the developers scan these topics, and that one of their methods of searching for topics is based on them not having had a reply (which was learnt when I would add after thoughts to initial comments, and be told that this was called ‘bumping’ and is considered as something that should not be done – for the very reason that developers and other interested parties would be less likely to find it).
Now , thanks to your happening to find this topic, and having replied, I learn that there is very little chance that the kind of people that I was under the impression scan these topics for new ideas, actually will do so.

Please may I ask you to communicate with any developers you wish (as many as possible), and please ask them to consider doing searches in these forums (3 above) for topics set as “this topic is not a support question”.
They will find plenty of suggestions made by run of the mill users, that are made to make WordPress more useable in the user’s hands.

One of the suggestions (if I remember rightly) that I have made is to have a ‘redirection’ or ‘copy to’ function, that basically automates the process that you and I have just gone through here.
That is “Developer searches forum, spots interesting topic, and notifies related developers who might be interested”. The topic author does not need to know the ins and outs of where the topic needs to go, they do not need to understand technical matters, who does what, the who’s who politik, some sort of submission system.
This function would allow developers to do a scan search of topics in forums, looking for related topics, and mark them (click a button), to copy the information to a developer related topic/discussion. That process may include an automatic placing of a post in the forum topic, to request permission to forward the topic to another developer discussion, and when the topic author clicks an approval button, then the copy takes place.
This process cuts down on the writing of custom messages each time, and facilitates the collection and collation of (what may be a vast) resource of suggestions and ideas.
A similar process could also be used to identify forum topics that have already begun work on a similar concept, duplicate suggestions and suggestions that are closely related (without deleting them), and other management that be be useful.
This suggestion is not intended to imply or force an obligatory function for the developer teams that would distract them away from their core (and enjoyed) tasks.
The suggestion is made, so that a possibly (very?) useful additional tool is available for supplying information from users to developers, that may be helpful for feeding in to the decisions for direction of development (where common pitfalls are, insights that could same time or effort in future, etc).

metaphor ;
This is a bit like “letters to Santa”
Lots of letters get sent to Santa, and we all know Santa does not exist (at least not as a real person, but some may be of that heart).
So many might think the letters are of no value.
That’s ok.
But if Santas postal address happens to be at one of the department stores or toy companies, then some serious market intelligence is gained, for free, prior to the impending time of it being most valuable.
(kind of funny how the items that run out first, are the items that had the biggest piles in front displays)

And somebody had to make them all (Santa’s helpers – some of us would have some others of us, believe).

So (call to action),
Joy, if you can, could you please communicate with the developers and
to the developers (Santa’s helpers) that read this ;

Please try an (even just cursory) scan search
of the topics in these forums for topics of interest to you, and set as “this topic is not a support question” (irrespective of how many replies they have),
to see if there are or might be some topics of interest that are worth disseminating in developer forums.

Thank you

At a recent WordCamp, one of the very senior core devs was asked how to get some feature into core. He suggested that the first thing to do is to build support for the idea through social networks, blogs, etc. The support forums are not the venue for that.

By and large, WordPress will detect fatals and disable the plugin when they occur through the code editors, but the update process may not be quite so forgiving. It is reasonable to discuss the concept first before making a ticket on the topic.

I was locked out.
I just happened to see this at the top of my topics list, without the lock sign so wondered what was going on.
Is there a mistake in the system,
or am I allowed to talk again?

Thanks (I think?)