Interview: John VanDyk, Author of Pro Drupal Development

Recently, OStatic did a post on the book Pro Drupal Development, in which we offered the first chapter and contents of the book to everyone as a PDF file. OStatic is based on Drupal-- an extremely powerful, modular open source content management system (CMS) also used by sites such as Fast Company and The Onion. Backed by its own foundation, Drupal is challenging top proprietary CMS packages. We found some time with Pro Drupal Development's author John VanDyk, and he gave us some good insights into Drupal and his book.

OStatic: Drupal has matured since your first edition of Pro Drupal Development, and in its new version 6. What would you say are the most attractive new aspects for developers?

While Drupal 6 offers numerous improvements in usability and multilingual support, fundamentally it continues to move towards Drupal's philosophy of offering a solid framework where everything is pluggable, overridable, or both. For example, take web forms like the login form. If you don't like the way a certain form looks, as a developer you have access to change the form while it is being built. Or if you want to add more validation to a form field, you can -- even if the form is being provided by a third-party module. I could go on and on about this (in fact, I do in chapter 10, which covers forms) but the take-home message is that Drupal 6 offers more flexibility and more power for developers than ever before.

Developers will like the OpenID shared identity login system, the ability to create actions that site administrators can assign to system events (such as automatically unpublishing comments that contain profanity), and especially the revamped theming system.

It can be difficult to bridge the world of designers and developers, but Drupal 6 helps to bring them together by allowing any themable (think "skinnable") component of a web page to be changed by editing a template file containing prepopulated variables. That means that designers can work with files that make sense to them, without a lot of embedded PHP code. In Drupal, a web page is made up of these themable components, so everything is on the table. A third-party module called Theme Developer Module is sort of like Firebug for Drupal and makes it easy to see which part of the web page is produced by which template file.

Some of the biggest wins in Drupal 6 are from third-party modules that plug into the core system. Chief among these is the Views Module, an interactive query builder which allows the creation of flexible lists of website content through a nice UI on the front end, while offering developers a rich plugin architecture on the backend. Many other third-party modules are starting to include their own preset views that leverage the Views Module.

OStatic: Can you describe, as an overview, what a module is in Drupal and what the process of writing one involves?

When developers learn that modifying Drupal's core code is a no-no, they often have a panic moment. "How, then will I bend Drupal to do my will?," they ask. Easy: by writing a module. The first part of writing a module is  writing a .info file, where you describe your module to Drupal. Here's an example from the Forum Module:

; $Id: forum.info,v 1.6 2007/06/08 05:50:54 dries Exp $

name = Forum

description = Enables threaded discussions about general topics.

dependencies[] = taxonomy

dependencies[] = comment

package = Core - optional

core = 6.x

This gives Drupal enough information to list the module on the modules administration page, and to tell whether the module is compatible with the version of Drupal being run (in this case, 6.x). Drupal will also make sure the dependent modules are present.

A module may have a .install file containing code that runs when the module is first installed. For example, some database tables may be needed, or some values may need to be initialized in Drupal's persistent variable system.

Finally, the .module file itself contains the code that does whatever it is that your module will do. And that's just about anything. There were 3,430 modules in the repository last time I checked, so it's a good idea to check if the module you're thinking about writing is already written. Drupal Modules is a good place to do that.

New Drupal developers are also often stymied by the question "When does my code run? I put it in a module, but when does the module run?" Answering that question requires understanding of the Inversion of Control design pattern that Drupal uses, often called "hooks" or "callbacks". You name your functions in a certain way, and Drupal will automatically call your code at the appropriate time, depending on how you've named the functions. For more on Drupal's hooks, see this page.

OStatic: Drupal is flexible at handling events automatically and employing triggers. How do developers make use of these features?

There are really two answers here. At the code level, that's always what Drupal has been about: having your code run when a certain event happens. For example, the following code would send a tweet to my Twitter account every time someone logs in to the Drupal site (it requires the third-party Twitter Module to be installed to do the dirty work).

function mymodulename_user($op, &$edit, &$account) {

  if ($op == 'login') {

  // Bring twitter-related functions into scope.

    module_load_include('inc', 'twitter');

    // Use t() for proper localization.
    $text = t('@username logged in', array('@username' => $account->name));

    // Post to twitter using the twitter module.
    twitter_set_status('clouseau', 'secret', $text);

  }

}

That's fine if you are a programmer. But what if we took the whole idea of "Send a message to Twitter" and abstracted it? Then we could use a nice user interface to associate the action "Send a message to Twitter" with one of Drupal's common events,  such as when a user logs in, or posts content, or creates a new account. That is what the new features in Drupal 6 provide: the user interface for doing such associations between actions and events. A trigger is an event that has been exposed in the user interface.

You can also create your own triggers. Perhaps you want to go the other way: you want actions to happen in Drupal when  a new tweet is posted to your Twitter account! Chapter 3 of the book tells you how to make your own triggers.

OStatic: I have always been impressed with the search features in Drupal, as compared to search in other content management systems. What makes these so good?

Drupal's search is so good because Drupal doesn't treat its content as a big bucket of text; rather, all of the fine-grained semantic information that Drupal knows about can be used to fine-tune search results. That includes the type of content, any classification information from the taxonomy system, and the usual content metadata. Inside the search engine is an extensible indexer that can accept pretty much anything. In the book, one of the examples uses Drupal to index an external non-Drupal database.

And as usual, you can tweak and override the search system to adjust the user interface, the way content is ranked, and the way results are displayed. That said, Drupal integrates well with external search engines such as Apache Solr, Xapian, and Sphinx if the built-in Drupal search does not meet your needs.

OStatic: Does your book provide actual code for example modules in Drupal?

Yes. In fact, the code is downloadable online, so you don't have to type it in yourself. The examples are heavily commented and are there to translate the concepts introduced in the book into actual code. Some of the examples have been taken by members of the community, improved, and made into supported third-party modules; others, such as the giant bunny example on page 107, are useful for demonstrating code but not so useful in the real world.

OStatic: Acquia is working on a commercially supported version of Drupal. What do you think of that effort?

I think it is a natural step and a sign that Drupal is maturing. The explosive growth that Drupal has seen in the last five years is only helped by having the perceived legitimacy that a commercially supported version provides. Though Drupal is often used internally by IT teams, having the option of a commercial name behind it can bring more confidence to that decision and grow the Drupal community at the same time.

Acquia has already been a benefit to the community in many ways, such as their involvement in Boston and Szeged Drupal Conferences this year, and their sponsorship of the upcoming Do It With Drupal seminar, which is focused more on leveraging Drupal to build social networks and online communities. (Do It With Drupal is being organized by Lullabot, my employer.)

OStatic: Are there any free Drupal resources on the web that you can point to as being useful?

I've devoted a whole appendix in the book to that, but here are some highlights. For developers interested in getting a feel for what's going on in the community, take a look at Planet Drupal, the aggregation of many Drupal-related blog posts. The Drupal Handbooks are constantly improving and contain a Videocasts section that includes presentations from the latest Drupal Conference in Szeged. And of course, there are the free articles and regular podcasts from Lullabot.

I also encourage developers to get involved with Drupal. A great place to get started is the Getting Involved handbook.

OStatic: What do you wish for in future versions of Drupal?

Drupal is a healthy and growing open source project. So I wish for more of the same! That is, more people coming together to tackle difficult issues like improving the user interface, performance, documentation and integration with other systems. Some specific things I'd like to see are memcache support, an expanded workflow engine, better image handling, and more Drupal distributions (using installation profiles) for vertical markets. These features are available now via third-party modules, but having them as part of core adds polish and makes Drupal even more attractive.