Occasionally a site user or developer will navigate to a page and suddenly the page content disappears, and it becomes blank. No content. No errors. Nothing. This happens sometimes, It could happen 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:

<?php

error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

// $Id: index.php,v 1.94 2007/12/26...

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:

<?php

if ($_SERVER['HTTP_HOST'] === 'some.domain.name.here') {
  error_reporting(E_ALL);
  ini_set('display_errors', TRUE);
  ini_set('display_startup_errors', TRUE);
}
?>

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

ini_set('display_errors', FALSE);

Change the shutdown handler

Another way to force errors to display is to change the shutdown handler. Add the following code (originally from https://stackoverflow.com/questions/845021/how-can-i-get-useful-error-me...), to the front of index.php:

// -------------------------------------------------------------------------------------------
// - Display Errors
// -------------------------------------------------------------------------------------------
ini_set('display_errors', 'On');
ini_set('html_errors', 0);

// -------------------------------------------------------------------------------------------
// - Error Reporting
// -------------------------------------------------------------------------------------------
error_reporting(-1);

// -------------------------------------------------------------------------------------------
// - Shutdown Handler
// -------------------------------------------------------------------------------------------
function ShutdownHandler()
{
    if(@is_array($error = @error_get_last()))
    {
        return(@call_user_func_array('ErrorHandler', $error));
    };

    return(TRUE);
};

register_shutdown_function('ShutdownHandler');

// -------------------------------------------------------------------------------------------
// - Error Handler
// -------------------------------------------------------------------------------------------
function ErrorHandler($type, $message, $file, $line)
{
    $_ERRORS = Array(
        0x0001 => 'E_ERROR',
        0x0002 => 'E_WARNING',
        0x0004 => 'E_PARSE',
        0x0008 => 'E_NOTICE',
        0x0010 => 'E_CORE_ERROR',
        0x0020 => 'E_CORE_WARNING',
        0x0040 => 'E_COMPILE_ERROR',
        0x0080 => 'E_COMPILE_WARNING',
        0x0100 => 'E_USER_ERROR',
        0x0200 => 'E_USER_WARNING',
        0x0400 => 'E_USER_NOTICE',
        0x0800 => 'E_STRICT',
        0x1000 => 'E_RECOVERABLE_ERROR',
        0x2000 => 'E_DEPRECATED',
        0x4000 => 'E_USER_DEPRECATED'
    );

    if(!@is_string($name = @array_search($type, @array_flip($_ERRORS))))
    {
        $name = 'E_UNKNOWN';
    };

    return(print(@sprintf("%s Error in file \xBB%s\xAB at line %d: %s\n", $name, @basename($file), $line, $message)));
};

$old_error_handler = set_error_handler("ErrorHandler");

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 a server running Apache, 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

For nginx, depending on your .conf file, you can usually find log files by typing the following command:

tail /var/log/nginx/[sitename]_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.

grep 'ErrorLog' /etc/apache2/*
grep 'ErrorLog' /etc/apache2/*/*

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 depending on your core version:

  • up to Drupal 5 and below: example.com/admin/logs/watchdog
  • from Drupal 6 and above: 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:

function media_mover_api_media_mover($op, $action = null, $configuration = null, &$file = array(), $running_config = null ) { ...
function media_mover_api_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) { ...

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):

$ php -l -d display_errors=On <filename>

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

Additionally, you can do check all *.php files for syntax errors. On *nix, run:

$ find . -type f -name '*.php' -exec php -l '{}' \;

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):

php_value output_buffering On
php_value output_handler mb_output_handler

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:

; Enable compatibility mode with Zend Engine 1 (PHP 4.x)
zend.ze1_compatibility_mode = Off

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.

Restarting Web server

WSOD can be caused by web server issues. Especially if you are using apache and PHP fails with error "undefined function: drupal_bootstrap() in ... index.php" but file includes/bootstrap.inc is in place with correct permissions, try restart (not just reload) web server.

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.

Malformed ctools plugins

Some malformed ctools plugins (for example custom panel layouts) can cause a WSOD. If you have any custom ctools plugins, try disabling them to see if they are the issue.

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.

PHP execution time limits

Another PHP setting that can lead to WSOD is max_execution_time. Apparently, on WAMP, the default is 30 seconds, but some administrative pages may take longer than that to process and load. Change this setting (see other sections on this page for instructions on how to change PHP settings in php.ini or using php_value() and do the same steps with this setting) to a larger value, and it might clear up your WSOD problems.

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.

Theme or module lacking

Check if the theme needed for your site is in drupal7/all/themes or drupal7/default/themes, if drupal7 is your drupal directory (If you use a multisite installation, the latter is drupal7/my_site.com/themes , my_site.com being your site directory). Especially if you use a sub-theme, check if both the master theme and the sub-theme are there, with the right names and read permission.
The same way, modules required by your site must be present in drupal7/all/modules or drupal7/default/modules (or drupal7/my_site.com/modules in a multisite installation).

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.

Cannot modify header information – headers already sent by (output started at .../sites/all/themes/THEME_NAME/template.php:1) in .../includes/common.inc on line 314.

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:

