WP Core? Plugin Update fail White Screen OD – method to detect and repair

Brief Over View ;
This topic suggests an automated method that has the objective of detecting and remediating failed plugin updates that result in the “White Screen of Death” that for some users can cause a great deal of stress. But are in any case, the cause of time that need not be wasted fixing the consequences, if there is a method to avoid the consequences (even if there is no method to avoid the cause – as yet).

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.

• This topic was modified 6 years, 4 months ago by MKSnMKS. Reason: formatting clarity