Why Drupal? The Coder's Perspective

DrupalDries Buytaert, founder of Drupal, recently wrote about how it snaps together like Lego pieces, building something he calls "The Assembled Web".

Being more efficient in the way we assemble a website will allow us to focus on the things that matter more, like innovation and creativity. By standing on the shoulders of giants, we can make things look and operate more beautifully than we'd ever have expected.

This got us thinking about why we use Drupal. For us at Monkeys At Keyboards working with it is very close to the experience that Dries suggested. I love working with Drupal and something keeps me coming back to it for every website project. Drupal.org tells me that at the time of this writing I have been making Drupal websites for 7 years and 4 months.

Ewok Village
Ewok village from lego.com

What we have learned is that some Drupal modules are flexible and adaptable. For example Views is easy to customize. My minor nitpick in Dries' otherwise darned fine idea is Drupal theming. Occasionally modules do not perform as expected so we have to change the theming to make it behave exactly how we want.

There are times when custom theming work is necessary to fulfill customer requirements or our own desire to reduce clumsiness in the user interface. Drupal modules sometimes are not quite designed with our exact usage in mind.

This is similar to the way the Ewok Village Lego kit has trouble making something other than the exact village that the Lego designers intended.

Fortunately, Drupal is not as rigid as Ewok Legos and there are often several workable solutions to the problem of changing how modules interact with people. As a developer, Drupal is a playground filled with equipment for teasing and tweaking the work of other people. This enables us to make it behave how we want it to.

This post could go very deep into describing how to use and not abuse the following features, but I have chosen to include a high level list of techniques that we use to glue Drupal modules together into a cohesive whole. The list is our order of preferred techniques when there are multiple options for changing things.

  • The first rule of theming is that if it can be done in CSS, it must be done in CSS. Normally we do this in a custom theme, which we discussed in a previous post. Be careful not to break mobile support!
  • Attempt to alter the HTML that Drupal is producing in a theme's template.php file using preprocessing hooks.
  • Create or modify theme templates to override default behavior.
  • Alter the behavior at the module level.
  • Use JQuery to rearrange or otherwise alter the DOM client side. Hax! This is a method of last resort, except for intentional uses such as AJAX.
  • Give up and write a custom solution using Drupal hooks, forms, and database features.

Luckily, in all but a very few cases, we don't make it to the last item on the list and write miles of custom code. CSS is powerful in modern browsers, so we take maximum advantage of this. Since CSS styling doesn't affect the operations of modules, we can focus on making websites look amazing. Stay tuned for case studies on the custom module solutions we have built.

Note: Next week we will hear about Laura the designer and project manager's take on "Why Drupal?"