Drupal 6 Modules for Every Website

When you begin creating a new website based upon Drupal, at the beginning of the project, you must decide what version of Drupal you will use. This is not as simple as merely choosing the latest stable version, because there is no guarantee that there will be equally stable versions of all the contributed ("contrib") modules that your project will need. Also, there may be no budget for custom-developed modules, to overcome the unavailability of stable versions of one or more contrib modules.

Once the Drupal version has been decided upon, you must choose an installation profile, which is a single download comprising Drupal core, plus (typically) one or more contrib modules and/or themes, all fully configured to work immediately upon installation. This may sound like a concept only of interest to more advanced developers, but if you have downloaded and installed regular Drupal, then you have (perhaps unknowingly) worked with an installation profile. That default version of Drupal is the "default" installation profile, and its name is reflected in subdirectories of the "profiles" and "sites" directories in the Drupal installation root directory.

In choosing an installation profile, your options include the simplest (the default profile, noted above), more substantial generic profiles (such as Acquia Drupal), and specialized profiles oftentimes specific to industries or human languages (such as those listed on the Drupal installation profiles pages). Unfortunately, many of the non-default profiles are too large and resource-intensive for the average project.

This article details the Drupal 6 base installation that has evolved from my own development experience — focusing on the core and contrib modules that I have found valuable for almost every project. This article does not cover the configuration settings, so the final result would not be considered a formal installation profile or a distribution. However, using this base installation as a standard setup saves time, even if the specific project requires one or more of the contrib modules or settings to be altered later. It is certainly faster than starting with the default profile, and it invariably streamlines the site-building process.

Before discussing the 40+ modules in question, the choice of Drupal 6 should be explained: As of this writing, Drupal 7 admittedly is the future, and should be sufficient for simple sites. But I'm still finding that most of my new client sites necessitate the use of Drupal 6, usually because some key contrib module is not yet stable or even available for Drupal 7. Based upon what I am hearing in the Drupal IRC channels and podcasts, it seems most Drupal developers are in the same boat. So this article will focus on Drupal 6; however, I will present a Drupal 7 base installation in the future.

At the Core

If you wish to follow along and create a base installation as described here, begin by downloading and installing the latest version of Drupal 6, which at this time is 6.22. This article assumes that you are already familiar with how to install Drupal in a local or remote development environment. It also assume that you are comfortable with an admin page being specified using its path, rather than the sequence of menu items one can follow to arrive at that page, e.g., "admin/build/block" instead of Site building > Blocks.

Most of the core Drupal modules are essential, but there are some optional ones that I rarely use, and thus can be disabled (and even deleted from the "modules" directory in the installation root). If it later turns out that there is a need for one of them, you can always re-enable it. These operations are naturally performed on the modules administration page (admin/build/modules).

The Color module is used by those themes that allow the user to modify her color scheme. But most projects call for a fixed design — oftentimes created by a web designer or the client, who does not want any users ruining that design by changing the colors to whatever they want. Modifiable color schemes seem helpful only for trying to make a Garland site look less Garland (usually unsuccessfully). For instance, the default color scheme is the (in)famous "Drupal blue".

There are 15 alternatives. Switching from Blue Lagoon to Greenbeam provides some different colors, but not a different design.

The Comment module allows users to add their comments to published content (usually nodes of the Story content type). Such comments are a critical part of blogs and other social media sites, but I have yet to encounter a business owner who wants visitors to her site to be able to add comments, thereby modifying the content of the site (i.e., what it says of the business), and requiring the constant weeding out of spam comments.

In my base installation, I disable both of the above modules, and enable the following four:

The Path module is essential for creating descriptive URLs, e.g., ?q=content/new-story instead of ?q=node/123. These URLs are friendly to all site visitors, particularly search engines looking for keywords.

The PHP filter module allows you, or anyone else with permissions, to include PHP code in any node text field. Even though creating a custom module is generally safer and recommended, there always seem to be cases where it is more straightforward to embed node-specific code within the node itself.

The Search module allows visitors to the site to do exactly that. Few if any clients you will encounter will elect to not have basic search functionality on their sites.

Almost every site owner wants visitors to be able to send her a message, but without revealing the owner's email address. The Contact module makes that possible.

Content Creation

I now turn my attention to contrib modules, which, compared to the core modules, offer a much wider range of functionality, and are far greater in number ("quantity not quality", some detractors may add, when wading through the thousands of unstable and unsupported modules).

