Book Image

Learning Drupal 6 Module Development

Book Image

Learning Drupal 6 Module Development

Overview of this book

Table of Contents (14 chapters)
Learning Drupal 6 Module Development
About the Author
About the Reviewers

Crucial Drupal Concepts


This book is geared toward developers, and to keep the book manageable, some introductory material must be glossed or skipped.

For a thorough introduction to Drupal 6, I recommend David Mercer's book Building Powerful and Robust Websites with Drupal 6, also published by Packt Publishing.

Throughout the book, it is assumed that the reader has a moderate amount of Drupal experience, and is comfortable administering a Drupal site.

However, there are some particular facets of Drupal that deserve an introduction. We will look at some of the aspects in this book. Others are common Drupal terms that take on additional shades of meaning when examined from a developer's perspective.

In this section, we will focus on Drupal concepts that will be crucial in this book. We will start out with one of the biggest topics: nodes.


Drupal is a content management framework. When we think of content in this context, we typically think about text objects like news articles or blog entries.

This concept of a generic text-based piece of content is captured in Drupal with the term Node. A node, in Drupal parlance, is a generic object for representing textual content.


While nodes are designed to be text-based, some of the contributed multimedia modules extend the node system to handle content that is not text-centric, such as images or audio files.

Nodes are stored in the database and retrieved as needed. Among other things, all nodes have:

  • A unique Node ID (nid)

  • At least one Version ID (vid) used to track revisions

  • Creation and modification dates, as well as identifying information for the user who worked on the node

  • Metadata such as publishing state (status), language of the node (and translations), and so on

In addition to these, most nodes also have a title and a body (contents). (Administrators and developers may choose to turn off a title or body, though the database always has a place for these.)

Nodes are used to back many different kinds of text content in Drupal. To understand this, let's look briefly at the process of creating new content.

By default, creating new content in Drupal is done by clicking on the Create content link in the main navigation. On this page, the user is prompted to select the content type for their new page:

The above screenshot shows three different available content types.

The Story and Page content types are included by default. The Quotes content type is one we will create in this book.


In Chapter 4, we will create the Quotes content type. In Chapter 7, we will extend the node object to create an even more elaborate content type representing a biography.

In fact, all the three content types are text-based and each of them is implemented using nodes. For practical purposes, the node is the heart of Drupal's content management system.

In this book we will deal with nodes many times, and we will take a close look at the node API.

Comments Are Not Nodes

While most article-like content is based on the node, one major text component stands out as an exception—the comment. A comment is usually implemented as a user-level feedback mechanism attached to stories, pages, blog entries, and similar articles. When you create a new page, for example, you have the opportunity to allow or disallow user comments. If comments are enabled in read/write mode, users will be able to comment on articles.

Following is an example comment-posting screen:

Comments serve a different role than nodes. For example, a comment is always linked to a node.

While comments will not play a big role in this book, they illustrate a point: Drupal is a very flexible architecture, and can accommodate extensions (like comments) that do not fit "the pattern" of typical text content and do not make use of the node API.


Since comments are, in many ways, very node-like, there is discussion among Drupal developers of transitioning comments into the node framework in Drupal 7.

While it is possible to implement a new form of content by creating a library that does not make use of nodes, it is often more efficient to build on the existing (well-tested, robust) node API.


Another important type of object in Drupal is the user. User records are maintained using this object type. Just as with comments and nodes, user data is stored in the database, and drawn out during processing.

Information about a user is used for purposes such as authentication, determining preferences and permissions, and logging.

In the course of this book, we will make use of the user APIs to perform permissions checks, get contact information, and discover user preferences.

Access and Security

Permissions are closely linked to the user object. Drupal provides a role-based mechanism for granting permissions to collections of users. In a nutshell, a user belongs to a role, and permissions are granted to (or revoked from) a role.

Thus, when checking access to a resource, Drupal loads a user object, finds the user's roles, and then finds the roles' permissions.

Does this sound like a lot of work? Well, it's not work the module developer must do. Drupal provides functions for performing permissions checks. Most of the time, module code does not need to directly discover a user's role before determining permissions. The users API does that work for us.

Blocks and Page Rendering

The term block is equally important. While a node is used to store and present articles and "larger" pieces of content, a block is used to present smaller bits of content. For example, navigational menus, daily quotes, polls, and search boxes are often presented using blocks.

A block is not a type of content. Actually, it is a unit of abstraction (a placeholder) used primarily to display other content. Administrators can use the Blocks editor to determine where blocks are displayed on a themed page:

The highlighted sections in the above screenshot show where blocks can be displayed.

From the developer's perspective, blocks are an important part of module creation. In fact, our very first module (which we will create in the next chapter) will display a block.

Defining a block in a module is a matter of selecting content to display, and then passing it on to the correct formatting tools.

In Chapters 3 and 4, we will look into themes, where we will format block content.


Closely related to blocks are menus. Drupal has a sophisticated menu system whose main purpose is the construction of navigation. For example, the above screenshot shows the main menu, with such items as Code review, My account, Create content, and so on. This menu is dynamically generated by the Drupal menu system.

But the Drupal menu system is a more sophisticated device than this simple description. It also functions as the primary tool for mapping URLs to specific handling routines. Using the menu API, developers can correlate paths with specially defined functions.

In Chapter 5, we will use the menu system to create a JSON (JavaScript Over the Network) service, and in Chapter 6 we will examine the more traditional way of mapping a path to a module.


The primary method of submitting content over the Web is through HTML forms. While the ubiquity of forms makes life easy for the web user, the dearth of good forms processing tools usually makes form development a joyless chore for programmers.

However, forms processing is one area in which Drupal excels. The Forms API (FAPI) provides a programming interface that takes the pain out of form development (or at least significantly reduces the pain).

Using the FAPI, developers can provide a single form definition and let Drupal build and display the form, collect the results, and even validate and escape form data. Drupal even provides forms caching and advanced AHAH (Asynchronous HTML And HTTP) features.

As Drupal development has progressed, the Forms API has got better and better, and the Drupal 6 version exhibits many improvements.

Chapter 6 is the first to explicitly cover the forms API, and it is used again in Chapter 7.

Database and Schema APIs

Beneath many of these higher-level frameworks and APIs is the layer responsible for managing and manipulating the database. Drupal provides a low-level database API to simplify the process of writing SQL queries.

This API provides some degree of security for database queries, and also makes it easier to write SQL that is portable across different databases.

Also the new Schema API, introduced in Drupal 6, makes it possible to define how a database should be structured without writing the actual SQL. Since different databases use different constructs for defining tables, this API simplifies the project of writing portable modules.

These APIs are discussed primarily in Chapter 7.

There are other aspects of Drupal that we will touch upon in this book, including taxonomies (sometimes called categories), filters, and actions. But there is no in-depth discussion of these here. To learn more, consult the Drupal handbooks:


Chapters 8 and 9 will make use of filters and actions inside modules.