A page being completely blank is commonly referred to as a White Screen of Death (WSOD). Because there is nothing on the page, it is not trivial resolving such a situation and you will have to go under the hood in order to restore your site.
1a. Ensure you have proper PHP Configuration, no PHP syntax errors or memory limit
The best approach to solving a WSOD problem is to identify the error– looking behind the blank screen or making it not blank. If you can access server / code at all, enable error reporting or find the system error logs first.
1b. Check your recent Drupal logs
Try to go to: admin/reports/dblog (Administer -> Recent log entries)
and check for recent errors.
If you can't, you can also check for recent errors manually in your watchdog table by executing following query directly in your SQL client:
SELECT * FROM watchdog ORDER BY wid DESC LIMIT 20
On Windows you can download: MySQL Administrator (easy to use)
Server Hostname: localhost
Default Schema: (your database name)
If using the syslog module, these errors will likely be in your servers syslog.
2a. Use DTools module to diagnose common problems (Drupal 6 only)
Download Link: http://drupal.org/project/dtools
and follow the README.txt instructions how to execute it in case of a WSOD.
It will help you to fix common WSOD problems like:
- menu_execute_active_handler() in index.php returns NULL
- Content of theme('page') rendering is empty
- Duplicated module paths
Sometimes copy the same module to make backup, but if the second copy is inside Drupal, it causing module duplicates
- Fix the wrong theme and module paths in the database
2b. Easy manual quick-fixing
- renaming directory name of bad module can temporary ignore that module without database changing and find that one which cause the problem
Go to contributions module directory (sites\all\modules\ or modules\) and before each refreshment rename couple of modules.
Rename module dir: sites\all\modules\Views to sites\all\modules\Views_
and refresh the page if this helped
Rename next module dir: sites\all\modules\Panels to sites\all\modules\Panels_
and refresh the page if this helped
Note: please ignore core modules like filter, system, user, etc. to prevent internal error dependencies: those modules don't have any critical issues.
3. CSS & JS Compression Issues
If you upload your project to a shared host and do not have sites/default/files/css and /js folders with permissions set to 777, you could possibly experience a WSOD when you go to enable CSS and JS aggregation (admin/settings/performance). It's better to create these folders on your dev machine, give them the 777 permissions, and then upload your project to the live site.
However, if you find that you are live and you cannot change the permissions, disable the aggregation and try renaming the css & js folders. Then create new folders with permission 777.
When you re-enable compression, the WSOD should not re-occur.
If some module passes unexpected data types the issues will be hard to track as the error is happening in a completely different place than the place that is causing it.
Some panels ajax only threw a 500 and apache errorlog only told us:
PHP Fatal error: Unsupported operand types in .../includes/common.inc on line 4461
That source told us some module did not pass an array but php expected it:
// Add defaults to the special attached structures that should be processed differently.
$elements['#attached'] += array(
'library' => array(),
'js' => array(),
'css' => array(),
But with devel and commerce_devel module enabled hunting that down was as easy as inserting this code before said line...
// Don't continue processing bad data.
...and collecting a backtrace in the database log.
Links to common Drupal WSOD issues
Above solutions wasn't helpful enough?