Silent WSODs (White Screen of Death) - fixing step by step
If you experienced White Screen of Death (WSOD) and your page is completely blank, don't panic.
1. Make sure that you have proper PHP Configuration, no PHP syntax errors or memory limit
Read more: http://drupal.org/node/158043
You can also check manually your {watchdog} table for recent errors
SELECT * FROM watchdog LIMIT 20On Windows you can download: MySQL Administrator (usage is very easy)
http://dev.mysql.com/downloads/gui-tools/5.0.html
2a. You may use DTools module to diagnose common problems for you
Download Link: http://drupal.org/project/dtools
and follow the README.txt instruction how to execute it when you've got WSOD on all the pages
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 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.
In example:
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 doesn'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.
Hopefully when you re-enable your compression, you won't get the WSOD.
Links to common Drupal WSOD issues
#495194: Fatal error: Unsupported operand types in form.inc on line 511 cause WSOD
#352344: Fatal error: Unsupported operand types in common.inc on line 1369
#496198: module_list() called with wrong arguments causing WSOD and breaking theme_registry
More comming soon...
---
Above solutions wasn't helpful enough?
Contact me:
kenorb: http://drupal.org/user/191974
with the details of the problems, I'll try to help you
When all else fails to fix the WSCOD
I experienced the WSCOD on my test server while updating modules. I could not get back to my Admin page even after trying all of the excellent suggestions above. I was able to recover from the WSCOD and also learned the cause of the problem-- custom snippets that were causing php fatal errors.
See http://drupal.org/node/499290#comment-1742156 for the details for how I recovered and how you can minimize WSOD if you use custom snippets in your site.
Check your theme!
After several hours trying to sort sitewide wsod, with no joy, a post from Kenorb told me my theme might be at fault.
I thought I'd disabled theme, by renaming, and setting status to 0 in mysql table; but after kenorb's post I also deleted it, and - presto! - two sites came back from the wsod.
So, maybe others affected by blank screens should also have a look at whether a theme is somehow acting up.
____________________________
DocMartin and Hong Kong Outdoors
CHMOD ugo -rwx questionable mod
in case of a sitewide WSOD caused by a bad mod. Instead of mv it around.
Not sure what you mean CHMOD ugo......
can you explain. Thanks.
What he means...
chmodis a Unix (Linux, BSD, etc.) shell command whichchanges the permission/accessmodes of a file or directory. In this case, the command:chmod ugo -rwx«questionable mod»where «questionable mod» is a direcory (i.e. folder) containing a module, will prevent access to the module from everyone.
Specifically the code would set the
user,group andothers permissions,-removingread,write, and execute permissions (i.e. all permissions) from the directory.Kevin Cole
Gallaudet Research Institute
Washington, DC
UTF-8 and BOM
I had a mix of WSOD and "Headers already sent" problems with my custom module. Turned out the issue was use of utf-8 encoded file with BOM (byte order mark) set. Saved it without BOM and all went fine then.
Encoding php files in utf-8 is handy if you are handling non-english text, but make sure not to use BOM.
Helpful stuff
drupal_flush_all_caches() :
_drupal_flush_css_js();
drupal_clear_css_cache();
drupal_clear_js_cache();
drupal_rebuild_theme_registry();
menu_rebuild();
node_types_rebuild();
cache_clear_all();
Drupal best CMS