The Implementation Notes section of each chapter will discuss, compare, and contrast various options for fulfilling the client’s needs in Drupal, and explain how we decided on the specific solutions chosen for each chapter.

All of the functionality required by Mom and Pop, Inc., is provided by the bundle of features that comes as part of the main Drupal software download, called “Drupal core” or just “Drupal.” Drupal’s Node module has the built-in ability to create various types of content on the site, including static pages, which work great for the Home and About pages. We’ll use the core Path module to give these pages nice and descriptive URLs such as http://www.example.com/about.

Drupal also provides a robust roles and permissions system, which we can use to separate Goldie’s tasks (website maintenance) from Mike and Jeanne’s tasks (managing the daily website content) and from the customers on the site (who can do only things such as leave comments). There are also administrative tools, such as the Dashboard and Shortcut modules, that can help Goldie provide a specifically tailored administrative interface for Mike and Jeanne.

Drupal also comes with a module called Contact, which can be used to build a simple contact form for any website. Different categories may be set up, and each one can optionally send mail to a different email address. This feature is useful for sites with different support personnel in different departments, for example.

And finally, the announcements section, as we will see, can be handled using just the default Article content type that ships with Drupal.

As discussed in Chapter 1, 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: “Basic page,” intended for static content such as an About Us page, and “Article,” intended for time-sensitive content such as press releases. But, like most things in Drupal, content types are fully configurable. Figure 2-5 shows the “Create content” page on a typical Drupal site with several content types available. This page is found under “Add content” (node/add) in either the Navigation block or the default Shortcut menu.

Figure 2-5. A list of available content types

Figure 2-6 shows an example of a typical node form, which is used to add or edit a piece of content. Each node has a Title field, which identifies the node in content listings and controls the title of the web page when viewed, and most nodes also have a Body field, which holds its primary content. Additional fields of varying types—for example, text, numeric, or file upload fields—may also be added to a basic node form for more granular data entry. The next chapter covers extending the fields on the node form in depth.

At the bottom of the node form fields is a set of more advanced options, enclosed in a set of vertical tabs. These tabs display the current value of each setting, and you can click them to make adjustments. 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 most other settings, so the tabs simply do not show up on the form for these users.

Figure 2-6. A typical node form in Drupal

The Body field on a node can optionally provide a summary, which is a short blurb that entices people to read further. Summaries are displayed in most content listings, in RSS feeds, and in other places. When a summary is provided, the text in the Body field is displayed only when a user is looking at a piece of content directly.

Nodes can have a variety of options applied to them, including the ability to track and revert revisions, the ability to turn on commenting on the content type, and the ability to default to Unpublished so new nodes are not immediately visible on the site. You may set these options on a per-node basis, or specify the defaults for all nodes of this type in the administration section for content types at Structure→“Content types” (admin/structure/types) in the administrative toolbar and pictured in Figure 2-7.

Figure 2-7. The content type administration form

Nodes that have the “Promoted to front page” publishing option checked appear on the default front page listing, available via the path http://www.example.com/node, as pictured in Figure 2-8. Nodes are displayed one after another, with “Sticky at top of lists” nodes on top, and the rest of the list ordered chronologically starting with the most recent.

Figure 2-8. The default front page view

You can make changes to content workflow once it’s created on the node itself, by editing it directly, or in bulk by going to the administrative toolbar and clicking the Content (admin/content) link, pictured in Figure 2-9. Here, content may be deleted, published, or unpublished, or have various workflow options set.

Figure 2-9. The Content administration page

The core Comment module allows website visitors to post replies to the content within a node, enabling them to discuss the topic at hand directly with the author as well as with one another. Figure 2-10 shows commenting in action.

Figure 2-10. The Comment module allows visitors to discuss a piece of content

Most content types have comments enabled by default, although the “Basic page” type has commenting turned off initially (as it doesn’t make much sense for visitors to discuss your About Us page). You may configure additional comment settings per content type from the administrative toolbar at Structure→“Content types” (admin/structure/types). These settings include specifying whether to require previewing of comments before posting them, as well as the number of comments to display on the page. We’ll cover a few of these settings later in the chapter.

Comments may also optionally be placed in a moderation queue rather than being immediately visible on the site, which can be useful as a basic spam deterrent. Comment administration facilities are available as a subtab on the main Content screen at Content→Comments, as shown in Figure 2-11.

Figure 2-11. The Comment moderation queue administration page