<?php
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
user_authenticate('admin', 'admin');
$actual=db_result(db_query("SELECT nid FROM {node} WHERE nid > %d ORDER BY nid",$_GET['node']));
if ($actual>0) {
  $sencer=node_load($actual);

  node_access_acquire_grants($sencer);
}
?><html>
<head>
<script type="text/javascript">
<!--
function delayer(){
    window.location = "rebuild_permissions.php?node=<?=$actual?>"
}
//-->
</script>
</head>
<body <?=($actual>0 ? " onLoad=\"setTimeout('delayer()', 500)\"" : "") ?>>
<?php
if ($actual>0) echo "doing... ".$actual;
else echo "Done";
?>
</body>
</html>

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:

PHP Warning: Table 'testing.access' doesn't exist
query: SELECT 1 FROM access WHERE type = 'host' AND LOWER('127.0.0.1') LIKE LOWER(mask) AND status = 0 LIMIT 0, 1 in C:\\My_webdev\\htdocs\\drupal\\includes\\database.mysql.inc on line 128
PHP Warning: Table 'testing.users' doesn't exist
query: SELECT u.*, s.* FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = 'da5qecc9rsf1dinhb4ko1e5dm0' in C:\\My_webdev\\htdocs\\drupal\\includes\\database.mysql.inc on line 128
PHP Warning: Table 'testing.cache' doesn't exist
query: SELECT data, created, headers, expire, serialized FROM cache WHERE cid = 'variables' in C:\\My_webdev\\htdocs\\drupal\\includes\\database.mysql.inc on line 128
PHP Warning: Table 'testing.variable' doesn't exist
query: SELECT * FROM variable in C:\\My_webdev\\htdocs\\drupal\\includes\\database.mysql.inc on line 128
PHP Notice: Undefined variable: variables in C:\\My_webdev\\htdocs\\drupal\\includes\\bootstrap.inc on line 427
PHP Warning: Table 'testing.cache' doesn't exist
query: UPDATE cache SET data = '', created = 1209809924, expire = 0, headers = '', serialized = 0 WHERE cid = 'variables' in C:\\My_webdev\\htdocs\\drupal\\includes\\database.mysql.inc on line 128
PHP Notice: Undefined variable: variables in C:\\My_webdev\\htdocs\\drupal\\includes\\bootstrap.inc on line 434
PHP Warning: Table 'testing.system' doesn't exist
query: SELECT name, filename, throttle FROM system WHERE type = 'module' AND status = 1 AND bootstrap = 1 ORDER BY weight ASC, filename ASC in C:\\My_webdev\\htdocs\\drupal\\includes\\database.mysql.inc on line 128
PHP Warning: Table 'testing.url_alias' doesn't exist
query: SELECT COUNT(pid) FROM url_alias in C:\\My_webdev\\htdocs\\drupal\\includes\\database.mysql.inc on line 128

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):

php_value include_path '.:/var/www/vhosts/example.com/httpdocs'

Missing Database Tables

If you are migrating a site with a large database, the database import may have timed out before all database tables were imported. Before visiting the site for the first time, be sure to check your database to see if all the tables are there.

Since a failure to read from a database table throws a PDOException, it may not appear in Apache or PHP error logs. One way to identify if this error is happening is to install Drush and run drush status.

For large databases, it is better to do the database import via the console (command line), since PHPMyAdmin is not always able to handle large database files.

Database imports may also fail if the server to which you are migrating the site has a limited amount of RAM.

Several command line methods for importing large database dumps are found here: https://hevodata.com/learn/mysqldump-export-databases-and-tables/#large.

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:

[notice] child pid ##### exit signal Illegal instruction (4)

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 generates a WSOD and Apache segfault in Drupal 5.

function mymodule_menu() {
  array(
    'path' => 'auth'
    'callback' => 'mymodule_auth'
  );
}

function mymodule_auth() {
  drupal_execute('user_login', array('name' => $_POST['name'], 'pass' => $_POST['pass'])); 
}

Usage of PHP short open tag

Sometime, mostly when moving to new server, you will get white screen. This may be because of usage of short open tag

<?

instead of

<?php

Solution: edit php.ini and enable short open tag

short_open_tag=On

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

Comments

raffuk’s picture

I would like to add that I was having this problem with an old project in a new PC.

The problem was that I didn't have the "files" directory created (which I had to create manually).
After that I didn't have any problems anymore.

I hope this helps!
www.twitter.com/raffuk

giblfiz’s picture

It is common to get a WSOD directly after login if you have the date_api module installed, and are running php 4.x / 5.0 / 5.1, but have not enabled the "date php4" module. This can be particularly sneaky if your dev environ is php 5.2 and your deployment environment is still php 4

jinesh.m’s picture

i got the dreaded white screen after I used D5 API calls in a custom block on my D6 site.

enabled error reporting (in index.php) & got this message "Fatal Error: Unsupported operand types in /includes/common.inc on line..."

a bit of searching gave me a quick patch - http://justinhileman.info/articles/unsupported-operand-types-in-drupal-6x

there are different reasons for drupal throwing a blank screen, hope this helps anyone getting one because of legacy calls :)

hlevinson’s picture

In your module code be careful with menu callbacks invoked by hook_menu(). Your callback function must return a value.

In the example below, if you omit the return statement, you will get the BSOD.

function my_menu() {
   ...
  $items['my/menu/path/%'] = array(
    'title'             => 'my title',
    'page callback'     => 'my_callback_function',
    'page arguments'    => array(3),
    'access callback'   => TRUE, 
    'type'              => MENU_CALLBACK, 
   );

   ...
}
   ...

