White Screen of Death in WordPress

One of the most popular WordPress related issues is, without doubt, the White Screen of Death (WSoD). The most annoying thing of this error is that there is no particular clue of what exactly might have caused it and hence the irritation and despair that comes with it when it happens.

Being one of the most common issues in WordPress the WSoD is well documented and there are numerous fixes and advice on how you can go ahead and get to the bottom of it and find the root cause.

In this article, we will present several fixes and tests that you can make to investigate this. So let’s begin:

Fix File Permissions

Check your permissions. Check your file and folder permissions and make sure they have the default ones – 644 for files and 755 for directories. If you have access to a terminal you can run the following commands from the document root folder of the website:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Define memory limit

Increase the memory limit. Check if the memory that you have set is not too low. It is a common case that some plugin or a theme will need specific memory value to run correctly. You can put the following line in your wp-config.php file:

define('WP_MEMORY_LIMIT', '768M');

This can also be done via the php.ini file with the following line:

memory_limit = 768M

In this case, you will need to have in mind the PHP value limits imposed on the server (if there are ones).

Disable plugins

Disable all plugins. A common trick to try to test is to disable all plugins. Then if the site loads you will know that one(or more) of them is the main reason for the issue. You can then try to enable them one-by-one and then check the website behavior after activating them.

You can deactivate the plugins via the website backend. If you cannot access the website backend you another easy trick is to use FTP, or the File Manager of the host and navigate to the wp-content/plugins folder in your document root and just rename it to for example plugins.rename. This is not the most recommendable way to do this but if you have no other access it can do the trick.

Theme change

Change the active theme. Another popular check and test are to change the active theme of the website. You can test with one of the default ones such as Twentyseventeen for example. Again the theme might be changed via the WordPress backend or if you do not have access to the backend you can do it via the database and the phpMyAdmin interface.

If you can log at the backend and you can see that there are some plugins and theme/s that needs updating you can try to update them as the newer versions might fix the issue

PHP Version

Check the PHP version. You can check the current PHP version of the website and try to change it to a lower and/or higher one.

Bonus: Error Log

Switch on debug mode. You can try to enable the debug mode in WordPress and see if this will give you any hints. You can do this by adding the following lines in your wp-config.php file:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

These lines will enable the debug mode but also make sure that the errors are not displayed on the frontend. Once you add these lines, this will log errors to a file called debug.log located in the wp-content folder.

Some of these checks and fixes might need a bit more technical knowledge but they might worth trying as in most cases one of these tests will lead you in the right direction and the main reason for the WSoD.

More on The Topic

• 4 Indicators Your WordPress Website Is Being Hacked
• 10 Indications Your WordPress Website Is Hacked
• The Best Ways to Avoid a WordPress Hack
• Why Does Google Replace the Title Tags of Your WordPress Website (And What Can You Do About It)?
• How to Prepare Your WordPress Website for a Crisis

The content of this website is copyrighted and protected by Creative Commons 4.0.