Over the last couple of years, the popularity of Drupal has exploded, to the point where some pretty big names have taken notice. Media companies such as MTV UK, Lifetime, and Sony BMG Records are using Drupal as a means of building loyal communities around their products. Print publishers such as the

Back in the dim recesses of time (the 1990s, for those who remember zeppelins and Model T cars), web pages were nothing more than simple text files nestled comfortably into folders on a server somewhere on the Internet. With names like index.html, news.html, about_us.html, and so on, these files were viewable by anyone with a web browser. Using the HTML markup language, these files could link back and forth to each other, include images and other media, and generally make themselves presentable. A website, as the hipsters of that day would explain, was just a collection of those files in a particular folder, as pictured in .

This system worked pretty well, and it made sense. Every URL that a user on the Internet could visit corresponded to a unique .html file on the web server. If you wanted to organize them into sections, you made a folder and moved the files into that folder; for example, http://www.example.com/news/ would be the address to the “News” section of the site, and the 1997 newsletter would be located at http://www.example.com/news/fall_1997_products.html. When the webmaster (or the intern) needed to fix a problem, they could look at the page in their web browser and open up the matching file on the web server to tweak it.

Unfortunately, as websites grew in size, it was obvious that this approach didn’t scale well. After a year or so of adding pages and shuffling directories around, many sites had dozens, hundreds, or sometimes even thousands of pages to manage. And that, friends, caused some serious problems:

The ” section of each chapter will discuss, compare, and contrast various options for fulfilling the client’s needs in Drupal, and how the authors came to decide on the solutions selected in the chapter.