function my_callback_function($param) {
  ...
  return '';
}

Michel Poulain’s picture

Thanks for your script!

On my huge website (80.000 users, 10.000 nodes), Drupal had the same white screen symptoms when rebuilding rights.

Since the version 6, check right permissions on previous script version was no longer working.

Here is the updated Drupal 6 version with some improvements I've made:
- the mandatory DELETE FROM {node_access} before rebuilding
- time remaining
- percentage status
- localization support
- custom script name in root directory

--
Mike

<?php
# Load Drupal functions
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);


# Check permissions to access this page
if (!empty($update_free_access) || $user->uid != 1) {
  require './update.php';
  exit;
}


# Retrieve node index in the nodes table and time started
$index = (!isset($_GET['index']) || !is_numeric($_GET['index']) || $_GET['index']<0) ? 0 : $_GET['index'];
$t = (!isset($_GET['t']) || !is_numeric($_GET['t']) || $_GET['t']<0) ? time() : $_GET['t'];


# First launch : flush node_access table and caches
if($index==0) {
  node_access_needs_rebuild(TRUE);
  db_query("DELETE FROM {node_access}");
}


# Fetch next node to rebuild grants
#$actual  = db_result(db_query("SELECT nid FROM {node} WHERE nid > %d ORDER BY nid",$_GET['node']));
$actual  = db_result(db_query_range("SELECT nid FROM {node} ORDER BY nid", $index, 1));
$total   = db_result(db_query("SELECT COUNT(nid) FROM {node}"));
$percent = ($total > 0) ? ($index/$total*100) : 100;
$time    = (floor($percent)) ? format_interval((time()-$t)/$percent*(100-$percent)) : t("caclulating...");


if ($actual>0) {
  # Update actual node grants
  $node=node_load($actual);
  node_access_acquire_grants($node);
} else { 
  # Finishing : remove 'rebuild permissions' warning
  node_access_needs_rebuild(FALSE);
  drupal_flush_all_caches();
}


/*
# Old method
set_time_limit(0);
db_query("DELETE FROM {node_access}");
node_access_rebuild();
*/


?><html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 
<title><?php echo t("Rebuilding nodes permissions !percent%", array('!percent' => floor($percent))); ?></title>
<script type="text/javascript">
<!--
function delayer(){
    window.location = "<?php echo $_SERVER["SCRIPT_NAME"]."?t=$t&index=".($index+1); ?>"
}
//-->
</script>
</head>
<body <?php echo ($actual>0 && !isset($_GET['stop'])) ? " onLoad=\"setTimeout('delayer()', 0)\"" : ""; ?>>
<?php
if ($actual>0) echo nl2br(t("Rebuilding nodes access rights... !percent% (!index / !total)\nStarted on !started. Estimation of time remaining: %time", array('!percent' => floor($percent), '!index' => $index, '!total' => $total, '!started' => format_date($t), '%time' => $time, )));
else echo nl2br(t("Nodes access rights rebuilding: <b>done in !elapsed.</b>\nStarted on !started. Finished on !ended",
  array('!elapsed'=>format_interval((time()-$t)),'!started' => format_date($t), '!ended' => format_date(time()))));
?>
</body>
</html>
joshua.stout’s picture

I removed 5 blank lines at the end of template.php and it fixed my WSOD.

charlesgroce’s picture

I tried everything in this guide and others to fix a theme-related WSOD I was getting after each administrative submit, such as enabling a menu item, or disabling a module. Turns out the problem was in the template.php file. Believe it or not, the following snip seems to have caused the problem.

Bad code:

<?php
function theme_x_menu_local_task($link, $active = FALSE) {
  return '<li '. ($active ? 'class="active" ' : '') .'><span><span>'. $link ."</span></span></li>\n";
}
?>