Even though a visitor to your site may not know whether a particular page shows the contents of a single node, or a list of nodes, or other information pulled from the database, she will be aware that the content forms the heart of any website built on a CMS, including Drupal. By default, content types in Drupal cannot be modified by adding fields to native or even custom content types. Fortunately, the Content module (a.k.a. Content Construction Kit, and CCK) allows one to add new fields of many possible data types — some as CCK submodules, but most as standalone modules. The former group includes some essentials: Text (fields and textareas), Number (integer, decimal, and floating point), and Option Widgets (selection, checkbox, and radio button widgets for text and numeric fields). Date, Email Field, FileField, Imagefield, and Phone Number are standalone modules that are usually needed for any substantial website. CCK is so critical to site building that most of it has been folded into Drupal 7's Field API.

While the Imagefield module allows for attaching images to nodes, the ImageCache and ImageCache UI modules (and the two ImageAPI modules they depend upon) are terrific for projects where the client will be uploading images to the website, and it would be best if the images were automatically resized if needed, or otherwise processed.

When anyone is adding content to your site, it is often the case that not just one node needs to be created, but several of the same type. By default, this requires you to click the "Create content" link, and then the name of the content type, every single time, for every new node. The Add another module solves this problem by including that second link in the status message at the top of the screen that informs you that the previous node was successfully created.

Earlier I mentioned the PHP filter module, which is needed for adding PHP code within a node's text field. If you find that you are creating a lot of such nodes, you can make the PHP text format the default for anyone with an admin role, using the Better Formats module. Settings only affect new nodes, and not any existing nodes.

Content Display

The Views and Views UI modules are so useful in building websites that they may be the top candidates for future inclusion into Drupal core, at least in the opinion of their legion of fans. Together these two allow one to query the Drupal database and present the results as pages, blocks, RSS feeds, and other display types — all without having to write and debug a single line of MySQL code. In the figure below, you see the settings for a custom view that displays the title and post date of all published Story nodes, sorted by the post date in descending order, with a pager that lists 10 records per screen.

Menus for Visitors

In Drupal, paths to pages are strongly related to menus, since it is the menu system that interprets the path portion of the URL request, and decides what page to display. There are some modules that offer terrific capabilities for site navigation. Begin by installing the Global Redirect module (which depends upon the aforementioned Path module). It checks the current URL for an associated alias, and if it is not being used, will do a permanent redirect (301) to the proper path.

When you are creating a new node, and you want an existing menu item to point to it, you can avoid the frustration of having to remember or write down the menu path, by using the Menu path autocomplete module, which changes the input field for the menu path to an autocomplete text field.

By default, Drupal displays nested menus in a hierarchy, with each submenu displayed indented underneath its parent menu item. Just to see a submenu, the user must click its parent menu item, and then wait for the page to reload, which is slow and tiresome. That might have been fine for websites in the late 1990s, but it is completely inadequate nowadays when everyone expects fast drop-down or pull-out menus, whose nested components can be displayed using only mouse hover, with no clicks. Drupal 6 still does not have this fundamental capability built-in, so you will want to implement something like the Nice Menus module. The figure below shows what a basic three-level drop-down menu would look like (with the Garland theme). You would most likely want to do further styling to improve the appearance of any such menu on your site.

Menus for You

Now that the navigation system is much better for the visitor, how about making your own life easier, and that of your client? As the administrator of a site, you will spend a lot of time visiting configuration pages, via the Drupal Administration menu. Unfortunately, by default, that menu is tedious to use, for the reasons mentioned earlier about having to click a menu item and wait for page refresh, just to see each nested child menu. For instance, getting to admin/build/menu-customize/primary-links requires clicking three menu links (Site building > Menus > Primary links) to expand the menus.

Fortunately, the Administration menu module creates a slick horizontal drop-down menu system at the top of every page when you are logged in as admin. It is so popular that it comes standard in Drupal 7.

A similar improvement can be made for the Navigation menu, utilizing the SimpleMenu module, which displays the Navigation menu in a persistent drop-down menu bar at the top of every page. This is especially useful when your current theme does not allow enough space for the nested menus in the Navigation menu, causing the longer child menu items to spill over into the main content area, thereby breaking the theme.

Easier Admin

There are several other modules that speed up the time-consuming administrative tasks that developers simply cannot avoid. The default user permissions interface (admin/user/permissions) forces you to page down through multiple screens of permissions, most of which have nothing to do with the ones you are searching for. To find the needle in the haystack faster, some developers prefer the Better Permissions module or the Filter Permissions module, but I have found the Fast Permissions Administration module to be the quickest solution. It filters page contents as you type. The figure below demonstrates how you can instantly see only those permissions containing the string "user".

