The White Screen of Death (Completely Blank Page)

Occasionally a site user or developer will navigate to a page and suddenly the page content disappears, and is completely blank. No content. No errors. Nothing. This often, but not always, happens after updating a module, theme, or Drupal core. This is what is referred to by most members of the Drupal community as the White Screen of Death or WSOD. There are several reasons why this might occur, and therefore several possible solutions to the issue.

(Note: The suggestions on this page might solve the problem even when you do not get the WSOD as it relates to an Internal Server Error.)

"Invisible" Errors

If error reporting is turned off, you could be getting a fatal error but not seeing it. On a production site, it is common to have error reporting turned off. If that is the case and PHP has hit an unrecoverable error, neither an error nor content will be displayed, therefore you end up with a completely blank page.

What you can do about this is either turn on PHP error reporting so it displays a message on the page itself, or check your log files (from the server) to look for the error. How to do both of these are explained below.

Enable Error Reporting

Although it may be turned off on commercial hosts and production sites (for good reason, so that users do not see the errors), these errors are one of your best tools for troubleshooting. To enable error reporting, temporarily edit your index.php file (normally located in your root directory) directly after the first opening PHP tag (do not edit the actual file info!) to add the following:

You will now be able to see any errors that are occurring directly on the screen. Memory problems may still not be displayed, but it's the first step in a process of elimination.

If you are using a multi-site setup and only want errors to appear for one site, then check the name of the host first as in:

If the problem occurs while running update.php open update.php in a text editor and uncomment the following line:

ini_set('display_errors', FALSE);

Log Files

Your log files can be accessed a few different places. This will vary depending on your host, but it's good to know what and where they are.

To access the files directly on the server, on some unix shells (you may need to alter this to suit your environment), you can type the following command:

tail /var/log/apache2/error.log

To check that you are looking at the right file, you may wish to type the following commands to find where the log files are.

Otherwise, if you are still able to access your admin pages through your site, which you often can during a WSOD, check the watchdog log for errors. For example you may see the 'headers already sent' error, which relates to the whitespace error (explained in the next section).

The path to your watchdog log, should you lose your admin menu is:

• (Drupal 4.7) http://www.example.com/admin/logs/watchdog
• (Drupal 5) http://www.example.com/admin/logs/watchdog
• (Drupal 6) http://www.example.com/admin/reports/dblog

Your results will vary in different hosting environments, but this is a good starting point.

Whitespace at the End of a PHP File

The most common code error that causes a WSOD is having additional whitespace at the end of a PHP file. To avoid this issue, it is a Drupal coding standard to not include the closing ?> on a PHP file.

You may also have the 'Include Unicode Signature (BOM)' option turned on on your editor, which should be turned off.

PHP4 Syntax Errors and Incompatibility

Some versions of PHP4 gag on some function declaration syntax. Here are examples of syntax that fails:

This appears to be a bug in PHP4 parser that makes it not be able to handle either too many "=" clauses in a function declaration or handle "&$..." So in at least some cases, this is a de facto PHP4 incompatibility.

Solution: Upgrade to PHP5.

PHP Versions

If you were previously running Drupal on a server with multiple versions of PHP you may have had special code in your .htaccess file telling Drupal which version to use. For instance, you may have added AddType x-mapp-php5 .php to your .htaccess file if your hosting provider required it to ensure PHP5 was used rather than PHP4.

If that is the case, remove this line in your .htaccess file.

Invisible Errors for Developers

If you are developing a module, you may first want to test loading your file(s) to make sure that there aren't any obvious PHP syntax errors. This happens because the include_once() or require_once() function calls simply do not always report the errors [if someone knows why and has a fix for that one, please add the info here!]. The following is the command you want to run on your system (it requires PHP console, or CLI, to be installed):

This command will ask PHP to parse your file. If you forgot a semi-colon ";", or a closing bracket "}" it will give you the error immediately. Fix it, and try again on your server.

Better yet, you may want to write an automated test to check for such errors. More info about Simpletest here.