<?php
function theme_x_l($text, $path, $options = array()) {\\etc

The closing ?>, the blank line, and the <?php tags caused the WSOD. Deleting them resolved the issue.

Good code:

<?php
function theme_x_menu_local_task($link, $active = FALSE) {
  return '<li '. ($active ? 'class="active" ' : '') .'><span><span>'. $link ."</span></span></li>\n";
}
function theme_x_l($text, $path, $options = array()) {\\etc

I hope this helps someone!

tahiche’s picture

This also fixed it for me!!.
Thanks!!.

Just one, single opening "<?php " in template.php.

It must consider the whitespaces as header elements or something like that...

imadalin’s picture

it took about 3 minutes to find out why a site i worked on was wsod-ed. drupal has great documentation.

aeskreis’s picture

Recently got a WSOD from a module with a bug in it. I manually disabled the module in the system table, but it still didn't work. I manually truncated all of the drupal cache tables, and it fixed it.

cos’s picture

My problem was WSOD when running update.php in D6 (on several different websites on different platforms).

Finally tracked it down to a series of broken function calls in the Garland theme. Don't know why they are broken. Don't care.

Apparently installation and update require the Garland maintenance-page.tpl.php. But once you are installed, there is no need to have a bloated maintenance-page.tpl.php to run update.php.

I replaced your_site_root/themes/garland/maintenance-page.tpl.php with a greatly simplified page, one that only does what is needed -- nothing more. And now update.php works just mighty fine.

So here is your easy-peasy replacement:

<?php

/**
* update pages depend on this file.
*/
?>
<html>
<head>
<title><?php print $head_title ?></title>
</head>
<body style="margin:100px;">
<?php print $content ?>
<hr>
<?php print $footer_message . $footer ?>
</body>
</html>

Andrew Himes’s picture

We moved our site (voiceseducation.org) from one host to another. When we did so, we had a serious and repeated problem with multiple errors and then with WSOD. The problem turned out to be the Drupal Tweaks module. Once we deleted that module and re-imported the database to the new site, all was fine.

Leglaw’s picture

In my case, I wasn't returning the form. Instead my code was:

function mymodule_page($id) {
//...  
  drupal_get_form('mymodule_form');
}

... when it should have been:

function mymodule_page($id) {
//...  
  return drupal_get_form('mymodule_form');
}

This will cause a WSOD that produces no errors written to the php or apache logs.

ju1i3’s picture

This is very useful. I had WSOD when I migrated from one host to another. It turned out to be the .htaccess file which was working fine on the old host but the line AddType x-mapp-php5 .php stopped any php from working including Drupal.

I also had an issue with the location of php.ini. Luckily the hoster told me where to put that but for the above problem they refused to assist with "customer coding". I think it's configuration information that we need to know from the host - otherwise how would we know how they have apache set up??

Julie

Anonymous’s picture

I got the WSOD after upgrading panels, which totally wiped out my custom layout. Why it has to delete that folder I've no idea.

Re-uploaded the layout (backup and migrate saved a copy of the module), re-saved desired layout and content and everything is now fine.

EDIT: Oops, really should have put my custom layout in my own themes folder: http://drupal.org/node/495654

atavio’s picture

Drupal 6.x & postgres 9.x. is a bad combination.

If you enable error reporting you will see something like:
Notice: unserialize(): Error at offset 0 of 1927 bytes in .../includes/cache.inc on line 33

Thanks for the good hints.

steve316’s picture

We had an issue with the wsod whenever we enabled the update module. All of our public pages were visible just fine, however we could not access any admin pages, all were wsod. We are on shared host, went round and round with them, they finally told us our queries were taking too long to execute their timeout limit was 10 seconds.

Eventually found this post, and edited the two files, this instantly cleared up our wsod issues with the update module.

here is the post:
I have seen the "MySQL server
Posted by cog.rusty on April 23, 2009 at 3:43pm

I have seen the "MySQL server has gone away" error on a couple of cheap shared hosting accounts where they had set wait_timeout=15 to save connections. By the way, MySQL's default is wait_timeout=28800. 15 is a bit too drastic.

Since I had no access to MySQL's settings, I had to hack Drupal core to fix it.

In includes/database.mysql.inc, at the end of function db_connect(), under the "SET NAMES" line:
mysql_query('SET SESSION wait_timeout = 60', $connection);

In includes/database.mysqli.inc, at the end of function db_connect(), under the "SET NAMES" line:
mysqli_query($connection, 'SET SESSION wait_timeout = 60');

I guess someone with more PHP experience that me could suggest a patch to check if wait_timeout is too low and fix it in some economic way.

msagi’s picture

Unserializing does not work on Postgresql 9 when bytea_output is 'hex'. To make Drupal 6 work in this case, open a PostgreSQL console and enter the following command:

ALTER DATABASE [your_database] SET bytea_output = 'escape';

This makes the bytea_output compatible with Drupal 6.

Cheers,
Miklós

http://portalsoft.hu

architectJpres’s picture

That did the trick!

Kristen Pol’s picture

I was debugging a white screen of death (WSOD) problem a couple days ago and putting:

error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

in the settings.php file still didn't display any errors.

But, installing the dtools

http://drupal.org/project/dtools

and enabling the wsod module in that package did show the errors.

Hopefully that will help someone!
Kristen

-Kristen
Profile: https://www.linkedin.com/in/kristenpol
Drupal 7 Multilingual Sites: http://kristen.org/book

koppie’s picture

I had this problem, turns out it's related to Drupal Commons. The solution: http://drupal.org/node/944630#comment-3590654

If you're too lazy to click on the link: flush the cache and make sure that Acquia Commons and Fusion Core themes are both enabled (even if you're using a different theme.)

teresalien’s picture

I spent a considerable amount of time trying to figure out why when I installed Ctools or Views...my screen would turn white. I actually have trying to find the right path or change appropriate files...I just want to design. With that said i found out the problem was not enough memory. I fixed it by using the

Drupal Module - Drupal Tweaks

I bumped up my Default PHP memory limit. If this can help anyone else that reads these posts as sweat drips from their brows because they are on a deadline and can't figure this s*&@! out my time hasn't been totally wasted.

BTW thank you to the developers of that module you should be at the beginning of the list with a big thing that says if you get the White Screen of death or a memory error message TRY THIS MODULE
The whole reason I started using Drupal was to hopefully illiminate the hours of tweaking

KISS
(Keep It Simple Stupid)

youssefr’s picture

Hi
After I disabled it ..I can see the blocks page now..I Still need to use "Apache Solr "
Thanks

i7nvd’s picture

I had a problem where I'd get a WSOD after submitting a button click for something like "Save Blocks" after modifying their positions. I tried to enable some error logging in some of my php files, but that made things worse. The problem showed up in my template.php file in my theme's root folder. I simply replaced that template.php file with the original one in my theme folder on my local machine. When it was replaced, everything popped back to normal again.

Stomper’s picture

When I transferred by website from localhost to a live server, I got the WSOD when trying to edit account information. I performed a permissions rebuild and it fixed the issue.

igormagic’s picture

This was my case - WSOD when I tried to change colors in Garland or other themes on Drupal 6.x running on FreeBSD. No information in Drupal or PHP logs. In the log of Apache there was this line:

[notice] child pid xxxxx exit signal Abort trap (6)

After investigation the cause was detected: imagecreatefrompng () caused PHP to core dump because PNG updated after PHP was installed.

Rebuilding of PNG and everything that depends on it fixed the issue:

portmaster -r png

kvguser’s picture

Drupal 5.23, PHP 5.3.0, MySQL 5.1.36, Apache/2.2.11
(yes, Drupal 5.x works on PHP 5.3, just disable errors from showing in your prod.server)

Effect: totally blank page (no errors) when going to Administer -- Logs -- Status report

fix:
in includes/theme.inc, find line

call_user_func_array($functions[$function], $args);

and replace with

call_user_func_array($functions[$function], &$args);

(note the only change is a "&" before $args)

franfran’s picture

For those of you have Drupal 7 and Devel installed.

I tried to develop my site in localhost and upload my site to a remote server. It just show blanked page and nothing. Wasted my 2 hours figuring why.

To fix the problem, if you have Devel module installed like my case, try to disable the Devel module before exporting your database.

p.s. I have tried to manually disable the Devel module in the database, but it won't work.

Hope it helps.

smartfun’s picture

I've had this nasty problem the last weekend. I recomment you all to check the size of PHP memory. If I had done this at the beginning I would have found the solution sooner.

rickumali’s picture

For a recent WSOD I had to deal with, I ended up finding my issue via the Watchdog entries. Drush helped me with this:

drush @dev watchdog-show --count=5

The above showed me:


Id Date Severity Type Message
430 13/Nov 16:02 warning php Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'mymodule_overview_page' was given in menu_execute_active_handler() (line 50)

My root cause: I hadn't yet defined the page callback 'mymodule_overview_page'. D'oh!

armyofda12mnkeys’s picture

When moving my site from Windows to Linux, it would work on the linux server initially... Then when I cleared the cache on the linux/prod site, it would display the WSoD always on the homepage.
or if i did sqldump from my Windows site via Backup and Migrate (since it clears the caches by default in its export file that I'd import), then the site also wouldn't work from even the start.
The file/folder perms were fine and alot of other things i looked into.

I got NO errors in the error_log's or to screen even though the site was setup for it via php.ini settings,
and I could see other errors on the log file when I uploaded a file to the linux server with a purposeful php error.

I tried 'echo' code in module_invoke_all to see what was going on (see that debugging code here: http://www.cleverlogic.net/articles/debugging-drupal-white-screen-death-...).
It only went to 'Finished loading system'. and never got further to load other things/modules. Didn't help since didn't say what module was failing.

I then installed drush to hope maybe the watchdog would have something in it... the watchdog didnt even work. and on the command line gave me an error 'Error: Class 'DOMDocument' not found in filter.module, line 1098'.
I googled and figured out, to at least to get drush working, i'd need to install php-xml.
I did and the site now works (on a linode linux server btw).
Really weird, and Not sure why the error wasn't reported via the error reporting when looking at the website that i needed the php-xml module.

Dave Hirschman’s picture

I had the "headers already sent" error in my log but could not find where the script output was happening before the headers were sent. I enabled output buffering by putting output_buffering = On in php.ini (putting ob_start(); at the beginning of index.php would probably also work). Then in includes/common.inc, function drupal_goto, before call to the "header" function I put:

$badoutput = ob_get_clean();
if ($badoutput !== '') {
  $hex = bin2hex($badoutput);
  die("drupal_goto - output generated before Location header: /$badoutput/, hex=$hex.");
}

to find the extraneous output. It was in fact a byte-order mark (BOM) of efbbbf that my text editor (notepad++) was invisibly adding to the front of a custom module source file before the <?php tag. Using Encoding >> Encode in UTF-8 Without BOM solved problem.

piersg’s picture

I had a single space at the top of my module file, before the <?php tag

That's three hours of my life gone that I won't get back!

JLambrecht’s picture

After running into this typical error too often ....

I wonder if the solution is not time-related or dependant on the number of restarts of the webserver.A few apparent tips and tricks below

? try and clear all caches ( drush -l http://hostname.dom cc all )
? clear the browser cache ( just cache, no passwords or forms or anything other )
? Is the web-user permitted to access all pages ( chow user:group /drupalpath -R )
? Is this suhoshin patch activated and are there any extra settings in suhoshin.ini set, multi_header = 1 does cause problems

[VERIFIED] though at first seemingly unusual disabling - enabling the 'update module' does indeed seem to be critical to the WSOD , this was not affected by the boost module i've tested or a module ( trigger ) in the same category as 'update manager' , the module itself does not depend on anything else. This module ( update manager ) has no author ....

Indicative for this problem is indeed :

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 42 bytes) in /var/www/cms/includes/menu.inc on line 3537
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 42 bytes) in
/var/www/cms/includes/menu.inc, line 3537

JLambrecht’s picture

use Allowoverride All in the virtual host to enable .htaccess (blushing)

check here http://drupal.org/node/256410
and here for more http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride

This fixed the problem for quite some time, for very unkown reasons the problem re-occured, enabling-disabling the update-module no longer is of any effect after the above mentioned changes were performed.
[ update ] disabling mod-security compensates for the intermittent part for this issue completely, no logs so far to indicate root cause, investigation continues
[ update ] reinstalled mod-security as this was a manual install, the problem seems fixed ... for now ?

Leaves the Error: Allowed memory size of 67108864 bytes exhausted (tried to allocate ... bytes) in .... that seems to cause it all.

joeshmoe123’s picture

On Hostgator I needed at at the following to .htaccess in public_html for the install to proceed. Without it WSOD after entering database information.

# Use PHP 5.3
Action application/x-hg-php53 /cgi-sys/php53
AddHandler application/x-hg-php53 .php

# Disables existing custom php.ini and
# tells it to use the default PHP 5.3 php.ini instead.

suPHP_ConfigPath /opt/php53/lib

order allow,deny
deny from all

brainHax’s picture

i set php version to 5.3 from cpanel and it worked .

ahmedhanyfawzy’s picture

I think the easiest way to make drupal show the errors is to add the following lines to the end of settings.php :

error_reporting(-1);
$conf['error_level'] = 2;
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

Peters’s picture

Thanks, you made my day less "white"!

;)

engrafi’s picture

The suggestion above for forcing error display also worked to show up the proximate error in a complete installation process when added to install.php, which is handy to know. (Not that it helped work out what the actual problem was, but it gives a sense of scope.)

matdab’s picture

In my case - update from drupal 6.19 to 6.24, averything was OK untill I enabled custom theme. I found solution -
go to index.php and add the following lines after <?php

ini_set('display_errors',1);
error_reporting(E_ALL|E_STRICT);

Than I got errors:
Notice: unserialize() [function.unserialize]: Error at offset 2 of 16 bytes in /includes/bootstrap.inc on line 556

Warning: Cannot modify header information - headers already sent by (output started at /includes/bootstrap.inc:556) in /includes/bootstrap.inc on line 726

Warning: Cannot modify header information - headers already sent by (output started at /includes/bootstrap.inc:556) in /includes/bootstrap.inc on line 727

Warning: Cannot modify header information - headers already sent by (output started at /includes/bootstrap.inc:556) in /includes/bootstrap.inc on line 728

Warning: Cannot modify header information - headers already sent by (output started at /includes/bootstrap.inc:556) in /includes/bootstrap.inc on line 729

So I deleted DataBase and imported backup, even this time didn't turn off modules before php.update as with small update it's not necessary, update went OK, still got errors in head, so installed module:
http://drupal.org/project/variablecheck

and found one bad variable:
simplenews_from_name_39 s:14:"4grow.pl";
so went to phpMyAdmin to variable table, found the record and deleted it - now everything is OK, I don't get WSOD (white screen) even after enbling custom theme:) Good luck!

Moreover - it appeared that the errors were on production site before update on 6.19 version, but I didn't see them cause didn't have the lines in index.php, so they come out just by the updating...

LizD’s picture

Adding the code to the settings.php file worked beautifully!

dianacastillo’s picture

I had the white screen of death and php error messages did not show up, I looked in my server log and saw that a module I was using "theme devel" was using too much memory so I disabled that module

Diana Castillo

mikaoelitiana@gmail.com’s picture

I hade a WSOD and I tried to enable error reporting following

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: ...

But that didn't make it because just after the bootstrap call, drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);, the error reporting was reset from the settings.php.
So you need either to temporarly edit settings.php and index.php or just place the code after the bootstrap code. That allowed me to find the bug and fix it

hassan2’s picture

Mine was caused by the module above. removed through ftp all fine.
Hope this helps

oscardax’s picture

In my case, a debug function together with drupal_goto() was causing the WSOD.

I had a menu callback startin with dargs() (debug printout of arguments passed into the function) and ending with a drupal_goto() page redirect.

On the registry log in admin/reports/dblog, this error was being logged each time I tried the callback:
Cannot modify header information - headers already sent by (output started at /home/XXX/public_html/XXXXXX/sites/all/modules/devel/devel.module:1771) en /home/xxxx/public_html/xxxxxx/includes/common.inc en la línea 351.

Solved after commenting out the call to dargs().
Hope this may help someone.

Rah1x’s picture

Just disable this line:
"set_error_handler('_drupal_error_handler');" in bootstrap.inc

It took me 2 hours to find this.. No wounder I hate Drupal !!

Rah1x’s picture

It took me many hrs to find the solution:

1. First Comment Error Handler in bootstrap.inc:
set_error_handler('_drupal_error_handler');

2. Then I saw the errors all coming due to "public://" and "temporary://" wrappers. For this, go to includes/file.inc and hard-code the paths (This has to be done at many places in this file). For example:

if($_SERVER['REMOTE_ADDR']=='127.0.0.1'){
  $directory = str_replace("public://", DRUPAL_ROOT.'\\', $directory); #/Localhost, remove when live
  $directory = str_replace("temporary://", DRUPAL_ROOT.'\temp\\', $directory); #/Localhost, remove when live
  }else{
  $directory = str_replace("public://", DRUPAL_ROOT.'/', $directory); #/Localhost, remove when live
  $directory = str_replace("temporary://", DRUPAL_ROOT.'/temp/', $directory); #/Localhost, remove when live
  }

.

3. Run custom clean_cache.php, which has the following code:

<?php
ini_set('max_execution_time', '2400');
define('DRUPAL_ROOT', getcwd());
include_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
drupal_flush_all_caches();
?>

.

4. If you are moving site to a new server, you may also need to give recursively 777 permission to the folder:
"/sites/default/files/"

medicalmusings’s picture

Good news this abated the WSOD for me.
But why. Just turning off the error handler surely means ther eis an error, but Im ignoring it.
No entries in watchdog table. Drupal 7

theneemies’s picture

We were experiencing WSOD on specific admin pages (e.g. editing content type or editing menu item) on a Drupal Commerce (Drupal 7) site.

Sequence of config changes we tried:

1. PHP memory_limit increased from 96M to 256M << no effect
2. PHP execution time increased from 30s to 60s << no effect
3. MySQL max_allowed_packet increased from 1MB to 16MB << bingo (maybe in combination with the preceding 2)

Whew! :)