As discussed in , each piece of content in Drupal, from a static page to a blog entry or a poll, is called a node. Drupal comes with two content types by default: Page, intended for static content such as an “About Us” page, and Story, intended for content that will be frequently posted, such as news articles. But like most things in Drupal, content types are fully configurable. shows the “Create content” page on a typical Drupal site with several content types available. This page is found under the path “node/add” (http://www.example.com/node/add).

shows an example of a typical node form, which is used to add or edit a piece of content. Each node has a Title, which identifies the node in content listings and controls the title of the web page it’s on, and most nodes also have a Body field, which holds its primary content. Although the extensive options at the bottom of this form may seem daunting, don’t worry. A general site visitor won’t have permissions to change Menu settings, Authoring information, or other settings, so they simply do not show up on the form for these users.

The module administration page, available from Administer→Site building→Modules (admin/build/modules) and depicted in , is where Drupal provides configuration options for your website’s functionality. Related modules are grouped together within fieldsets, and each module entry contains a description and an indication of which version is currently running on the site. This version information can be extremely useful when troubleshooting problems.

Modules may be switched on and off by toggling their Enabled checkboxes, which allows you to custom-tailor the functionality of any Drupal site to its unique needs, without bogging it down with needless overhead.

A module might also have dependencies. That is, it might require one or more other modules in order to work properly. For example, the Forum module requires both the Comment and Taxonomy modules to be enabled before it can be enabled. If you forget to do this, a confirmation screen will appear asking you whether to enable the required modules in order to proceed.

Nearly all modules also have one or more administration pages associated with them for configuring various settings. Most often, these are found under Administer→Site configuration (admin/settings) or Administer→Site building (admin/build). Because modules can easily add additional administration pages, we recommend navigating to the Administration (admin) main page and clicking the “By module” tab (admin/, as pictured in , to view all administrative options broken down module by module. This is a best practice to follow after installing a new module.

In the earlier hands-on section (”), we created an “About Us” page and a “Home” page and added them to our site’s menu. But if you return to those pages, you’ll see that the URL is something like http://www.example.com/about?. Wouldn’t it be great if we could instead give these pages nice search URLs like http://www.example.com/node/1? We can, with Drupal core’s Path module.

The Path module allows us to specify human-readable URLs, referred to as URL , which mask Drupal’s default way of naming paths:

There are multiple tools that specialize in automated spam detection, but two in particular are worthy of mention in a Drupal site context: Akismet and Mollom. Each of these tools is a web service and requires an “API key,” a specific random string of characters, to communicate between a website and the central reporting server.

Akismet (http://akismet.com) is a service created by Matt Mullenweg, creator and project lead of the blogging platform WordPress. It scans through the content of your site’s comments and “trackbacks” (excerpts of posts on other blogs that link to yours), and based on its analysis of millions of other blogs’ content, will either delete the content if it’s spam, or send it on through if it’s clean (or “ham”). Installing the Akismet module allows you to tap into the collective intelligence of millions of other blogs using the service. Chances are good that by the time a spammer trains its automated posting scripts on your website, Akismet already knows how to fingerprint the attacker and will delete the comment before it’s seen by anyone on your site. And if not, Akismet provides the ability to manually mark the content as spam, and uses that data to learn from its mistakes. Akismet has been around since 2005 and has captured over seven billion spam comments, making it a tried and tested solution. The Akismet module is available from http://drupal.org/project/akismet, and an API key for the service may be obtained from http://wordpress.com/api-keys/.

Mollom (http://mollom.com) is a newer service started by Benjamin Schrauwen and Dries Buytaert, creator and project lead of Drupal. It performs a very similar service to Akismet by automatically scanning the content of comments and preventing obvious spam from even being posted to the website. Like Akismet, your website benefits from the collective intelligence of every other website that has a Mollom plug-in installed, and Mollom is also compatible with many different content management systems and programming languages.

Drupal.org has a large repository of free themes that have been uploaded by contributors. You can find a listing of these themes at http://drupal.org/project/Themes, or you can try them out “live” at http://themegarden.org.

The quality of the themes in the Drupal repository varies greatly. These themes have been created for a wide variety of purposes and needs by contributors with a broad range of programming and design skills. Download several themes and be sure to read their README.txt files to determine how to best use them. Many of these themes can be used as a starting point from which site administrators can customize their own site-specialized presentation.

Several companies offering for-purchase themes have also emerged in the Drupal ecosystem. These themes tend to be higher quality, a bit more “bullet-proof,” and may allow for easier customization by administrators.

Installing a theme requires almost exactly the same process as installing a module. Download the theme’s .tar.gz file from its project page and extract it. Place the theme’s directory into the sites/all/themes directory, and your new theme should appear on the Themes administration page in your Drupal installation, as shown in .

Themes can be switched on from the Themes page at Administer→Site building→Themes (admin/build/themes), shown in .

Most administrators can just ignore the “Enabled” column—the “Default” column is what actually defines the theme that all users without permission to select themes will see. Enabling our new theme is as simple as selecting it in the Default column and hitting the “Save configuration” button at the bottom of the form. The new default theme should affect the site design immediately.

As mentioned previously in the chapter, by default Drupal’s content entry is done with HTML. Like most earthlings, Mike and Jeanne aren’t fluent in code, so it’s important that they be able to format their content and add images without it. Not surprisingly, a number of community solutions to this issue have cropped up over the years:

Drupal core provides this site with a good starting point. It provides the needed user authentication and allows the creation of several different types of content, such as “job” and “application” types. Drupal’s out-of-box functionality gives each one of these new types only a “Title” and “Body” field. We’ll need quite a few more fields so that users can enter data into different fields, and so that we can pull out information from certain fields to make listings of content.

Functionally, CCK is set up into two end-user pieces. The first of these are fields, which allow a user to save data into your site. Fields represent the type of data that needs to be saved, such as integer, decimal, or text. When choosing a field to add to a content type, the first decision you need to make is what kind of data is being stored “behind the scenes” in the form. Will the information entered into the form be something basic like text or numbers, or something more special like a relationship to another node or user? The field types included in CCK “core” are displayed in . Other modules, such as Fivestar (

The “jobs” view will provide a listing of jobs at Epic University, categorized by department. The completed view will be similar to the one pictured in .

The next step is figuring out how to translate that set of features into a shopping list of Drupal functionality. Bob and Sarah are fortunate: the core Drupal software can provide most of what they’re looking for without any additions. We’ll set up special permissions for contributors, and use Drupal’s administrative tools to create a custom Product Review content type. Those Product Reviews will be the meat of the site’s content.

We’ll use the CCK module to add custom fields to the Product Review content type for the various bits of information we want to record. We’ll also use the Views module to build a listing page of products for quick scanning. Three requirements for Bob and Sarah’s website, though, will require functionality that we haven’t seen yet: importing product information from another website, allowing users to rate and review content, and building a custom search page.

We’ll start by creating the base content type and adding the simplest pieces: the basic text fields needed for the Pros and Cons, grouping those fields together, and allowing comments:

The Amazon module is actually an entire collection of modules, each with its own purpose:

The Amazon module doesn’t require much configuration, but there are several important settings that most site administrators will want to change on its configuration page, at Administer→Site configuration→Amazon API (admin/settings/amazon) and pictured in .

Because each country that Amazon operates in has a separate database of products, prices, and availability information, you’ll want to choose the Locale that your website’s users reside in. This setting will determine which Amazon website (

Having set up the Amazon module, we’re ready to continue customizing the Product Review content type:

Go to Administer→Content management→Content types (admin/content/types), click the “manage fields” link for the Product Review content type (admin/content/node-type/review/fields), and create a new field using the settings indicated in .

Click the Save button to create the field, and you’ll be taken to the detailed settings page. Choose the settings indicated in , and click “Save field settings” to add the field. Because these are editorial reviews, it doesn’t make sense for users to be able to remove their vote, so we’re going to remove the ability to do so. We’ll also add this field to the Summary group so that it’s displayed along with the pros and cons.

When you return to the “Manage fields” tab (admin/content/node-type/review/fields), rearrange the new Rating field above the Pros and Cons inside the Summary group. After you click the Save button, the list should look like this:

Click the “edit” tab for the Product review content type (admin/content/node-type/review) and open the “Fivestar ratings” section of the page. Once you’ve checked “Enable Fivestar rating” for the content type, a preview of the rating widget based on the settings you’ve selected will appear on the page. Feel free to experiment with different settings: the Fivestar module will offer a preview that reflects your choices. Fill out the settings with the values in , as shown in . This setup will show the user’s own vote if available; otherwise, it shows the average vote across all users.

The indexing process used by Drupal’s Search module only works when the “cron” utility has been properly configured. cron is a utility used to run various commands at scheduled intervals on your web server. It is responsible for performing maintenance tasks on a Drupal site, such as clearing old log entries, as well as scheduling bulk email and other tasks that happen with regular frequency.

Each time cron runs, Drupal will catalog some of the site’s content; by default, it indexes 200 posts each time. If your site has a large number of posts already, the speed of the indexing will depend on how frequently cron is configured to run on your server.

If you’re not sure whether cron has been set up, or if you’re running on your local computer to test the site out, you can tell Drupal to perform its cron tasks by visiting Administer→Reports→Status report (admin/logs/status) and clicking the “run cron manually” link. For more information on setting up cron for your site, see http://drupal.org/cron.

Although our Product Reviews content type has all of its data in order, and our product listing pages are looking great, the individual reviews still look a bit untidy. Fortunately, we can use the CCK module’s display settings to tweak how each type of field is displayed in the reviews.

Go to Administer→Content management→Content types (admin/content/node-type), click the “edit” link, and then click the “Display fields” tab (admin/content/node-type/review/display). Fill out the fields using the settings in , which will help streamline the display of review information. Click the Save button when you are done.

Changing the CCK Display settings for our reviews cleans things up quite a bit, but the Summary information still seems awkward. In , we cover some of the basics of theming the HTML that Drupal outputs, but for now we can improve things quite a bit by adding some CSS rules using CSS Injector. We’ll use it to reduce the width of the Summary box and float it to the side of each review, turning it into a floating sidebar rather than a header at the top of each review. Here’s how:

There is a long list of modules to help us satisfy the requirements for this site. When looking for wiki solutions, the obvious place to start looking would be wiki modules. There are three modules with “wiki” in their names, Wiki (http://drupal.org/project/wiki), Liquid Wiki (http://drupal.org/project/liquid), and Wikitools (http://drupal.org/project/wikitools). Wiki was developed as a means to centralize the various wiki solutions in Drupal in a single package, but has been abandoned since 2006 and therefore is of no interest. Both Liquid Wiki and Wikitools are not “complete” wiki packages. They both group together some common needs in wikis, but rely on other modules for much functionality. Unfortunately, at the time of this writing, it appears that the Liquid Wiki module is also not being maintained, as there are no official releases and no development has occurred since February 2007. That leaves us with Wikitools as the only viable one in the group.

At the time of this book’s writing, the Wikitools module was under development and was not yet ready for production use. It adds some nice features, like automatically redirecting links if a wiki post path changes and protection against moving pages (regular users can’t retitle a wiki post, which would change the post’s path). These are nice but certainly not needed in our scenario. Check back for updates on the status of the module; as with all other tools in the Drupal world, things can evolve quickly if enough interest is focused on them.

However, we can build a wiki without any of those modules, which is what we’ll be doing in this chapter. There are many modules that will give us the functionality we need, just not under the banner of “a wiki module.” We can use all the tools that Drupal provides, not just the obvious or obviously named ones. Drupal core already has many “wiki” features built in, so we just need to provide a few extra touches to make our site like what people expect from a wiki.

The first thing to do is make sure that we have the content types that we need for our site. The student government needs pages that are only editable by the moderators, as well as the main content that everyone will edit. To easily distinguish between these use cases and to control access, we’ll have two content types: Page and Wiki page.

Drupal comes with two premade content types, Page and Story, as mentioned in , so Page content is already done for us. We don’t need the Story type, so instead of making a new content type for the wiki, we can edit the Story type to fit our needs.

Go to Administer→Content management→Content types (admin/content/types) and you will see the existing page and story types. Click the “edit” link for the Story type and make the changes listed in , as seen in . Click the “Save content type” button to make your new content type.

Because all of the content on the site will be group content, we don’t want to have the default “submitted by username” information to display (inevitably, it won’t be just that person’s work). To remove that information from our new Wiki page content type, we need to take a short trip over to the theme section:

The Pathauto settings page is quite large and can be intimidating. Luckily, most of the defaults are what most sites will want to use anyway, so that makes our job with configuration a lot simpler than it may first appear.

These settings will now take care of all new content that we create, but another thing that we want to account for is the content that we have already created. Currently, our new Help page that we created has a URL like

We want to keep track of all changes to all content, whether it’s on a Wiki or Page type. As mentioned previously, revisions are not created by default, but we can change that. The node publishing option defaults can be configured per content type. We already set this up for the Wiki page content type when we created it, but our Page content is not configured for this. Let’s go turn it on so we make sure we get every revision:

For the SGA site, we want all users to be able to keep track of what others have done and see these revisions. They also know that they are working with a relatively trusted group of users, so they want to allow anyone to undo changes if needed. A quick trip to “User management” will take care of that:

Let’s make some content changes and see how we can use the revisions:

Drupal core allows administrators to change the default publishing settings for each content type, ensuring that stories posted by contributors won’t immediately show up until an editor publishes them manually. However, the grunt work of checking for new unpublished posts, reviewing them, editing them, publishing them, and then saving the changes is cumbersome for sites with a lot of activity. We’ll be using a collection of useful modules to streamline that process and match the requirements.

We’ve now set up specific, reusable actions to reject and approve nodes. Thanks to the work we did earlier, whenever these actions are triggered, all the appropriate emails will be sent and content will be published as soon as it’s approved, based on the workflow and trigger rules we set up.

The Workflow module already provides a simple view listing all of the site’s content, and what state each piece of content is currently in. Now, we need to alter this view to take advantage of the Views Bulk Operations module.

Image handling in Drupal has long been a distributed effort between several cooperating (or competing) modules. The Image module (http://drupal.org/project/image) was the universal solution in Drupal 4.6 and 4.7, but with the advent of CCK, several new modules appeared that leveraged this new, more flexible system. Because the Drupal community’s development trends are headed toward websites built around CCK and Views, we’re going to build our site around this newer approach, building on the basic functionality of CCK and Views.

ImageField (http://drupal.org/project/imagefield) is a module that provides a reusable image upload field to CCK, which we’ll be able to use to upload our photos.

Despite its name, the ImageCache module (http://drupal.org/project/imagecache) does much more than simply cache images. It is often paired with ImageField, because although ImageField handles the upload and storage of images, it does not provide any way of creating thumbnails. ImageCache can not only create thumbnails, but also chain together several image manipulations such as crop, rotate, scale, desaturate, and sharpen to create completely customized displays of images.

The display of images in a gallery can be made from a few pages created by the Views module. Because ImageCache and ImageField provide Views integration, you’ll be able to select any desired images created with ImageField, and then ImageCache will scale those images down for display in the view.

After enabling the module, ImageField puts a new field on the fields form for setting up a new or existing content type. Like other CCK fields, an image field is added to a content type at Administer→Content management→Content types (admin/content/types). The form for configuring an image field is displayed in .

A few of the options on this form are common among all CCK fields, such as Label, Widget type, Required, and Number of values. These fields behave the same for an image field as they do for other fields, as described in the introduction to CCK in . The other options listed here are unique to ImageField:

The first thing that we’ll need for our photo gallery is a new content type for photos, called Photo. This new type will let users upload full-resolution photos through .

The main ImageCache administration panel at Administer→Site building→ImageCache (admin/build/imagecache), shown in , displays a list of the presets available on the site. An image preset starts as nothing but a name, describing the actions that are performed on this style of image. You can add, edit, or delete presets, as well as “flush” them. The Flush option lets you clear out all created images for a preset. Because images are generated on the fly, you can delete all the thumbnails on your site at any time and they’ll be re-created the first time they’re requested. You might try flushing the cache for a preset if images somehow become out of date with the original.

Let’s set up a few presets to scale down the images: the first one a “thumbnail” size that’s a small 120-pixel-wide square, and the second a “preview” size that maxes out the image for display on photo node pages (which maxes out the image widths at 480 pixels to prevent our layout from breaking):

There are contributed modules available that add integration between Drupal and other forum systems, such as phpBB, but Drupal itself comes with its own simple forum using the built-in Forum module. The Forum module uses regular Drupal core concepts such as taxonomy (for forum containers and forums themselves), nodes (for posts inside a forum), and comments (for replies), which makes it integrate seamlessly with the rest of the website, including Drupal’s translation features.

Another core Drupal module, the Book module, provides the ability for multiple users to collaborate together in order to create a collection of documentation. Book pages are structured into one or more hierarchies, with previous, next, and up links generated automatically on each page. Each page also provides a “printer-friendly version,” which will create an unformatted page consisting of the content of the current page and any subpages for easy printing or downloading for offline reading.

User interface is the text that is provided by Drupal, both in core and contributed modules. This includes things like form labels, help text, and navigation. Drupal core’s Locale module provides the framework that allows user interface translations. To get the bulk of our localization, we will download translation projects that will supply us with translations of the core user interface. As we add contributed modules, we’ll need to check whether they supply a module-specific translation. If not, we are not out of luck, because core also gives us the framework to add and update translations as needed within our site. The “Localization client” module uses this framework to add a nice, user-friendly frontend to make translating interface text a breeze.

Locale does not cover every single aspect of user interface text though, so we will be using the excellent Internationalization (i18n) module to fill in the gaps. The Internationalization module provides us the tools to translate taxonomy, blocks, and certain site variables like the site name and mission statement. In addition to providing extra translation, it also helps us manage our multilingual content.

Locale handles the translation files and language switching options on the site. Let’s break it down and look at what that means.

As discussed earlier in the “Language switching” section, we have several options to choose from. We don’t want our users to have to manually switch their language in the account settings (the None option), and our client does not have separate domain names for each language (the “Domain name only” option). That leaves us with the two “Path prefix” choices. We are going to use the “Path prefix with language” fallback rather than the “Path prefix only” option, because our client wants to make sure that if a registered user has chosen a language in her account settings, she gets returned to that rather than the site default, should the prefix method not return a usable result:

The Locale module provides a block to switch languages, which can be configured just like any other block to have a different (or no) title, and have various display options set.

Interface translation depends on the Locale module, which should already be enabled on your site once you have installed a translation.

Earlier, we enabled translation for our pages, so let’s walk through the translation process itself:

Translated content is all shown by default. The main Internationalization module will let you display only content that is relevant to the language currently in use:

If you go to the front page of the site, you will see that we now only get one “Welcome” post and one “Knowledge Base” menu item. If we choose Nederlands from the Language switcher block, you will see that the Dutch “Welkom” post appears, and the menu items change to the Dutch versions.

Now the content we see is more streamlined, as shown in . Let’s move on to translating other items in the site that are being stubborn, such as the site name, Migratory Patterns.

Before we can translate the various site-wide variables, we need to let Drupal know which ones we want to make translatable. To do this, we’ll need to edit the settings.php file:

The book club has two main options for managing event data in Drupal. The options are indicative of a common trend amongst Drupal’s contributed modules. Specifically, there is a long-standing module in the Drupal community simply called Event (http://drupal.org/project/event), which natively handles most of the required features. The other option, and the one we will be using in this chapter, is a combination of CCK and Views add-ons: the Date module (http://drupal.org/project/date) and the Calendar module (http://drupal.org/project/calendar), respectively. The main differences are as follows:

Both options are capable of meeting all the requirements for the book club’s site. In fact, when compared side by side, they look functionally equivalent: both options allow us to create new events, view a list of upcoming events, and offer rich, full-featured calendar displays. In fact, by working with any content type, the Event module still allows us to use CCK to build custom content types for our event data (for example, for holding additional information about events). This significantly blurs the line between the solutions, particularly compared to the choice between the Image module and Imagefield, as discussed in . With the Image module, a specific content type (“image”) is defined, whereas with Event you can reuse any custom content type. Furthermore, Event is a single module without any dependencies, whereas Date and Calendar require CCK and Views respectively. So why not use the Event module?

We’ll start by creating a new, basic content type just for events. We just need the event name and description along with an easy way to add the event location:

As its name would imply, the Date API module merely provides a set of library functions for date handling. These functions consist of things like converting between date formats, providing integration with modules such as Views, and even generating date input select boxes. Though covering the full extent of the API is outside the scope of this chapter, it is worth noting that the Date API module does not depend on CCK, but is required by both the Date and Calendar modules. In theory, any module in Drupal that performs any sort of date handling or manipulation could take advantage of this .

Drupal core, by default, does all time zone handling based on an offset from Greenwich Mean Time (GMT), represented as the number of hours’ difference (plus or minus) from GMT. For example, the offset −0400 is used for Eastern Daylight Time in the United States. This approach has several drawbacks, the most significant of which is in trying to account for Daylight Saving Time, as the offset will change. When the local time changes to Eastern Standard Time, the actual offset from GMT changes from −0400 to −0500, and the setting must be updated again.

With all our required modules enabled and set up, we can now customize the Event content type we created earlier by adding dates. Note that as we do this, we will only add a single CCK field to handle both the event’s start and end times:

The Calendar module provides a new view type that shows the results of a view in a calendar rather than a list or table as with the default view types. This view type is one of the more complicated ones available. It provides full day, week, month, and year views of the event data on our site with lots of links between views and paging through days, months, and years. To achieve this rich functionality, Calendar requires certain views arguments to exist, and to be ordered and configured in a certain way.

The Calendar view type then determines which view the user would like to see based on the arguments that exist. For example, if our view URL is calendar, the Calendar view will handle the paths described in .

Sweet Tees has several options to manage their online store; however, they really want to provide a seamless, user-friendly experience for their customers. They are looking for a solution that is simple and elegant, yet also comprehensive.

For Drupal, there are two primary e-commerce solutions, both of which consist of several modules, to implement the various features required.

The e-Commerce module (http://drupal.org/project/ecommerce) is the oldest and more flexible of the options. The package is designed to be a highly modular framework for building e-commerce solutions in Drupal. In a way, it is a development framework of its own on top of Drupal’s existing framework. The principal benefit of the e-Commerce package is ultimate control and extensibility. Because of the high number of variable components in an online store (payment processor, shipping calculations, taxes, and so on), this flexibility is incredibly useful. The downside, however, is that the flexibility increases the level of complexity, thus making it more time-consuming to set up and configure. Also, again due to its architecture, the checkout process for the e-Commerce package takes several pages and requires that customers register accounts on the website. This violates two of the client’s primary requirements.

The Ubercart—core package represents the base framework components for our online store. There are five modules in this section: Cart, Conditional Actions, Order, Product, and Store. Each of these modules is required for running an online store. Following is a brief description of each:

Go to Administer→Site building→Modules (admin/build/modules) and enable the following modules:

After enabling these modules, we can see that our store administration section has changed dramatically. Going to Administer→Store administration (admin/store) now shows messages in the “Status messages” list and two new sections, Products and Attributes, as seen in .

When we enabled the modules in the previous step, Ubercart automatically added a Product content type and associated it with an Image field so that we can attach pictures to our products. However, Sweet Tees sells two kinds of products: T-shirts and stickers. In order to accomplish this requirement, we’ll create two product classes, as shown in .

In this section, we will configure the site’s shopping cart, as pictured in . Once we get the cart set up, we will be able to browse to an individual T-shirt page, select options such as color and quantity, and add the customized products to our cart.

The vast majority of our work for this section is completed by simply enabling the Cart module. The cart settings come with very workable defaults, but there are a couple settings we want to change:

The first step in customizing a theme is to make a copy of it and place it into the appropriate location in the sites directory. Think of the sites directory as “the stuff that makes your site yours.” All of your customizations, installed modules, and themes should go into this directory. For most sites, this will mean placing themes into sites/all/themes. Drupal will discover themes within subdirectories, so feel free to organize this however you like.

Now let’s look at customizing the page.tpl.php file. This is the file that defines the general HTML structure of the entire page. The theme engine and enabled modules make a number of variables available to this file, and then these variables are simply output using PHP print statements. Let’s change the structure of our theme by moving the breadcrumb output up into the header region of the page. We want our breadcrumbs to look like those shown in .

Those little bits of dynamic content that you are using in your template files are really handy—until they annoy you by not quite producing exactly the output that you want. The variables that Drupal creates by default, like $site_name and $submitted, are meant to be a baseline that will fit a lot of people’s needs. Like everything else in the theme system, though, you have the power to crack them open and change them. Not only can you override existing variables, but you can also create your own brand-new .

All variables that go out to a template file are first passed through a special kind of function, called a preprocess function. You can add your own preprocess function to your template.php file and get the last shot at the variables before they head out to the template. To keep things tidy, you can use one preprocess function per template; for example, you can create a mytheme_preprocess_page function to affect variables to be used in your page.tpl.php file. With this function, you can define, or redefine, any variable. For instance, if you wanted to make a new variable that printed out a random number between 1 and 100, you could add this to template.php:

function mytheme_preprocess_page(&$vars) {

  $vars['random_number'] = rand(1, 100);

}

Then (after clearing the Drupal cache), you can print out that variable out in your page.tpl.php file just like any other variable:

<?php print $random_number; ?>

Drupal gives us lots of nice variables to use, but they don’t always look the way we prefer. A common item that many people wish they could change is the “Submitted by...” line, which prints out the author name and date that a node was created. You can turn this display off and on in the theme configuration screen at Administer→Site building→Themes (admin/build/themes), under the Configure tab (admin/build/themes/settings), but you can’t change what information is actually printed out when the display is on. We’re going to change this line to instead print out “Posted on” followed by the date, as shown in .

One important piece that we need in order to modify this is a template.php file. As our Newmarine theme doesn’t have a template.php file in it yet, we’ll create that as well to accomplish our task:

It’s important to have a few things ready prior to installing Drupal. A full list of requirements is available at http://drupal.org/requirements. Use the following as a basic checklist prior to installing Drupal:

When discussing updates, it helps to have some background information about Drupal’s version numbering system. For all the gory details, see http://drupal.org/handbook/version-info, summarized in .

Each “major” release of Drupal core gets a new number: Drupal 5, Drupal 6, Drupal 7, and so on. A new major Drupal version is released every 12–18 months, and consists of new features, improved usability, and more flexible APIs. Throughout a major version of Drupal’s release cycle, several “minor” versions of Drupal are also released, such as 6.0, 6.1, and 6.2. Minor Drupal versions fix critical security problems and important bugs as well.

Releases of projects like contributed modules, themes, and translations have a version naming scheme such as 6.x-1.3. The “6.x” indicates the major version of Drupal that it is intended to work with; in this case, Drupal 6. The “1” indicates the “major” release of the contributed module. And the “3” indicates that this is the third bug fix release of this major release of the module.

Some releases also have “extra” version information, such as “-beta4” or “-rc2.” These indicate that the modules are still in development, but available for testing.

Updates between minor versions of Drupal core and modules, such as between Drupal 6.3 to 6.4, or Views module 6.x-2.0 to 6.x-2.1, are normally fairly painless, as long as your site is kept up-to-date. Updates between major versions, however, such as Drupal 6.3 to 7.0, or Organic Groups module 6.x-1.0 to 6.x-2.0, and especially to 7.x-1.0, will need special care, as the changes are generally quite extensive.

The module listing pages at http://drupal.org/project/Modules, pictured in , list modules by category (such as CCK or mail-related modules), by name alphabetically, and by the date they were last updated. Browsing these category-based pages can be useful for determining the modules that exist in a particular space, and keeping an eye on the modules that are frequently at the top of the date list helps highlight those with active maintainers.

Drupal.org also provides a block for searching the downloads on the site, also pictured in . For example, searching for “wiki” brings up a list of modules with that keyword in their name or description. This allows you to drill down to modules specific to your needs faster than browsing by the default category view.

The Drupal.org support forums at http://drupal.org/forum, particularly the “Before you start” forum at http://drupal.org/forum/20, can provide a wealth of information in the form of questions from other users about the modules they used for their own projects. Often, you can receive some helpful advice not only about the feature you’re trying to implement now, but also for future things your website will need to take into consideration. The “Drupal showcase” forum at

Modules, themes, translations, and even Drupal core itself are all referred to as projects on Drupal.org. Each project has its own page at http://drupal.org/project/file_name, which contains a wealth of information that can be used to evaluate a module’s health.

shows the first part of a module’s project page. Here you can find the name of the module’s maintainer (usually the original author and/or the module’s primary developer), the date the project was first created, a description of what the module does, and sometimes a screenshot showing what the module does.

The original project creation date can be useful when looking for time-tested solutions (if the module was created in the past week, it’s probably best to let it mature a bit before depending on it). But also be aware that some older modules may be legacy solutions that more modern modules deprecate.

The first is the “Developers” link at the bottom of project pages (for example, http://drupal.org/project/developers/3060), which takes you to a table, shown in , displaying a list of the individual developers who are maintaining (or have maintained) the project. The data shown here are the commits, or code changes to a project, by everyone who has ever had access.

From this information, you can get a general idea of who within the project has been working on it the longest, how active each contributor is, and how much experience each has with a given project’s code. A sign of a good, healthy project is lots of recent commit activity, along with numerous contributors in the list if some of the original folks are no longer around. If this list is small, and the last commit was several months ago, particularly if the project’s issue queue shows warning signs, it may be worth looking for alternative solutions, or perhaps offering the maintainer payment for the changes you need, in order to help entice her interest again.