Everyone has perhaps experienced first-hand the phenomenon known as the Blue Screen of Death, or the Blue Screen Of Death (you Apple fans too, until you saved money on the Mac;)).
Those who do with WordPress may know a similar phenomenon in the form of White Screen of Death or White Screen Of Death ( WSOD ). This problem occurs similarly to its blue label, usually during a system user action, and indicates a problem with the execution of a function or other dynamic code within the PHP programming language that forms the framework of the WordPress system.
In general, there are two basic forms of WSOD :
– Partial WSOD , when the site is unavailable to visitors externally but the admin interface is functional
– Total WSOD when no line within the WordPress installation is working
The causes can be various, usually a problem with the WordPress theme or module, which manifests itself when installing or activating these elements. Depending on the action that occurred, you can try the following solutions:
1. Deactivate a topic
When a problem occurs while manipulating a new or old theme, try disabling the active theme and turning on the standard default WordPress theme that you know works normally. If the admin works without problems, this operation is simple. Otherwise you need to help via FTP:
– You find the directory of the relevant topic in the directory wp-content / themes /
– You rename the entire topic directory, e.g. from mojatema to mojatema-debug.
– You try to log in to the admin interface.
If everything works we can try to find an error in the topic code (see point 3), but it is not certain that the error is right here. It can also be in a WordPress module that is not compatible with the topic.
2. Reset modules
WSOD can also be caused by an error in one or more WordPress modules. If you have an administrative interface available, it is best to try disabling all modules, and when this fixes the problem, then turn it on and check each time it does not reappear.
With total WSOD, we have no choice but to log in to FTP again and proceed as follows:
– You search the module directory at wp-content / plugins.
– You rename the entire plugins directory – for example to plugins-debug – and save it offline.
– You create a new directory of plugins at the same level.
– See if the problem is fixed (of course, no modules will work in this state).
– You will try to gradually move the module directories to the new plugins directory and activate the modules via the administrator interface, in which they will be displayed one by one. In doing so, you check when the problem reappears.
3. Fix code error
Here are some specific reasons why WSOD may be responsible:
– Duplicate or conflicting PHP functions in different modules
Especially in modules with the same or similar functionality (or between a module and a theme), there may be a case where several functions are named the same or use the same so-called global variables, which can also cause WSOD. It is therefore important to check the various combinations described in points 1 and 2 so that the problem does not recur in the future.
– Incomplete upload of a module or theme using automatic (via the administrator interface) or manual (via FTP) installation.
In this case, it will simply help to delete the topic or module after deactivation and re-download, in case the uploads will work fine.
– A space in the functions.php file or a blank line in the wp-config.php file
You can find the functions.php file in the topic directory. If you’ve made changes to it, it should help delete the changes or simply replace the entire file with the original theme file. A common problem is especially stray gaps in the wrong place, see the picture:
Similarly, a blank line (especially at the beginning and end) in the wp-config.php file, which is located in the root directory of the WordPress installation, can cause the problem.
– Setting rights on directories and files
All directories should have server (so-called chmod) permissions at level 755 and all files at level 644. Although rare, this issue can occur when you change the default rights allocation settings from your ISP. Be careful not to set more permissions on files, this setting may affect the security of the entire website.
Here are some notes and tips on how to avoid WSOD :
– Before installing new modules or themes, make sure that they are compatible with the new (or your) version of WordPress.
– If you are not a very technically proficient PHP programmer, do not try to download the first beta version of WordPress right away. However, when you upgrade your WordPress installation to the official new version and WSOD occurs, look for an error in the installed modules and themes that may not support the new version. If these modules or themes are necessary, it is necessary to wait for their new version and only then update WordPress, or temporarily identify and correct the error yourself.
– If you do not know how to find the error, read the error message in the server logs, which often contain a direct mention of the function or. the file that is causing the problem. These records should be able to provide you with your .. provider 🙂
After reading these lines, an ignorant observer may say, “Hey, that WordPress is an unstable system.”
However, the opposite is true: these errors, unlike the well-known BSOD, occur very rarely and usually cause additional modules or extension topics that are the product of the volunteer community. Of the thousands of modules and themes that are created daily, it is understandable that it is not always possible to achieve maximum compatibility. Even so, it is good to keep the topic and module compatibility assessment system moving towards this state.
We are at the end of the next section on troubleshooting WordPress. As in the previous article , we welcome your comments on this topic in the comments.
Did you solve your WSOD problem anyway?
Have you encountered another, such as the green screen of death? 🙂
Let us know!