chupadupa’s picture

This worked perfectly for me. Hostgator just moved my server and it must have been set to 10M or something. I put mine on 500M Thanks.

strick’s picture

Issue:
You created a custom module and tried to setup a theme function with it. After changing an Administration setting, you get the WSOD (white screen of death) on all pages. There are no errors in the Apache or PHP error logs. This is not a memory or time out issue. You screwed up in your module ;)

# Disable your module
UPDATE yourdrupaldatabase.system SET STATUS = 1 WHERE filename LIKE ‘sites/all/module%’ AND name LIKE ‘your_custom_module_groups_%’;

# Remove main cache
DELETE FROM yourdrupaldatabase.cache;

# Remove all other cache tables.
DELETE FROM yourdrupaldatabase.cache_*

mmugo’s picture

..the
max_execution_time

in php.ini

leopinzon’s picture

If you have copied another host's filesystem and its database to another machine, You may find you watchdog plenty of Ctools compilation warnings (they seem to be harmless, but believe me, they aren't!) like this:

preg_match(): Compilation failed: disallowed Unicode code point ctools/includes/cleanstring.inc drupal

In this case you have to check the Ctools (and now that you are there, the rest of the modules) version compatibility vs. your actual PHP version.

Some versions of these modules only work on PHP 5.2 instead of PHP 5.4 and latter.

