January 9, 2013

Drupal Commandments

By Max Pearl

About a year ago, I was deeply enmeshed in fixing a rather badly-developed Drupal site for a client. In my frustration and anger, I wrote these commandments. I thought these would go without saying, but obviously, they needed to be said.

1. Thou shalt respect thy client, and thy client's budget, both for this project, and for future maintenance. Nonprofits know that money spent on a web project is an important investment. They also know that money spent on a web project can take away from thier mission-based work. And also, many clients don't understand when something will take a very long time, and when something won't, and it is hard to always know how high a priority something is. Which is why we almost never just do what the client asks, unless it is quite trivial to implement. A conversation is always important. Clients need to know what the trade-offs are, and how much one request might eat into the budget, when there are other things that they'd like to get done.

2. Thou shalt assume that some other shop may take over this project at some point. Face it. Clients fire web developers all the time, not always for bad reasons. It could be that they want to work with someone local. They might have hired internally. Whatever the reasons are, it's essential to assume that some day, it will be someone else's responsibility to maintain the monstrosity that you created. That's why keeping to drupal best practices and documenting anything that's custom is essential.

3. Thou shalt at all times make sure that thy decisions will be cost-effective in the long run, and thou shalt not use difficult to maintain code or modules unless absolutely necessary, determined by use case.

4. Thou shalt create a custom modules only in the most needed situations, and never without documentation for both end-user and developer. I know a lot of developers like to include custom modules almost as a matter of course. We don't. Because custom code can be difficult (and costly) to maintain, it adds cost to the project, and should only be done when necessary. In addition, using drupal contributed modules instead of custom modules, even when you could roll your own, helps the community if you make changes to those modules to fit your particular use case.

5. Thou shalt let Drupal do what it does best, like forms, menus and views, and thou shalt not hard code forms or menus into the theme.

6. Thou shalt make it easy for thine clients to add new menu items, change taxonomy, add new content, organize content, and add new fields to content types.

7. Thou shalt never create back-end database objects that cannot be seen or manipulated via the Drupal admin interface.

8. Thou shalt use imagecache presets, and not hard-code image sizes into the theme. Now that this is in core, there is no reason to do anything else.

9. Thou shalt never use very complex modules without well-thought-out information architecture and use cases. Example, using the content access module to do things you can do with core.

10. Thou shalt use taxonomy when appropriate, instead of coding fields with different names but the same data into different content types.

Thou shalt evangelize these commandments wherever thou shalt work. We do.