Home » Technology » The WordPress White Screen of Death, Solved

The WordPress White Screen of Death, Solved

If you have used WordPress (WP) for an extended period of time, there is a chance you have encountered an issue in which attempting to resolve your WordPress site resolves to a white/blank screen; this is commonly referred to as the WordPress White Screen of Death. Troubleshooting this problem can be simple, or frustrating depending on the cause. In this article we will review common problems that will result in the White Screen of Death as well as some more obtuse reasons.

You might notice the white screen in isolated cases, such as on one page, or in a site crippling example where nothing resolves. The former potentially could be caused by something unique to the page in  question. For a blank screen that is site wide, as well as for isolated cases, there are two likely causes of a blank screen,

  • A third-party plugin causing a conflict.
  • A third-party theme causing a conflict.

There are actually a number of problems that could cause a blank screen. We will attempt to address them all, however the above mentioned two are the most common.

The Basic

If your problem has occurred after moving to a new environment, then lets start with checking the system requirements for WP. The System Requirements for your version of WP can be found in the root of WP in a file with the following name: readme.html. You likely however do not have a copy of this file still sitting in your root deployment, to acquire it you will need to know the version which can be found in the following file:

/wp-includes/version.php

You will find a line such as the following:

$wp_version = ‘3.6’

WordPress maintains the most up to date requirements on the following page. If you have an older version than the most up to date version, go to the following link to download a copy of your version if you do not already have one.

If your system configuration matches the System Requirements then we can move on.

The Simple

A simple cause for a blank screen could be either (or both) of a plugin or theme used on the WP site. Before attempting to disable a plugin or theme used on your WP site, a simple start would be to check the logs for the Webserver, and for PHP. In this article we will presume you are using Apache in a traditional LAMP (Linux, Apache, MySQL, PHP) deployment for your WordPress site; if you are not using a LAMP environment, you can find corresponding logs in other competing products.

For Apache, check the Apache error log (error_log*) or logs depending on your configuration:

  • Using XAMPP on a Windows OS: C:\xampp\apache\logs\error.txt
  • On CentOS 6.5:
    Possible options: /etc/httpd/logs/error_log

In addition to the above, if you have Virtual Hosts configured with custom log(s), these will exist alongside the standard Apache logs unless otherwise configured. If you have trouble locating these log(s) then simply use the Search functionality in your OS to find the file(s) or parent folders; in CentOS 6.5 for example you could type the following:

locate httpd.conf

This might return:

/etc/httpd/conf/httpd.conf

Why would you want this file? This is the Apache configuration file in which you can find the location of the error_log as it is configured:

ErrorLog logs/error_log

Moving on, if you check the Apache error log(s) and find nothing of value, you can check the PHP error log(s):

  • Using XAMPP in on a Windows OS: C:\xampp\php\logs\php_error_log
  • On CentOS 6.5:
    Possible options: /etc/httpd/logs/error_log

If you have trouble locating these log(s) then simply use the Search functionality in your OS to find the file(s) or parent folders; in CentOS 6.5 for example you could type the following:

locate php.ini

This might return:

/etc/php.ini

Why would you want this file? This is the PHP configuration file in which you can find the location of the error_log as it is configured:

The location can be defined by (as an example): error_log = syslog

Other settings that can govern how much is reported include:

display_errors – to turn on/off

error_reporting – to govern scope of messages returned

html_errors – to turn on/off

log_errors – to turn on/off

track_errors – to turn on/off

display_startup_errors – to turn on/off

report_memleaks – to turn on/off

xmlrpc_errors – to turn on/off

If you are not able to determine any information of value in the PHP logs, then we can move on to disabling WordPress addons. Don’t forget to attempt to reproduce the error and recheck the logs if you find (for example) that you need to modify PHP’s error reporting.

Themes and Addons

There are several ways we can disable a theme or addon; we will simply make changes in the database to do this. For the theme we will execute the following query to determine the current theme:

select * from `wordpress`.wp_options where option_name = ‘template’ or option_name = ‘stylesheet’;

This presumes the database name is ‘wordpress’; you will need to change this accordingly. This query will return two records both of which will have the current them name listed under the column ‘option_value’. We can then update these two records to use the default WordPress theme with name: twentythirteen; this actually may be different depending on the version of WP you are using. Before you update the theme manually make sure you still have it loaded; reacquiring it is a simple matter if need be (see above, it will be similarly named to twentythirteen). This query can then be used to update the theme:

update `wordpress`.wp_options set option_value = ‘twentythirteen’ where option_name = ‘template’ or option_name = ‘stylesheet’ LIMIT 2;

Now we have changed the theme. If setting the theme back to the default doesn’t work we can try disabling all of the addons with the following code:

update `wordpress`.wp_options SET option_value = ‘a:0:{}’ WHERE option_name = ‘active_plugins’;

If this above code snippet doesn’t work we will need to reassess our problem.

More

WordPress provides a good outline of  methods for native WP logging; you can read it here. These methods may not be compatible with your version of WP as they should reflect options for the most recent release. We can try a simple method though; by simply asking WP; in the WordPress config file (wp-config.php), edit the following line to read as follows:

define(‘WP_DEBUG’,true);

This tells WP to enable it’s native debug mode. With debug mode enabled, if WP has something to tel you, it will now display it on screen; so now is the time to attempt to reproduce your error.

Test the credentials found in the WP config (wp-config.php) to ensure they will allow you to connect to the database. A connection error would have likely been revealed at this point but better safe than sorry. You will need the following: the database name, database credentials, and database URL. Presuming the database is available on your local environment represented by localhost; issue the following command at the command prompt:

mysql <databasename> -u <username> -p

Then enter the password when prompted; bearing in mind that <databasename> and <username> correspond to your database’s name and credential username.

A corrupted config file; it is plausible that if your configuration file is corrupted you may have a blank screen. Realistically though the above methods would likely reveal this problem. You can rebuild your config file as follows:

  1. make a backup of the existing WP config (wp-config.php); renaming it to something else is a simple way to back it up.
  2. copy pertinent information from the existing config including: the database name, database credentials, and database URL.
  3. ensure that the file wp-config-sample.php is sitting in the root folder of the WP site; if not pull it from your copy of WP (see above for reacquiring a copy).
  4. ensure that wp-admin/setup-config.php is still available; if not pull it from your copy of WP (see above for reacquiring a copy).
  5. reload your WP site and walkthrough the config process again; and retest your site afterwords.

Other possibilities include problems caused by the .htaccess file; try removing it. Or, one broad stroke if the above doesn’t work, change the name of the following two folders and then replace them with copies from your install files (see above for reacquiring a copy):

  • wp-content
  • wp-includes

Did that help? If so try isolating the offending files by reintroducing the removed files a few at a time. If this helps you may find that the offending code is in fact in one of the Addons or a Theme; and as such not revealed through our simple method of attempting to disable them. Why is this? Some third-party add-ons for WP are highly invasive and as such problems like these can be difficult to troubleshoot.

Hopefully the above has assisted in correcting your problem.

All content is © copyrighted by the owner of this website, 2014 and beyond | Check us out on Twitter