bezu60’s picture

I am getting the WOD only when I try to log in as user-1. Authenticated users can still log in and the site still works on every page (except I can't get to admin).

If I type/user/logout the site reappears.

If I type /admin while on the WOD I get:

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /home/felix/public_html/includes/database/database.inc:2168 Stack trace: #0 /home/felix/public_html/includes/database/database.inc(2168): PDOStatement->execute(Array) #1 /home/felix/public_html/includes/database/database.inc(680): DatabaseStatementBase->execute(Array, Array) #2 /home/felix/public_html/includes/database/database.inc(2347): DatabaseConnection->query('SELECT expire, ...', Array, Array) #3 /home/felix/public_html/includes/lock.inc(167): db_query('SELECT expire, ...', Array) #4 /home/felix/public_html/includes/lock.inc(146): lock_may_be_available('theme_registry:...') #5 /home/felix/public_html/includes/theme.inc(449): lock_acquire('theme_registry:...') #6 /home/felix/public_html/includes/bootstrap.inc(446): ThemeRegistry->set(Array) #7 [internal function]: DrupalCacheArray->__destruct() #8 {main} thrown in /home/felix/public_html/includes/database/database.inc on line 2168

bezu60’s picture

I forgot to add that the hosting provider just moved us to a new IP.

bezu60’s picture

My WOD turned out to be that Drupal was requesting too much MYSQL files at once, so they raised the limit and that fixed it up. Very strange as it was not causing a problem until we moved to a new IP address.

taherk’s picture

I had issue of White screen or empty screen when saving a block page in admin or going to status report. For me when I updated token module and ran update.php the issue went away.

Regards

flavio.mprado’s picture

This is caused because json_encode() moved to a new package... To solve install php5-json (apparently, this function was on php5-common before) :p

ashishdalvi’s picture

function module_invoke_all($hook) {
  $args = func_get_args();
  // Remove $hook from the arguments.
  unset($args[0]);
  $return = array();
  foreach (module_implements($hook) as $module) {

        print "Starting loading $module <br />";

        $function = $module . '_' . $hook;
        if (function_exists($function)) {
          $result = call_user_func_array($function, $args);
          if (isset($result) && is_array($result)) {
            $return = array_merge_recursive($return, $result);
          }
          elseif (isset($result)) {
            $return[] = $result;
          }
        }

        print "Finished loading $module <br />";

  }

  return $return;
}

Just add 2 print statements in the code above, then refresh the page, the module which didn't reach the "Finish loading $module" statement is the one with the problem.

Deactivate the module which dosen't finished loading.

For me it was devel module

UPDATE system SET status = 0, bootstrap = 0 WHERE name = 'module_name' LIMIT 1

Found solution on stackoverflow : http://stackoverflow.com/questions/5276010/drupal-white-screen-of-death-...

xsd’s picture

I have recently signed up for Drupal webhosting on goDaddy!

When I setup page and within few days, I have faced with an issue - where page is blank, unable to login (even as Admin user!!)

I have done the following, still no luck.

Recreate database
Reinstalled Drupal

I have read about few things and that helped fixing the issue

1. Used tip shared above
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

in the settings.php file still didn't display any errors.

2. Checked error_log file, and saw below error
PHP Fatal error: Call to undefined function json_encode()

3. Also noticed below error (not sure, whether they are related!)
Call to undefined function json_encode()

Issue resolved by
1. Going into CPanel
2. Select Php version (setting page)
3. Make sure Current PHP version: 5.5
3.1 -Enable "json"
3.2 -Enable memCache
3.3 -Enable memCached
3.4 -Enable pdo
3.5 -Enable pdo_mysql

Saved changed, and hit refresh on main page... whola (all good, back to life!)

drpl’s picture

Hello all,

I faced this problem, after investigation I found this is because Admin menu module, so I disable the module and uninstall it, then enable and it's working fine.

SwFlipNico’s picture

Hi all,

just crossed path briefly with this WSOD symptom. I had modified my server's php.ini (/etc/php5/apache2/php.ini), uncommenting the line
extension_dir = ext
...Well, let's say it wasn't a good idea... i changed the php.ini file back and everything went back to normal.
Hope this can help some of u folks,
cheers
;)