Hand-in-hand with creating content is the ability to navigate to it on the site. Drupal provides a built-in module called Menu for this purpose. Menus hold the navigation links to various web pages on a Drupal site. Drupal comes with four default menus, and you can also add your own:

Figure 2-12 shows an example of all four menus in the default core Bartik theme. Themes will be discussed in more detail later in the section Spotlight: Themes.

Figure 2-12. Drupal’s built-in menus: Management, User, Main, and Navigation

Blocks are smaller chunks of content that you can place in your pages. Examples of some default blocks provided are “Who’s online,” which shows a listing of users currently logged in; “User login,” which displays a login form to anonymous users; and “Recent comments,” which shows a list of the newest comments on the site. The Navigation bar in the sidebar, the “Powered by Drupal” text at the bottom, and even the entire content area of the page are blocks! You can also make your own custom blocks: for example, you might create a block to display an announcement about an upcoming event.

Figure 2-13 shows the Block administration page under Structure→Blocks (admin/structure/block). Blocks are placed within a region of a page. Examples of regions are “Sidebar first,” “Footer,” and “Content.” Region names, and exactly where they appear on a page, vary depending on the theme (or design) of your site; some themes may define additional regions such as “Banner ad” and remove or change some of the default regions. Therefore, blocks must be configured on a per-theme basis. We’ll discuss more about themes and regions later in Spotlight: Themes. You may use the arrow handles on the side to drag blocks to different regions. To see a visual representation of what the regions look like, as pictured in Figure 2-14, click the “Demonstrate block regions” link.

Figure 2-13. The Block administration page for the Seven administration theme

Figure 2-14. Block regions for the Bartik theme indicate visually where blocks will be displayed

You can customize the visibility of blocks, as well—for example, to show blocks on only certain pages or only to users with certain roles. If the core PHP filter module is enabled, you may also optionally use PHP to specify complex visibility settings—for example, to display a Help block to any users who have been members for less than a week. There is also an option to let users control the visibility of certain blocks themselves, so they have more control over their browsing experience.

First, we’ll make a simple About Us page to get the hang of Drupal’s content creation and editing tools.

Congratulations! You’ve just created your first of many nodes in Drupal!

Next, let’s experiment with creating an Article—Drupal’s other default content type. Unlike “Basic page,” which contains just a Title and Body field, Articles can also provide Tags (or keywords) and an Image on each post. Articles also have comments enabled, and automatically get posted to Drupal’s default home page in reverse-chronological order, making them useful for things like announcements. So, let’s announce the creation of our new website!

Great! We now have some simple content on the site, and our Navigation menu is starting to come together. However, there’s something a little funny going on: our tabs in the top-left corner are displayed in alphabetical order, which puts About Us before Home. It would make a lot more sense for Home to come first, so let’s fix that by reordering the items listed in the menu:

Figure 2-20. The menu administration screen allows you to reorder menu links

Now, if we close out of the Overlay and return back to our site’s frontend, our menu should have Home listed first. That’s more like it!

Next, let’s start to play around a bit with blocks on the site. Mike and Jeanne don’t know what Drupal is, which is going to result in all sorts of awkward questions about that “Powered by Drupal” block in the footer. So let’s remove it. Additionally, they want to be able to show off the latest weekly deal prominently on the home page, which is the perfect use for a custom block.

Figure 2-23. “Weekly deals” block added; “Powered by Drupal” block removed

The Module administration page, available in the administrative toolbar under Modules (admin/modules) and depicted in Figure 2-24, is where Drupal provides the ability to turn on and off your website’s functionality. Related modules are grouped together within fieldsets called packages, 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 you’re troubleshooting problems. Finally, many modules also have links to their help pages, permissions, and configuration pages. This is very handy for getting to the meat of what a module does as soon as you turn it on.

Figure 2-24. The Module administration page

You may switch modules 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. Some contributed modules may also require certain versions of other modules in order to be enabled.

One final handy page to be aware of is the administrative Index page at admin/index, shown in Figure 2-25. This has a full list of administrative pages grouped by the module to which they belong.

Figure 2-25. Viewing administrative tasks by module in the admin index

Although core modules can provide the basics for your site, and can in some cases get you pretty far, the real power in Drupal comes from its vast array of community-contributed modules. You can browse and download all contributed modules from http://drupal.org/project/Modules, pictured in Figure 2-26.

Figure 2-26. The contributed modules browsing page at Drupal.org

