Cross-posted at O’Reilly Broadcast.
Continuing my effort to spare newcomers to Drupal from falling into this powerful content management system’s most common traps, this time I look at a frequent cause of white screens – the sudden and scary devolution of a previously healthy Drupal site into a blank browser window.
This can be caused by coding mistakes, such as neglecting to conclude a line of custom PHP with a semicolon.
But white screens often happen to new Drupal admins who haven’t yet come near any custom PHP. The typical story is that you install a new module and suddenly – poof, there goes the site. You might assume that the new module is buggy or incompatible with your site.
But the cause is often simply that your web server has run out of memory for executing PHP. Since at heart Drupal runs on PHP interacting with an SQL database, your site can’t bootstrap to begin writing any html pages.
Under many web hosting accounts, the default setting for memory allocated to PHP is quite low – on mine, it’s 8 MegaBytes. But it’s not uncommon for a Drupal site with extra modules installed to require 96 MB or more.
In order to increase PHP’s memory allocation, you need access to your web server’s PHP initialization file, which is called php.ini. (You won’t have this access with web hosting plans that restrict you to the site’s home directory, since php.ini is typically found higher up the directory tree, such as in the /etc folder if you’re using Apache.)
When setting up a new Drupal site to which you plan to add extra modules, find your server’s php.ini file, open it and search for this line:
memory_limit = xM
…where “x” is some integer, such as 8. If it’s a small number like that, replace it with something more appropriate. Some Drupal modules will give you guidance on this in their documentation. I’ve found that 96 MB is a good starting point.
Save the newly edited php.ini file, and you should now be safe from memory-related white screens.
But whatever the cause of a particular problem, all of them are arguments for routinely backing up a Drupal site and its database, and/or for trying out significant changes on a test site before deploying them to the public site.