The Module Filter module offers similar capabilities on the modules admin page (admin/build/modules), which can become just as unwieldy as the permissions page, as a site becomes more complex. In the example below, with a single click you can see all of the modules in the Date/Time package.

Just as with the FPA module, you can type a string of text, to filter the result set to only those modules containing that string in their names, such as "user", illustrated below. There are also checkboxes for filtering by whether the modules are enabled, disabled, required, and unavailable.

That improved version of the modules admin page makes use of vertical tabs as a way of neatly presenting the fieldsets of the page, and avoiding excessive scrolling up and down. They can be applied to all candidate admin pages with the Vertical Tabs module — shown below in the lower part of a Story content creation page.

Most site builders find that one of the first roles they need to create is an "administrator" role, if only so the client — or more commonly, her technical staff — can login and administer the site just as you can. The Admin Role module allows you to designate any role as an administrator role with all available permissions enabled. Also, when a new module is enabled, that role is automatically given its permissions.

Visitors, Good and Bad

In addition to the star admin helpers described above, other essential modules can assist well-intentioned users of your site, and help thwart the evil designs of the opposite sort. If a user is already logged in, and she tries to go to the login, user registration, or password reset pages, rather than showing her the useless and confusing "Page not found" message, it would be much better to take her to her user page, and optionally display a "You are already logged in" message. The Already In module handles that nicely.

To minimize the number of nefarious automated form submissions (either by hacker bots or kids with too much time on their hands), the CAPTCHA module is one of many that can help shore up your site's defenses, and is commonly used on the user login and contact forms. Rather than using the available image CAPTCHAs, I opt for the simple math challenges, because the squiggly character CAPTCHAs can be rather inaccessible to people with vision and cognitive problems, and quite annoying to everyone else.

SEO

Drupal's core Path module may be invaluable for creating more descriptive URLs, but you can take your search engine optimization efforts several steps further. The Pathauto module (which depends upon the Token module) can automatically generate search-engine-friendly URLs, based upon the node title, user name, user ID, or other tokens. The Nodewords module allows you to set meta tags for each node, view, or panels page, or have it automatically generated. The Page Title module lets you assign better values in your pages' TITLE and H1 tags, for any node.

While your project may call for a sitemap page that can serve as a directory for human visitors, be sure to also create a sitemap specifically for search engines. The XML Sitemap module makes it easy, by automatically creating a sitemap that conforms to the sitemaps.org specification, and submitting it to Google Search and other search engines. The module also comes with several submodules that can add sitemap links to content, menus, taxonomy terms, and user profiles.

Your sitemap will be updated every time that your Drupal cron job is run. In Drupal 6, by default, that process is typically only started manually, unless you install and enable the Poormanscron module. Like several other essential components, this one's functionality has been integrated into Drupal 7.

Miscellany

There are three remaining recommended modules that do not fit into any of the subject areas presented above. The Devel module is like a toolbox for programmers — featuring SQL debugging, dummy data generation, node access troubleshooting, cache flushing, user switching, and more.

Most business owners will be quite interested in the web traffic to their site, which can be tracked for free using Google Analytics. The Google Analytics module makes it easy to include the tracking JavaScript code on every page, without your having to add it to your theme's page HTML file.

Lastly, the Transliteration module is probably the best way to ensure that when a user of your site uploads a file to the server, the filename will be sanitized, i.e., spaces, control characters, and other problematic non-ASCII characters will be removed or replaced.

Drawing the Line

Admittedly, there are other modules that Drupal developers may argue should be added to this list. They include commonly-used core modules (e.g., Taxonomy and Trigger), powerful contrib modules (e.g., Content Access, CKEditor, and Location), and modules that are often required by other modules (e.g., Chaos tools suite).

These additional modules are not included in my base installation, for several reasons: Oftentimes some or all of these secondary modules are not used, taking up space. Enabling unneeded modules clutters up the admin menu, right from the start, with the possibility that they will never be used. Later in the development process, and especially after deployment, extraneous modules make it difficult to determine which modules can be disabled and uninstalled, if needed or desired to reduce the memory and disk usage of the site.

I have found that the modules detailed above provide a solid starting point for any Drupal 6 project, and I hope that this information is of value to you as well.