Implement Hook Twice

You can also get a blank screen if you have by mistake implemented the same hook more than once. For example, accidentally implementing hook_help twice.

Output Buffering

Some modules need output buffering turned on.

To do this, try adding these lines to your .htaccess file (normally located in your root directory:

Zend Compatibility Mode

If you get the WSOD while setting up a new server, you may have a problem with zend compatibility being on. If you check the error reporting you may see an error with "Trying to clone an uncloneable object of class mysqli." This is caused by the zend compatibility mode being On in the php.ini file.

To fix this, set zend compatibility to off by editing the applicable line:

More detail about zend compatibility can be found here.

Clearing the Cache Table

Depending on the problem, clearing the cache table (via phpmyadmin for example) can resolve a WSOD.

Ionic Rewriter: WIMP

If you are using Drupal on a WIMP stack and getting the WSOD on the http://www.example.com/install.php page it may be that you cannot have the Ionic Rewriter ISAPI module installed in IIS during the Drupal install.

The solution in this case is to add it in after install is completed.

PHP Memory Limits

Another common reason for the WSOD is issues with memory limit. Traditionally, this has most often been a problem showing up (or rather, not showing up) in the modules admin screen, by it giving a WSOD. This issue has pretty much been solved for that page; however, there are still instances that will occur in other modules (usually showing up during admin actions like bulk updates) where PHP memory can be exhausted.

Try the solutions here first if this issue came up when you tried to go to the module page.

You may also want to try running the update.php script. If you do not know how to run update.php or your user does not have the permissions to run it (and you do not have the user1 login), there is more info about update.php here.

Next, you'll want to confirm that the change has had an effect with a phpinfo() page. If you are hosting the site and it didn't work, check that you were modifying the correct php.ini file (it's named in the phpinfo). If your site is hosted by someone else and you failed to increase the memory limit, then your host has probably locked it down (for good reason) and you'll have to negotiate with them. There may be a few work-arounds to try, like creating a custom php.ini, but it will vary from host to host.

Module and Theme Related Errors

If the error is not originating from a memory limit, or any of the above errors, the error may be coming from bad code in a module or your site's theme.

Non-recommended Module Versions

If you are working with a module that is not in a recommended release version, you may have success by upgrading it to a recommended version or disabling/removing the module. To disable the module, simply go to the module admin page (Administer > Site Building > Modules) and uncheck the checkbox next to the module, then click "Save Configuration."

You can tell whether a module is recommended by looking on the module page, the version will have a green background with a green checkmark at the right, and say eg. "Recommended for 6.x." Particularly if the module is a development version, eg. "6.x-1.x-dev" it may not be recommended, and will then have a red background with an "x" at the right.

Name Clashes

Another possible cause for a blank page is a name clash, i.e. a module and a theme are using the same name. For example, if module "foo" implements hook_block() with foo_block() and there is also a theme "foo", then the theme engine will invoke foo_block() as the theme function to render a block. While foo_block() might not trigger a WSOD, foo_page() will.

No error messages are produced, because this is a wanted behavior of Drupal's theme system.

The solution in most cases is that if either the module or the theme (or both) are custom (created by yourself), rename it.

Character Encoding on template.php

If the error is as follows, particularly if the output started at line 1, it may be that the character encoding on your template.php file is not set correctly.

This is most likely if you are using an editor such as Dreamweaver, in which case you should either set the encoding to utf8_unicode_ci or use a plain text editor to edit the template code.

Disabling Modules

Via the Module Administration Page in the UI

Disabling all the modules, then enabling them one by one can help narrow down a culprit module. To disable the module, simply go to the module admin page (Administer > Site Building > Modules) and uncheck the checkbox next to the module, then click "Save Configuration."

Via the Database

If your WSOD is caused by a specific module (e.g. you enabled a module, then got the white screen) and you cannot access the module admin page, it's usually effective to disable the module in the system table of the Drupal database by setting its status to 0 and then clear the cache table.

WSODs Due to Specific Modules

If you are using any of the following modules, you may want to look at these specific issues that have the potential to cause the WSOD.

FCKEditor + Webform

If FCKEditor is enabled when adding a new webform on Drupal 5, the 'Additional Processing' field under the 'Webform advanced settings' fieldgroup gets the value of <br /> by default. This causes a blank screen when the form is submitted. To remedy, delete the <br /> from the field.

Node Access

If you have just enabled or disabled node access module and get the WSOD when attempting to update, you may need to rebuild node permissions. You can do this one of two ways.

First, you can rebuild permissions via the "Rebuild Permissions" button under "Node Access Status" on the Post Settings page at http://www.example.com/admin/content/node-settings.

Alternately, you can use a script to update the db node permissions table:

Gallery 2 (Embedded)

If you are using embedded Gallery 2, you have to edit gallerydirectory/config.php to point to the new database server. If you do not do this, you may get the WSOD without any errors (after enabling errors as above).

PEAR Wiki Filter

If you have moved your module directory, the PEAR Wiki filter will not be able to find the PEAR modules (assuming you installed them underneath the module directory.)

Check your input format in the admin pages and make sure that the "Path of PEAR packages" is correct.

WSOD on Multisite Installs

If this happens during installation or when starting a multi-site configuration where you are sharing databases or database tables, the reason may also be in the settings.php file in the sites/yoursite/ directory. This happens if you have already edited the $db_url variable in settings.php. The installer will no longer be automatically invoked, because Drupal assumes installation has already been completed.

If you get the following error messages for example (Drupal 6), the above may be the reason:

WSOD on Cloned or Duplicate Sites

There are a few possible culprits for a WSOD on cloned sites.

Include Paths

If you have created a new Drupal site by copying the files from an install and then importing the db over, and then edited the settings.php file with your new db info, you may still end up with the WSOD.

The pathauto module has caused problems in this scenario, where it throws fatal errors because of missing includes. In this case, adding this line to the .htaccess file solves the problem instantaneously (the right base path for your own server may be obtained through info.php or by logging into your control panel):

Missing Database Tables

If you are moving a large site and using phpmyadmin to import the DB, it may have either hanged and timed out or caused some tables not be be loaded into the db. to begin, be sure to double check your db to see if all the tables are there.

If moving a large site with a huge db then better import the db via a console (command line), as phpmyadmin is not always able to handle large db files.

Relic index.html Files, and Server Setup

Sometimes a server will be setup with a blank index.html file in the root directory, and/or Apache may not be configured to search for index.php files with the DirectoryIndex directive. It can look like a WSOD, but really is just an empty page.

To check if this is the case, navigate to http://www.example.com/index.php or look for an index.html file in your root directory. If there is an index.html file, make a copy of it outside your root folder, and then delete it and see if it resolves the issue.

Infinite Loops in your Code

If your site gets a WSOD after a CPanel system update, with notices like this in the error log:

You may have an infinite loop. Apache has become smart enough to detect this and terminate the script without waiting for a timeout.

You can try disabling modules in the system table until you find the offending module, or put a call to watchdog at the start of every function call in the module, so you can trace the call chain by looking at the watchdog table. If you find a repeating call pattern, look through the code for a loop cycling, eg. node_load through hook_nodeapi and/or other functions, and repeating node_load again.

PHP Timeout

The default PHP timeout defined in php.ini is 30 seconds. This is too short for some activities like listing/enabling modules.

Here are details on how to increase the maximum execution time.

Inappropriate naming of functions

Defining a custom function in your module code which acts as a Drupal hook function may result in WSOD. Check that the functions, that you define in your module do not use _menu, _auth or other extensions if they are not meant to implement that specific hook.

The following code generetase WSOD and Apache segfault in Drupal 5.

Any other solutions available?

If above information was not helpful enough, you may follow the next article which is dealing with WSOD diagnostic solutions:
http://drupal.org/node/482956 - Silent WSODs (White Screen of Death) - fixing step by step