Monday, May 17, 2010

40. The search features in Drupal are excellent, 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.


39. 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.


38. 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:,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 Drupalenough 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.