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
Imagecache problems
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
WSOD on login from date_api
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
Unsupported operand types in Drupal 6.x
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 :)
Be careful with menu callbacks invoked by hook_menu
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.
Thanks for the "Rebuild Permissions" custom script
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
You're not going to believe this.
I removed 5 blank lines at the end of template.php and it fixed my WSOD.
Fixed!
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:
The closing ?>, the blank line, and the <?php tags caused the WSOD. Deleting them resolved the issue.
Good code:
I hope this helps someone!
This also fixed it for
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...
good documentation for wsod
it took about 3 minutes to find out why a site i worked on was wsod-ed. drupal has great documentation.
Clear the Cache
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.
WSOD running update.php
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>
WSOD and Drupal Tweaks module
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.
Make sure your function is returning required values
In my case, I wasn't returning the form. Instead my code was:
... when it should have been:
This will cause a WSOD that produces no errors written to the php or apache logs.
.htaccess file
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
Panels
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
White Screen of Death due to postgres 9
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.
Update Module = WSOD - Our Fix
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.
Unserializing does not work on Postgresql 9...
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
That did the trick!
That did the trick!
Use dtools & wsod module for errors to show up
I was debugging a white screen of death (WSOD) problem a couple days ago and putting:
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
Drupal Commons
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.)
White Screen Of Death
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)
Apache Solr was causing the White Screen at the Block page!
Hi
After I disabled it ..I can see the blocks page now..I Still need to use "Apache Solr "
Thanks
My solve for my WSOD issue
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.
When I transferred by website
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.
Another cause of WSOD when trying to change colors in themes
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
One more solution
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)
Drupal 7 + Devel module
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.
PHP MEMORY
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.
Drush Can Display Watchdog Entries
For a recent WSOD I had to deal with, I ended up finding my issue via the Watchdog entries. Drush helped me with this:
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!
When moving my site from
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.
headers already sent - BOM
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 (puttingob_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: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.Almost the same...
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!
APC and/or suhoshin
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
? FIX ( partial / temporary )
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.
Hostgator
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
Set php version to 5.3
i set php version to 5.3 from cpanel and it worked .
The Easiest way is to enable the error reporting on settings.php
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);
Thanks, you made my day less
Thanks, you made my day less "white"!
;)
forcing error display
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.)
white (blank) screen after enabling custom theme after update
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...
Thank you!
Adding the code to the settings.php file worked beautifully!
white screen of death due to no memory left
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
Place error reporting after bootstrap call
I hade a WSOD and I tried to enable error reporting 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
remote streamwrapper
Mine was caused by the module above. removed through ftp all fine.
Hope this helps
In my case, a debug function
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.
Just disable this
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 !!
White Screen due to URL Wrappers
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:
.
3. Run custom clean_cache.php, which has the following code:
.
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/"
disbling the error handler
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
MySQL max_allowed_packet increased worked for us
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! :)
BSOD FIX
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.
Added Theme to Custom Module Causes WSOD
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_*
For me, it turned out to be..
..the
max_execution_time
in php.ini
PHP / Modules compatibility versions
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.
I am getting the WOD only
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
I forgot to add that the
I forgot to add that the hosting provider just moved us to a new IP.
Solution
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.
I had issue of White screen
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
Installing drupal on Ubuntu 13.10 gives a wsod
This is caused because
json_encode()
moved to a new package... To solve install php5-json (apparently, this function was on php5-common before) :pfunction module_invoke_all(
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-...
Drupal 7 & blank/white page (for all users)
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!)
Hello all,
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.
Drupal 7: Just met the famous WSOD....
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
;)
My WSOD was cause by
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.
Just enabling error console led to fix
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.
sabry
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/
Solved!
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);
need to leave default.settings.php
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.
thanks for this page
its realy helpful article for drupal developer i also use this article for our developing website of drupa 6 and drupal 7 version.
Thanks
WSOD caused by common.inc
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?
check for any _theme functions
The issue that was causing it for me was that I had _theme function with no code inside.
My case : rights on sites/default/ folder
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.
i tried Blank pages or "white
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
Check your DB connection information
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';