spencercritchley.com

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.

I’ll be giving a free seminar on Understanding Social Media at the Monterey County Democrats’ Center For Change in Monterey Tuesday, Nov 17, 2009 from 6 to 8 pm.

This is part of our Training For Change series for Monterey County Democrats volunteers.

Cross-posted at O’Reilly Broadcast.

The Drupal Content Management System keeps getting better and better. But the learning curve is still steep and the interface is still tricky – even after working with it for several years, some gotchas keep tripping me up. That tells me it’s worth jotting them down, hopefully to spare a few other Drupallers falling into the traps I’ve fallen into enough times for all of us.

This time: Mysterious problems logging in or accessing content.

These are fairly common and can have a variety of causes. The ones I’ve found most often:

1. You just need to clear your browser’s cache (I believe Drupal’s cache management has improved, so that this is less common in recent versions).

2. You haven’t given a particular user role permission to access a particular content type. Go to [yoursiteurl]/admin/user/permissions and make sure the appropriate boxes are checked (replace [yoursiteurl] with your actual site url, of course). Note that you need to do this every time you create a new content type (as when using CCK, the Content Construction Kit), or even when you are only adding a new field to a content type. Also note that giving a permission to Anonymous users does not mean that Authorized users inherit that permission. You have to check the box for each.

3. The SQL database has a problem. This can cause access or login problems even for the super admin user (user 1). Bearing in mind that you should back up your database before doing anything to it, you can try these fixes:

• Rebuild permissions: Go to /admin/content/node-settings/rebuild.
• Repair the Sessions table: You can use the appropriate SQL query for your DB, or an easy way is to use PHPMyAdmin. In PHPMyAdmin, choose your Drupal database, check the box next to the Sessions table, and find the “With selected” drop-down near the bottom of the page. Choose “Repair table”.

The Sessions table seems to be prone to problems. I recently came across this idea at Stanford Tech Commons for keeping it healthier. It sounds useful, but I don’t know enough about database innards to judge its reliability. Comments?