Cybertrail’s picture

My WSOD was cause by accidentally using cPanel Edit rather than Code Editor to edit settings.php. It added space to the beginning of the file, just before the <?php causing WSOD for every admin page including the login page.

HullGJ’s picture

Thanks for this well written post. After updating admin_menu inside my drupal 7 site using the update page there was an error during the install, which is because I have a shared server on Fasthosts, which for some reason doesn't allow modules to be installed or updated through the administration.

However, in my panic state I didn't realise that and it wasn't until I read this post about how to enable error messages that I could understand that I needed to reinstall the module manually by copy-pasting the module files after downloading it from the relevant *.drupal.com/projects/* page. This was achieved by a simple ftp upload to the sites/all/modules/* folder.

The most useful aspect of this page apart from the information is the writing style - clear and concise.

sabrykamal’s picture

I would like to add that I was having this problem with an old project in a new PC.

The problem was that I didn't have the "files" directory created (which I had to create manually).
After that I didn't have any problems anymore.
http://www.elkamaal.com/

barresoft’s picture

I solved it using this mentioned "debug" mode, adding the following lines on start in the root index.php file:

<?php
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

stellarvisions’s picture

That being missing caused the WSOD when running install.php -- Drupal 7.39

We forgot that BOTH settings.php AND default.settings.php are needed.

The steps above revealed errors and pointed to the issue.

---
Stella Gassaway
principal

stellarvisions : communication architects
http://www.stellarvisions.com

We design culture-driven tools™
that shape how information is
organized, displayed, shared, and
experienced.

umesh sharma’s picture

its realy helpful article for drupal developer i also use this article for our developing website of drupa 6 and drupal 7 version.

Thanks

ThomasKdot’s picture

When I updated the drupal installation on one of my customer's website (following this procedure), I got told by Filezilla that "common.inc" already exists and how to proceed. I chose "Overwrite". This was fatal.

Result: WSOD. After examining the WSOD troubleshooting guide above, I got one single error message that "entity_load()" could not be accessed by the node.module, which, after some googling, led me to common.inc. I checked, the function "entity_load" was not present in the new server installation, but it was in the unpacked drupal archive! I copied the archive version of common.inc into the includes directory on the server, overwriting the freshly installed common.inc and - Bingo! - Drupal site worked like a charm again.

Where does the wrong version come from, and how could it be that it overwrote the correct installation file in the "includes" directory?

allisonc’s picture

The issue that was causing it for me was that I had _theme function with no code inside.

function tf_cart_theme()
{
  //
}
viola_chisto’s picture

Hi there,
I had the same problem : a blank page on all websites pages, including admin pages. This appened after Drupal update 7.59.
In my case, it was a rights problem on folder sites/default/. I don't know how, but rights have changed after Drupal update.
Putting rights of the folder at 505 resolved my case.

drattar’s picture

i tried Blank pages or "white screen of death" (WSOD) in three of my sites; after extensive handling ... i found my sites hacked and malware was injected in Root directory.

this code was the malware:
https://security.stackexchange.com/questions/86094/what-does-this-malici...
https://gist.github.com/timbrandin/370f812ece9829899a11

pillona’s picture

It took me a long time to solve so I thought I would share it.
I was migrating an old drupal website to a new server. The old installation was probably using a default mysql port number, so there was no need to provide it.
However, in my new installation, if I just changed the db host in the settings.php file, the website was stalling, "waiting for .... to load" and finally erroring without much extra information. You would think that not being able to connect to the DB would at least output some errors, but in fact it was not the case...

I had to change the DB connexion string adding :portnumber (obviously replacing portnumber by the real db port number) after the dbhost, and then it worked.
e.g. here I added the 35536 port number:
$db_url = 'mysqli://drup7:mypasswor@xxxxx.privatesql:35536/drup7';