Over at the Acquia weblog, Jeff Whatcott is asking for people’s Drupal disaster stories. I asked a handful of people in the office what they would add to the list and before we knew it, we quickly had a decent list of avoidable disasters.

Building websites with Drupal can be like raising an unruly child that only does what it wants to do. We’re fond parents, however, and we love Drupal. Every item in this list is a usability issue, so we’ve posted this to the Top User Experience Improvements in Drupal 7 wiki page with the faith that D7 will play well with others and not bring as many people to tears.

Many thanks to catch and gaele for providing links to the Drupal issue queue.

1. Within minutes of installing Drupal, enabling a few contrib modules immediately used up the default 8MB memory allotment. WSOD!

   Solution: Increase Drupal’s memory limit in settings.php.

2. User 1 was accidentally deleted once. Drupal core not only allows this, but it conveniently places the “Delete” button right next to the “Save” button.

   Solution: This is being worked out for Drupal 7: Disallow deletion of user 1. In the meantime, use the User Protect module or display contextual help information at user/*/delete with a custom block or Help tip.

3. For the longest time, the “File uploads” settings arbitrarily cut in half the maximum upload size set by php.ini without informing the administrator that it was doing so until a file upload exceeded the limit.

   Solution: This was recently fixed in Drupal core.

4. The input format used to create numerous posts was later deleted. Drupal core did not notify the administrator what possible consequences there might be. The result was that the original authors could no longer edit their posts.

   Solution: Don’t delete any core input formats! If you do, run an SQL query like UPDATE node_revisions SET format = '4' WHERE format = '1' (where ‘4’ is a new input format created to replace ‘1’, which is the format that was deleted). This is being worked out for Drupal 7: Disappearing edit tabs due to input format permissions.

5. The “User login” block was disabled and all login forms seemingly disappeared. Drupal core did not adequately inform the administrator that this common scenario might happen makes matters worse by not having a login menu item.

   Solution: Go to the user/login path on your site at http://example.com/?q=user/login (where “example.com” is your website’s domain name or IP address). A core login menu item has been proposed: Provide log-in item for navigation menu

6. Site maintenance mode was turned on and the administrator didn’t know how to log in. The site maintenance form did explain how to log in again but Drupal really should include that information in the status messages that persistently say “Site is in maintenance mode” across the site.

   Solution: Go to the user/login path on your site at http://example.com/?q=user/login (where “example.com” is your website’s domain name or IP address).

7. Drupal’s access rules actually allows an administrator to ban his or her current IP address or username without informing the administrator that bad things might happen.

   Solution: Go into the Drupal database and remove the offending rules from the ‘access’ table. This has been fixed in Drupal 7!

8. The path module allows critical paths to be overridden, such as user and admin, without informing the administrator of impending disasters.

   Solution: Most of the time you can delete the path alias at admin/build/path, or use a module like Find URL Alias to find the offending aliases and delete them.

9. On one site, comments seemed to randomly disappear. Authors could edit their their posts because of the “edit own (content type name”) permission, but this also allowed them to delete their posts. When a post is deleted, so are the comments attached to it.

   Solution: Drupal 6 now has a “delete (content type name)” permission that makes this easier to to anticipate. Drupal 5 can use a node access module like Content Access. In either case, however, the author is not adequately informed when deleting a post that the post’s comments will also be deleted. Use a custom block or Help tip and display contextual help information at node/*/delete or simply don’t allow members to edit their posts (Drupal 5) or delete them (Drupal 6).

This wasn’t intended to be a “top ten” list, but let’s round this out with a few pet peeves of ours:

10.  Drupal terminology can be confusing. For example, every post is a node but not every node is a post. Chatrooms and panels are nodes but not posts, at least in the traditional sense of the word. The content/node/post part is being discussed: Content, post, node (type)

11.  Administration pages in core often have titles and paths that aren’t in sync, leading to an environment that is generally hard to master. For example, “URL aliases” is at paths, “Blocks” is at block, “Posts” is at admin/content/node, and so on. This is being worked out for Drupal 7: admin/foo URLs should be consistent

12.  There is too little or too much developer documentation. The drupal_goto() function, for example, supports query strings but finding an actual example of that is surprisingly difficult. Victor Kareh’s tale of how difficult it is to contribute a Drupal module is another example.

What are your favorite disaster stories? Please post them here in the comments with your solutions, and be sure to send them to Jeff, too!