Each module has its own project page on Drupal.org, as indicated in Figure 2-27. Here you’ll find a description and often a screenshot of the project, as well as information about its developers, what sort of bugs or features the project has, documentation links, and more. The main feature on this page is a table containing releases of the module that you may download. The version of the module you should download is the one in the Recommended Releases table in green, and whose version starts with “7.x-” (unless you’re using Drupal 6, in which case you’d look for the release that starts with “6.x-”, and so on). Visit http://drupal.org/documentation/version-info for much more information on Drupal’s version naming conventions.

Figure 2-27. The project page for the Login Destination module

Once you’ve found your module, you need to get it into your Drupal site. There are two ways to do this in Drupal 7:

Detailed instructions on how to install modules are available in the online Installation Guide documentation at http://drupal.org/documentation/install/modules-themes.

If you decide that you no longer want to use a module, you have two choices:

Controlling user access consists of three parts: (optionally) creating one or more roles to match the types of visitors your website needs to support, assigning permissions to those roles, and associating user accounts with those roles.

Under People→Permissions→Roles (admin/people/permissions/roles), pictured in Figure 2-33, you may create, edit, or remove roles, as well as reorder them with the drag-and-drop handles in order of escalated privileges. At this stage, there’s nothing more to a role than a name. Individual users may be assigned to roles either via their user edit page or from the administration page at People (admin/people). Both creating and assigning roles requires the “Administer permissions” permission, which is separate from the “Administer users” permission that gives access to the main People administration page.

Figure 2-33. The Roles administration page

At People→Permissions (admin/people/permissions), individual permissions may be assigned to roles, as shown in Figure 2-34. Access to this screen is controlled by the “Administer permissions” permission, so different users can take care of day-to-day user-related administrative tasks without requiring an escalation of their privileges in the system.

Often, permissions will have descriptions underneath them to provide more information about what they do. Additionally, modules that can impact website security will be labeled with “Warning: Give to trusted roles only; this permission has security implications.” This means that this permission should only be given to an administrator-level user, unless the full ramifications for that permission are fully understood.

Figure 2-34. The Permissions administration page

Each user has a special page in Drupal called the user profile. This is the page that you see when clicking the “My account” link after you have logged in. Other users might visit your user profile page by clicking your name next to a blog entry or comment you have authored on the site. By default, the user profile page lists some simple information about the account, such as the username and the length of time that the user has been registered on the site. However, additional fields may be added to a user profile and contributed modules may provide more information here, as shown in Figure 2-35. Users may change basic settings in their user profile, such as their password and their time zone, and other modules can add extra features here as well, such as a language selection or a field to upload a picture to be displayed alongside the user’s posts.

Figure 2-35. A user profile page on Drupal.org, with additional information provided by add-on modules

Under Configuration→People→“Account settings” (admin/config/people/accounts), there are many customizable user options, including:

A community site of any reasonable size and popularity may eventually attract visitors with less-than-honorable intentions.

Administrators with the “Administer users” permission may change a user’s status to Blocked, which will prevent him from logging in. The blocked user then has only the rights of an anonymous user. User accounts may also be canceled, and you’ll be presented with a variety of options about how to handle the accounts and what to do with their content.

For more automated blocking, Drupal also provides the ability to block IP addresses, available at Configuration→People→“IP address blocking” (admin/config/people/ip-blocking), to help keep out repeat trolls, spammers, and the like. If you have the ability to block nefarious users from a firewall or web server level, however, that’s a much more scalable approach and keeps them out of other web applications you might have on the same server.

We talk more about people with nefarious intent in Spotlight: Content Moderation Tools.

Mollom is a service started by Benjamin Schrauwen and Dries Buytaert, creator and project lead of Drupal. It automatically scans the content of your site comments (as well as nodes, the contact form, and multiple other places where user-generated content comes in) and, based on its analysis of millions of other blogs’ content, prevents obvious spam from even being posted to the website. Your website benefits from the collective intelligence of every other website that has a Mollom plug-in installed, and Mollom is compatible with many different content management systems and programming languages.

Mollom attempts to overcome shortcomings of traditional spam-trapping tools in the following ways:

Figure 2-38. Example spam reporting from the Mollom module

Mollom’s goal is to eliminate the need to do any manual intervention of content moderation, by passing the “gray area” validation to the posters themselves via the conditional CAPTCHA. And, unlike the CAPTCHA provided by most websites, users are only confronted by the scrambled character challenge if their post is “borderline”—not for every single form submission, unlike other solutions such as the CAPTCHA module.

The Mollom module is available from http://drupal.org/project/mollom, and you can obtain an API key by creating an account on http://mollom.com.

If you prefer to use other automated antispam tools such as Akismet or Defensio, another option is the AntiSpam module. While the AntiSpam module is not as popular in the Drupal world as Mollom, its ability to evaluate multiple external services to see which provides the best protection is a nice feature.

Automated tools are perfect for blocking obvious spam and robots, but what do you do to prevent trolls on your site from posting pornography or other offensive content? Some websites prefer a more hands-on approach, particularly if there are legal ramifications to offensive content appearing on the website even for a second.

Drupal core includes some basic content moderation tools, such as the ability to set any content type as “unpublished” by default (hiding it entirely from everyone but the original author and administrators), and revision control so that further edits can be “rolled back” to a version that was approved. But many Drupal sites set up their own custom moderation screens with tools like the Views and Flag modules, as well as the Revisioning module, a simple utility module that ensures that the approved version of a node stays published when subsequent edits are made.

Most sites won’t be satisfied with the meager selection of themes that comes with Drupal core. Luckily, 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, as pictured in Figure 2-41.

Figure 2-41. Drupal.org’s themes listing, filtered by 7.x-compatible themes

The quality of the themes in the Drupal.org 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.

Several companies, such as Top Notch Themes, offer premium, paid themes. These themes tend to be higher quality, are 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, as we saw in Hands-On: Working with Modules. You can either click the “Install new theme” link at the top of the Appearance page and walk through the installation wizard, or download the theme’s .zip or .tar.gz file from its Drupal.org project page and extract it into the sites/all/themes directory. Your new theme should appear on the Appearance (admin/appearance) administration page in your Drupal installation, as shown in Figure 2-42.

Themes can be enabled and disabled from the Appearance page (admin/appearance) in the administrative toolbar, shown in Figure 2-42.

Figure 2-42. The Appearance administration page

The Appearance page is divided into Enabled and Disabled themes. Enabled themes are exposed as options in interfaces such as the Block administration page, and other contributed modules can use enabled themes to make different parts of the site look unique. The theme marked “Default theme” (in this case, Bartik) is the one displayed on the frontend of the site. To set a different theme (such as Stark) as the frontend theme, click “Enable and set default” or “Set default,” as appropriate.

Drupal offers a number of configuration features that themes can take advantage of. There are two ways to configure themes. For global options (ones that you want to apply across all themes), select the Settings tab at Appearance (admin/appearance/settings). For settings specific to a single theme, or to configure settings that are only offered on a per-theme basis, select the Settings link next to any enabled theme (admin/appearance/settings/<theme_name>). The settings shown on this form will vary from theme to theme.

On these settings pages, you can toggle the display of many page elements, including the site logo, site name, site slogan, user pictures, and others, as shown in Figure 2-43. Sometimes, one or more of these checkboxes may be disabled by settings elsewhere in your installation. For example, if the Comment module is turned off, Drupal no longer lets you toggle the “User pictures in comments” and “User verification status in comments” settings.

Figure 2-43. The theme configuration page allows customization of which page elements are displayed

The theme configuration page also allows administrators to upload their own site logo image and shortcut icon (also known as the favicon or bookmark icon, which appears in the browser’s address bar) or simply point to one elsewhere on their server. Note that in order to see these settings, you must first uncheck “Use the default.”

Some themes, such as the core Bartik and Garland themes, also take advantage of the Color module, which allows administrators to configure a theme’s color scheme using a handy JavaScript-based color picker. Figure 2-44 shows the Color module in action.

Figure 2-44. The Color module, supported in some themes, offers customization of the site’s colors

It’s important to remember that block regions are defined by the theme, and different themes may offer different regions. If you have blocks assigned to a region in one theme and you switch to another theme that does not offer a region with the same name, these blocks could disappear from your site. After enabling a new theme, visit the Block administration page at Structure→Blocks (admin/structure/block) and see what regions are available in your theme. You may need to reassign blocks to another region to take full advantage of the new theme.

By default, Drupal ships with the Seven theme—which sports a neutral, no-nonsense design—for use on administrative pages. This is to help you understand when you’re viewing the public frontend that your users will see and when you are in a backend, administrative context. It’s also possible to use a different theme as the administrative theme, or even to use the same theme for both the front- and backends of the site. You can choose an administrative theme at the bottom of the Appearance (admin/appearance) page. This theme will be used for all administration pages (those starting with “admin” in the URL path and also maintenance pages such as update.php), and optionally for content creation and editing pages as well. Figure 2-45 shows the Administration theme settings page.

Figure 2-45. The Administration theme settings page