Drupal Cheat Sheet

I'm pretty impressed with the open-source web-site content management system called Drupal, but when I started using it to build web sites, I found it pretty difficult to figure out. This surprised me, because I was already an experienced web developer, including being a PHP/MySQL web programmer (those are the technologies that Drupal is built on), and I was also quite involved in the development community of WordPress (another web site content management system, focused on blogging). I felt like I needed a "cheat sheet" to get me going: an article that would quickly get me familiar with the basics of Drupal, help me figure out how to build a Drupal-based web site in the "right" way, and give me some idea of which of the hundreds of contributed modules out there were the best ones to use on my sites.

But I didn't find a "cheat sheet". Instead, I spent a lot of time reading all sorts of documentation and articles (many of which assumed basic knowledge of Drupal that I didn't necessarily have), and attending meetings and events put on by the Seattle Drupal Users Group to absorb the collective knowledge of people who had been building web sites with Drupal for longer than I had been. Eventually, I learned enough to build pretty complex web sites, so to save other web developers the same effort, I thought I would create this article. To get the most out of this article, you should be a web developer who has built at least plain-HTML web sites, and understands the process of registering a domain name, setting up hosting, creating HTML files, and uploading them to the server. My hope is that after you read this article, you will be ready to build a web site in Drupal, and at least know where to go for more information. (If not, you can hire Poplar ProductivityWare to set up a Drupal-based site for you.)

Sorry about the length of this article, but building a site with Drupal is fairly involved! Also, note that this article was written for Drupal 5 and updated for Drupal 6. The concepts are still the same in Drupal 7 and later versions, but some of the details may have changed.

Here's what this article contains:


Why Use Drupal?

Drupal is an example of a web site content management system, which is a software package that can be used as a tool to build the pages of a web site. In Drupal, most of the text-based content (i.e. the text on your site's pages) is stored in a database (typically MySQL) on your web server. Drupal itself is a set of PHP scripts that runs on your web server. Drupal allows site administrators to create and edit content; allows site administrators to change the menus, URLs, categories, and other configurational aspects of the site; has a comprehensive system to manage users and accounts; and allows visitors to view and interact with your web site. All of the text content for the site is stored in a MySQL database behind the scenes; images and other media files are typically stored on the server rather than in the database.

The main advantage of using a content management system, instead of building a web site with HTML files, is that it is much easier to edit the content, add new pages, and re-configure menus and navigation. Another advantage is that the content of the site is separated from the presentation, so if you want to change the overall look of the site, you will not have to go back and edit all your content pages -- you just change the template.

The main advantages of Drupal over other content management systems are that it is free, open-source software; it uses the ubiquitous PHP/MySQL technology as its platform; it has a very large community of users, so bugs are found and fixed quickly; there are many web developers available to build Drupal-based sites; it has a huge number of free add-on modules to cover most of the functionality that web sites need; and if you don't find a module for the functionality you need, you can write your own add-on module (or hire Poplar ProductivityWare to write one for you).

There are some advantages to WordPress too. If you are building a fairly simple web site that is basically a brochure, with perhaps a news, articles, or blogging component, you don't need all the functionality of Drupal, and I would instead recommend using WordPress as the content management platform. It shares many of the advantages of Drupal (it's open-source, based on PHP/MySQL, extensible, and backed by a very active developer and user community), but it's a lot simpler to use and set up -- you won't need a "cheat sheet" to figure it out: pretty much just install it, find a theme you like, and you're ready to go. My comparison of Drupal and WordPress article, elsewhere on this site, has more information. Also, if you are interested in other content management systems besides Drupal and WordPress, check out the short reviews in my article on resources for web programmers.

Back to table of contents


Glossary of Drupal Concepts

This section contains a glossary of the Drupal terms and concepts that you need to understand before reading the rest of this article. For a more comprehensive introduction to Drupal, check out the Overview pages from the Drupal Getting Starting Guide on drupal.org.

Paths: Each page on your web site, including the built-in administration pages you will use to build and modify your site behind the scenes, has a path, or URL, associated with it. Drupal typically refers to pages on the site by just the suffix part of the path -- excluding the base URL of the site. For instance, on your site, the Create Content administrative page might have a URL something like www.example.com/node/add, or it might be more like www.example.com/sub/dir/?q=node/add, but in either case, the Drupal path would be just "node/add". In the rest of this article, the URLs of administrative pages will be given by just their path suffix, so you'll need to figure out how that relates to your own site. The paths given below are correct for the 5.x and 6.x versions of Drupal; I'll try to update them for later versions as needed.

Content types and nodes: In Drupal, pieces of content that make up your web site belong to particular content types. For example, a typical static web page has content type "Page", a news article has content type "Story", and a new topic of discussion in a forum has content type "Forum Topic". Each of these content types in Drupal is a specialized version of the basic content type, which is called a "node" in Drupal. A basic node has a title, a body, a unique ID number, a content type designation, a record of who created it and when, and some other settings associated with it. Other content types have additional fields and types of information associated with them; you can even create your own content types. You may hear people say, in regards to Drupal, that "everything is a node," which is a good way to remember that most of the content in Drupal is stored in content types that are variations of the basic node content type. However, there are certainly exceptions: not all the content that you can display on Drupal web pages is actually stored in nodes (some examples are in the sections below). You can create new content by visiting path "node/add" on your site, and you can manage and edit existing content by visiting path "admin/content/node" on your site.

Comments: If you have the optional core "Comment" module turned on (see below for module terminology), some of the nodes on your web site (such as forum topics and blog articles) can be set up to allow visitors to the site to comment on them. In Drupal, comments are stored separately from the node they refer to, and typically displayed on the same web page as their node. Comments are one example of content on your site that is not a node.

Users and Roles: Everyone who interacts with your web site, from the visitors to the administrators, is considered a "user" in Drupal. Users can be given permission to access certain content and perform certain actions on your site; these permissions are granted by assigning users to "roles," and defining authorization permissions for each role. When you first install Drupal, there are three roles defined. The most basic is called "anonymous user", which corresponds to a web site visitor who has not logged in. The next role is "authenticated user", which corresponds to a person who has logged in to a user account on your web site. There is also an implicit role that I like to call the "super administrator": the first user account that you set up when you install Drupal is given an internal ID number of 1, and that user account always has permission to perform all administrative actions on the site (although this role is not really defined explicitly). A user with sufficient permission can define new roles for your site, create new user accounts, and assign different permissions to the roles; the screens to manage users and roles can be found at path "admin/user".

Themes: Drupal, like most good content management systems, has a strong separation between the content of your site and how that content is presented. This allows you to define many web pages in the administrative back end, and ensure that they all conform to your web site's basic design (e.g. header, footer, sidebars, color scheme) when they are presented to a visitor. The mechanism for ensuring that the pages are presented in a consistent manner, and for defining the style and design of your site's pages, is through the use of a Drupal "theme", which is a set of web scripts, images, and style files that you will upload to your web server. You can have more than one theme installed on your site, but only one theme is active for any one page view, and most sites are set up to allow the use of only a single theme. The section below on themes has more information on this topic.

Modules: The core functionality of Drupal is pretty basic -- it's more of a framework than a complete system for creating a web site. The Drupal framework can be extended by installing and activating add-on "modules", which are sets of PHP scripts that modify or extend the functionality of the core Drupal framework. The basic Drupal distribution contains several "optional core modules", which are modules that come with the distribution, but are not turned on by default. You can also download and install "contributed modules", which are modules written by members of the Drupal community. Finally, if you are a PHP/MySQL programmer (or hire one), you can also write your own custom modules. Most Drupal-based sites will make use of at least a few optional and contributed modules. The section below on modules has more information on this topic.

Menus: In the administration section of your Drupal site, if you have the optional core "Menu" module turned on, you can create and modify various "menus" (path: admin/build/menu), which are basically just ordered collections of links to pages on your site. Some menus are pre-defined; you can also create your own menus. Drupal will only display a given menu item to a user who is authorized to view the page it links to, so you can add items to menus without worrying about whether they're applicable to all roles on your site. (By the way, the text in menus could be considered content, but menus are not nodes.) See the Menus handbook on drupal.org for more information.

Blocks: Blocks are generally small lists of links or other formatted text, which you can place in various regions on your site's pages, such as in the header, the footer, a sidebar, or below the main content. Various Drupal modules produce block output (for example, each menu you define is available as a block), and you can also create custom HTML blocks from the block administration page (path: admin/build/block). This screen, in addition to letting you create blocks and assign them to regions of your theme, also lets you restrict blocks so that only certain roles can see them, or so that they only appear on certain pages of your site. See the Blocks handbook on drupal.org for more information.

Taxonomy: The optional core "Taxonomy" module allows you to categorize your web site -- for instance, to create systems of categories or tags for your site's content. You can limit certain "vocabularies" (or groups of related categories) to certain content types, and have other vocabularies that apply site-wide. See the Taxonomy handbook page on drupal.org for more information. The path for the taxonomy administration page is "admin/content/taxonomy".

Weight: Many Drupal administration screens use the concept of "weight" to define an order within a collection of items. For instance, when you create a menu, each menu item gets a "weight" number. When the menu is displayed, the "lighter" items (the ones with the smallest or most negative numbers) "float" to the top of the menu, and the "heavier" items (the ones with the largest or most positive numbers) "sink" to the bottom of the menu. In Drupal 6 and later versions, weights are no longer as visible as they were in Drupal 5, because you can use a drag-and-drop interface to order menus, taxonomy terms, and other weighted items. However, you will still see weight number selection boxes in some places, so it's useful to know about the concept.

Input Format: When editing content in Drupal, you will often see an option to select an "input format" for a text/HTML area field. Input Format is a bit of a confusing term here -- what it really means is that when Drupal is displaying content from that text area, it will "filter" the text before displaying it (so it's really more of an output format than an input format). When you install Drupal, you will typically have two input formats defined: Full HTML, which allows you to use any HTML formatting in your text, and Filtered HTML, which will remove all but a limited set of HTML tags from your text. In addition, both of these formats make some other changes, such as turning email addresses and web addresses into links, and converting blank lines into paragraph breaks. You can modify these processing steps, define your own input formats, and restrict which roles can use which input formats on the Input Formats configuration page (path: admin/settings/filters).

Drupal's Directory Structure (directory is another word for a "folder" of files) is as follows:

  • top-level directory: The top-level directory of your Drupal installation contains the .htaccess file (which you may or may not need to modify, hopefully not!), a few documentation files (such as INSTALL.txt and LICENSE.txt -- you might want to read them), and a few PHP script files that are used by Drupal. Aside from the .htaccess file, you probably should not modify anything in this directory, and you probably shouldn't add files to this directory.
  • includes, misc, modules, scripts, themes: These directories contain the core files of Drupal. You should normally not add anything to these directories, or modify the contents, because if you upgrade later to a new version of Drupal, these are the directories that will be overwritten with the new version's files. In particular, if you install non-core modules or themes, do not put them in the core modules and themes directories! Use the "sites" directory instead (see below).
  • files: This is the directory that Drupal versions prior to Drupal 6 chose as the default location for uploaded files, such as images and attachments for your web site's pages. Drupal 6 makes the better choice of putting them under the "sites" directory (see below); you can also choose to do this in a pre-Drupal-6 installation.
  • sites and sites/all: The "sites" directory contains files for the web site or sites (one Drupal installation can be used to manage multiple web sites) you are managing. Underneath "sites", the "all" directory contains files that pertain to all the sites you are managing, and the other directories, including "default", are each used for a single site (see below). Underneath the "all" directory, and/or site-specific directories, you can create sub-directories "modules" and "themes", which is where you install add-on modules and themes for your site or sites. For instance, put an add-on module that is going to be used by several of the sites you are building in sites/all/modules, and an add-on module that is specific to the site whose directory is "mysite" into sites/mysite/modules.
  • other sites/whatever sub-directories: A single Drupal installation can be used to run multiple web sites; aside from the "all" subdirectory mentioned above, each sub-directory of "sites" contains files pertaining to one web site. For instance, if you want to have sites abc.example.com, def.example.com, www.example2.com/abc, and www.example2.com/def all running within one Drupal installation, you would create subdirectories sites/abc.example.com, sites/def.example.com, sites/www.example2.com.abc, and sites/www.example2.com.def, respectively. If you are certain that your Drupal installation will only ever be used to run one Drupal site, you can just use the sites/default subdirectory. Each site-specific directory must contain a file called "settings.php", which contains information about site URL and the MySQL database. For obscure reasons, it is also important to have the "default.settings.php" file present in each directory (this is provided in the sites/default directory when you first install Drupal; you should copy this to settings.php rather than renaming the file). Within each site-specific directory, you can also have "modules" and "themes" directories that are specific to that site, and you should also set up a "files" directory to store your uploaded files, rather than storing them in the top-level "files" directory (to do this, visit the File System administration page at admin/settings/file-system; this is also the default for Drupal 6 and later versions). The INSTALL.txt file that comes with Drupal has more information, and you can also check out the Multi-Site Drupal handbook on drupal.org
  • profiles: The profiles directory is used for "installation profiles", which might help you set up Drupal automatically for the type of web site you are building. However, there are not very many installation profiles available yet. More information can be found in the Installation Profiles handbook page on drupal.org.

Back to table of contents


Site Building Checklist and Pitfalls

This section contains an overview of site building in Drupal: what order to do things in, where to find more information on each step, and some pitfalls you can avoid. Here are the steps I suggest following, in this order, when creating a Drupal-based web site:

  1. Plan your site: See the Site Planning section below for more information.
  2. Decide which Drupal version you want to use. You will first need to decide on the "major version" of Drupal: 4.x, 5.x, 6.x, etc. My recommendation is that you use the most recent major version, unless it is so new that most modules don't yet have compatible versions for it (you can find this out by visiting the Modules list page on drupal.org, and scanning the Version sections to see what Drupal versions each module is compatible with; for instance, in February 2008, Drupal 6.0 was released, but most of the modules were not yet updated to 6.0, so I would have chosen 5.x as my major version). Once you have decided on a major version, you will probably want to use the latest release of that version, because it will have the latest bug fixes and security updates. There is also a page on drupal.org that discusses how to choose which version to use.
  3. Download the zip file for the Drupal version you are installing, from the download Drupal page on drupal.org.
  4. Unzip and upload the Drupal files on your web server, create the sites subdirectory for your site (see above), copy in the default.settings.php and make another copy called settings.php, and run the install script. This is described in great detail in the Getting Started Guide on drupal.org - go to that link, choose your Drupal version, and read the Installation Guide sections. (If there is not yet a Getting Started Guide for the major version you have chosen, it might be time to revisit that decision and go back to the previous major version.)
  5. Locate, unzip, and upload the contributed modules you will need for the site's functionality. (Don't activate the modules yet -- just upload them to your site.) See the modules section below for more information on how to choose and install the modules you will need. Important: when you add a contributed module to your site, you need to add it to the "sites" directory, not the main "modules" directory! See the section above on Drupal's directory structure.
  6. Locate, unzip, and upload the theme you want to use for your site, or at least the theme you plan to use as a starting point for customization. See the themes section below for more information on themes. Important: when you add a theme to your site, you need to add it to the "sites" directory, not the main "themes" directory! See the section above on Drupal's directory structure.
  7. Set up a time zone and basic site information. The time zone settings are at path admin/settings/date-time, and the basic site information is entered at path admin/settings/site-information. Important: Don't fill in the mission for the site yet. The reason is that in some Drupal versions, if the optional core "Drupal" module is enabled, and your site has a mission filled in, that will trigger the site to appear in a directory on drupal.org, and you probably don't want that to happen until your site is ready for public viewing.
  8. If you are using the (recommended) Admin Role module (see modules below), enable this module and set it up, before enabling any other modules.
  9. Enable the Path module (see modules below), and get Clean URLs working (Clean URLs are at path admin/settings/clean-urls; in Drupal 6 and later versions, Clean URLs may also be enabled when you run the install script). The Path module and Clean URLs setting are what allow you to have "clean" URLs without a question mark or the word "node" in them on your site; for example, instead of URLs like www.example.com/?q=node/3, you can have URLs more like www.example.com/about. If you find that the Clean URLs page gives you an error message, and says your site is not configured properly for clean URLs, you can probably follow the instructions there to fix it. In particular, for sites I have built, I have found some or all of the following changes to be necessary to get Clean URLs working on some web hosts:
    • In the site's settings.php file, define a base URL: search for a line that starts with $base_url, remove the "#" (comment) character at the beginning, and edit so that it points to the base URL of your Drupal installation (for instance, 'http://www.example.com/drupal').
    • In the site's .htaccess file, remove the "#" character on the line that has "RewriteBase" in it, and make it say "RewriteBase /" (without the quotes).
    • If your Drupal installation is in a sub-directory of the base URL of the site (e.g. example.com/drupal), then find the section several lines down in the .htaccess file that is marked as dealing with URLs of the form 'index.php?q=x', and change the line that starts with "RewriteRule" so that it points to the actual location of index.php (e.g. in this example, replace index.php with /drupal/index.php in that line).
  10. Enable other modules needed by your site (see modules below).
  11. Create content types for your site (assuming you are using the CCK module; path: admin/content/types). See the planning section below for more information on content types.
  12. Enter at least some sample content, at least one item of each of your custom content types, and place-holders for the main static pages of your site (path: node/add).
  13. Create views, menus, and panels for your site (assuming you are using the Views, Menus, and Panels modules; paths: admin/build/views, admin/build/menu, admin/build/panel). Also, configure the blocks (path: admin/build/blocks). For more information, see the site planning section below (views and panels), the glossary section on blocks above, and the glossary section on menus above.
  14. Set your site's home page, by visiting path admin/settings/site-information. The default path is "node", which tells Drupal to display the most recent content on your site that was marked "Promote to home page". For most sites, this is probably not what you want, so you can set the home page to any other path on your site (a single page piece of content, a view, a panels page, etc.).
  15. Customize your theme, if necessary (see the themes section below).
  16. Finalize your content (path: admin/content/node).
  17. Set up cron - Drupal sites need to have a "cron" job run periodically in order to function properly ("cron" is a Unix/Linux utility that runs tasks on a computer on a schedule). See the cron job page in the Drupal handbook for more information, or use the Poor Man's Cron module (see modules section below).
  18. Check your site for security and integrity, and you're done! Some considerations:
    • Backups: you will probably want to schedule regular backups of both the MySQL database behind your web site, and the uploaded files (which should be stored in the "sites/*/files" directories of your Drupal installation). The modules section below lists some modules you can use to perform backups.
    • Configuration Warnings: When you visit the main Drupal administration page on your site (path: admin), you may see a red warning message across the top. If so, you should probably check the status report (path: admin/reports/status) see what is wrong, and fix it, because some of the problems the status report lists are security risks.
    • Permissions: Verify that the different roles you have set up have the correct permissions on the Configure Permissions screen (path: admin/user/access).
    • Modules: There are also some Drupal security-related modules available on drupal.org; you might browse through that list and see if any of them sound useful for your site
    • Software Updates: Periodically check for security updates for Drupal and the modules you are using (in Drupal 6, you can turn on the core Update Status module and you'll be reminded of updates when you log in). You can also be notified by email of security updates released for Drupal itself; see the Security page on drupal.org for more information.
    • Site Feature Updates: Once you have Drupal installed and customized for your site, updating and adding to the content is straightforward in the administration interface. However, sometimes you will need to add a new feature or functionality to the site, or modify how a current feature works. This can be difficult, because you probably don't want to break the "live" site while you're testing the new feature. A strategy for making such updates:
      1. Back up your live site's database, and use this to build a test version on another server. All you should need to do to use one Drupal site's database contents for another site is to create the appropriate settings.php file.
      2. Follow the instructions on this page on database migrations on drupal.org to track content revisions on your live site.
      3. Make the configuration changes on your test site. These will normally involve creating or modifying content types, views, and panels. If you are also installing or updating modules as well, you will eventually need to upload the same files to the live server!
      4. When the test site is working properly, find all revisions to content on the live site since your backup, and make the same changes to the test site manually (see article referenced above).
      5. Back up the live database again. Back up the test database, and use this backup to overwrite the live database.
    • See the Installation, Migration, and Backups page on drupal.org for more suggestions.

Back to table of contents


Site Planning

Before you build your site, it is important to have a plan for the following aspects of it:

  • Design: overall look of the site, styles, colors, layout, etc.
  • Functionality: forums, blogs, static pages, contact forms, e-commerce, etc.
  • User Interaction: roles for users, what you want visitors for the site to be able to do, flow from page to page, what should be in the menus, etc.

Once you have a plan for the design, functionality, and user interaction of your site, the next planning step is to figure out what you'll need to add to and customize in Drupal to achieve your plan. For most web sites, this means a combination of custom content types, views, panels, a theme, and modules. I'll discuss the first three here; recommended modules are listed in the modules section below, and theme customization is discussed in the themes section below.

Custom Content Types

Many web sites can be best built using custom content types, which are nodes (see glossary section on nodes above) with added data fields. For instance, in a site I built for a roofing company, I created a custom content type "Material" that contained fields pertaining to roofing materials, such as an image of the material, the name of the manufacturer, and a link to the manufacturer's web site. Another custom content type, "Customer", contained information about a customer: before and after photos, the house's address, the roofing material used (a reference to a "Material" node), a way to specify that this is the "featured" customer, etc. The Content Construction Kit (CCK) module, and probably one or more CCK sub-modules, which give you more data type choices, must be installed and activated to allow creation of custom content types in Drupal version 6.x and earlier (path: admin/content/types). It appears that this functionality will be in the core of Drupal in version 7. See the Content Construction Kit Handbook on drupal.org for more information on how to create content types with CCK. You might also want to check out a talk I did on custom content types and views.

Views

Once you have created custom content types appropriate for your site, you will probably want to use the Views module to display your custom content types. Views are either full pages or blocks (see glossary section on blocks above) that contain one or more nodes; you can specify various "filters" to define which nodes are included, and choose to display the included nodes as complete nodes, teasers, tables of fields, lists of fields, grids, etc. You can also "expose" some or all filters for your views, to allow site visitors to restrict the view to subsets of the nodes, and you can define "arguments" so that depending on the path used to access the view, different subsets of nodes are displayed. For more information on how to create views, see the Views Documentation page on drupal.org, or the advanced help within the Views module, depending on which version of Views you are using. You might also want to check out a talk I did on custom content types and views.

As an example of views, on the roofing company site mentioned above, I created a "Materials Gallery" view that showed all the Material nodes as complete nodes (with a special theme function that arranged them in a 2-column table), and three different views of Customer nodes: a Featured Customer block that picked out the featured Customer and displayed it, a zip code-filtered page that allowed site visitors to search for customers in their zip code, and a material-filtered view that allowed site visitors to search for photos of houses roofed with certain materials. One other useful feature of views is that you can also define permissions for each view (which roles can view them and whether users can filter them).

Panels

Once you have content types and views defined, you may find your site needs a couple of "panels" pages. Most of the pages on your web site will follow the general layout defined by your theme, which is normally a header section at the top, a footer at the bottom, left and/or right sidebars, and a content section in the middle. But often, a few pages need to have a different layout. For example, maybe the home page needs to have 4 sections, arranged in a 2x2 grid, in the main content pane, for News, Events, Featured Product, and the weather in Toledo. The Panels module allows you to do that (note: you probably want to use Panels Version 2 or 3, even if it is still in a "beta test" version). Often, Views with Filters and Arguments are what goes in panels, and with Panels Version 2, you can even use different portions of the panel-page path to feed into different panels as path arguments. See the (in progress) Panels 2 Documentation page on drupal.org for more information. One other note: with some coding, a Panels page can also override the main layout of a theme (for instance, you might not want the usual sidebar on the home page). There's a page on the Seattle Drupal group about this.

Back to table of contents


Themes

This section contains information on Drupal themes, including how they work, where to find new themes, and how to install them.

How Themes Work

As outlined above in the introduction and glossary sections, Drupal uses a "theme" system to separate the content of your web site from the way that content is presented. Basically, when someone requests a particular URL on your site, Drupal figures out what the Drupal path is for that URL, gets the content from the database for the blocks (see glossary section on blocks, above) on the page, as well as the main content section, and sends this content to the "template engine" you are using. The template engine then figures out which theme functions and/or files are needed to render the content in your theme, and uses them to convert the content into an HTML page (or in some cases, an RSS/XML page or other format), and sends this out across the network to the site visitor's browser.

There are four main options for template engines in Drupal; each theme is specific to a particular template engine, because the files needed for a theme vary depending on what template engine it is based on. The main engines are:

  • PHPTemplate - the most popular, most developed, and therefore recommended template engine; it is also the default in Drupal 5.x and later versions, and heavily built into the structure of Drupal in 6.x and later versions. For information on programming with PHPTemplate, see the PHPTemplate page on drupal.org.
  • Smarty - possibly easier to use for theme designers who are not PHP programmers - more information can be found on the Smarty page on drupal.org.
  • XTemplate
  • Write your own template engine

The rest of this article will assume you want to use the PHPTemplate engine.

Finding Themes

When you install Drupal, you will find that it gives you several themes to choose from. You can customize the colors of some of these themes (if you turn on the optional core Colors module), as well as the logo image and in some cases, text appearing in headers, footers, and sidebars. You can also change the blocks and menus for these themes (see glossary section on blocks and the glossary section on menus above). However, for many sites, you will probably want to find a different theme, or create a custom theme. My advice, if you want to have a customized look for a site, is to start by finding a theme whose structure is reasonably close to what you are looking for, and then modify the CSS styles for the theme, and possibly add some custom theme programming until it is what you want. If you are planning on creating a highly customized theme, I recommend starting with either Box_grey, Zen, or one of the themes that is distributed with the core Drupal files.

You can search for new themes on the Themes page on drupal.org. When you find a theme that you think you might like, make sure it is based on the PHPTemplate theme engine (it probably is, unless it specifically says it isn't), and make sure it is available for the version of Drupal you are running. You might also want to check its licensing conditions, and make sure you are willing to abide by them (all themes from drupal.org are licensed under the GNU Public License). Then download the theme, and see below for how to install it.

There are also companies that offer nice Drupal themes for purchase or free download, but not on the official drupal.org page. If this is an option you're interested in, check out Top Notch Themes and RoopleTheme.

Installing and Activating Themes

The Getting Started Guide on drupal.org has more detailed instructions on how to install themes, but I'll outline the steps here. Important: see the section above on Drupal's directory structure, in regards to where to install themes.

To install and activate a theme:

  1. Download the zip file for the theme and unzip it onto your local computer. It should unzip into its own directory, named after the theme. (If your starting point for customization is one of the themes distributed with Drupal, you can find its files in the Drupal zip file, in a subdirectory of "themes".)
  2. If you are planning to customize this theme extensively for your site, you might want to rename it. To do this, change the directory name, and also edit the theme name in the style.css file or the .info file (depending on the Drupal version) of the theme.
  3. Upload the directory of files to your web host, creating them as a sub-directory of either sites/all/themes or a site-specific sub-directory such as sites/mysite/themes.
  4. To enable the theme, visit the Themes administration page (path: admin/build/themes). Find your theme in the list. You can enable it by checking the Enabled box; you can also make it the default theme by clicking the Default option. You may also want to disable some of the other themes at this time. Click the Save Configuration button at the bottom of the screen, and if you chose this new theme as the default theme, you should see an immediate change in the styles and layout of your page (unless you have defined a separate administration theme).

Back to table of contents


Modules

This section contains brief instructions on how to install add-on modules on a Drupal site, as well as some recommendations on which modules to use. To find modules not listed here, visit the Modules list on drupal.org.

Installing and Activating Modules

The Getting Started Guide on drupal.org has more detailed instructions on how to install modules, but I'll outline the steps here. Important: see the section above on Drupal's directory structure, in regards to where to install modules.

To install and activate a module:

  • Download the zip file for the module and unzip it onto your local computer. It should unzip into its own directory, named after the module (for instance, the Views module is in directory "views").
  • Upload the directory of files to your web host, creating them as a sub-directory of either sites/all/modules or a site-specific sub-directory such as sites/mysite/modules.
  • To activate an installed module, or an optional core module (which you don't have to download/upload), visit the Modules administration page (path: admin/build/modules), find your module in the list, click the Enabled check box, and click the Save Configuration button at the bottom of the screen.
  • You may find that your module cannot be enabled because it depends on another module that is not yet installed or enabled. If that is the case, you'll need to follow the instructions above for the module you need, then return to the Modules administration page to activate the module you originally wanted.

Recommended Modules

One of the great strengths of Drupal is that there are so many contributed modules available ("contributed" meaning that they are not distributed with Drupal, and you have to install them separately), so practically anything you want to do, you can probably find a module to do it. However, there are so many available that finding them is a big problem. So, in this section, I list some of my favorite modules. In general, all the optional core modules that come with Drupal are also good, if you need their functionality (for instance, if your site needs a forum, use the Forum module, and if you want to offer polls, use the Poll module). I won't go through all of the core modules here; you can read about them on the Core Modules handbook page on drupal.org.

Essential Modules for Site Building

These modules are pretty much essential for all, or at least most Drupal sites.

  • The optional core Path module lets you set up nicer URL paths to your pages, as outlined in the Site Building Checklist section above. On a larger site, you will probably want to use Pathauto, which automatically chooses URLs based on your node titles (Pathauto depends on the Token module, so you'll need to install that too). The Global Redirect module is also useful for making sure you only have one URL being used for each page on your site. Path Redirect allows you to specify permanent redirects from one URL on your site to another URL (especially useful if you are migrating from an old site to a new one with different URLs, or if you change some URLs on your site).
  • Unless you and all other possible content writers and editors on your site enjoy writing raw HTML, you will probably want to install a "WYSIWYG" (What You See Is What You Get) HTML editor for your site. There are many WYSIWYG editor options for Drupal, most of which are stand-alone modules -- you can browse through them on drupal.org. My recommendation is to start with the WYSIWYG API module, and choose from one of the editors it supports. I've written a blog post on how to configure this module, which may be of use. My reasons for choosing this module:
    • Many of the other editor modules are difficult to set up and configure; WYSIWYG API makes it pretty easy.
    • The module supports a variety of editors (you download the editors from links provided within the module), so you can choose one that supports the editing features you need on your site, or produces the best results. You can even have several installed at the same time. I normally choose (and recommend) the FCK editor plugin within this module; TinyMCE is another popular choice.
    • You can use different editor profiles for different input formats, which means that you can have a small set of editor buttons enabled for restricted input formats, and only use the full toolbar for Full HTML formatting. See the glossary item above on input formats for more information.
    • This module is very smart about figuring out which text area fields on an editing screen need WYSIWYG editing, and it supports new fields that are added dynamically through AJAX/AHAH methods. (Technical detail: WYSIWYG API keys off fields that have Input Formats defined for them, and ignores plain-text fields. See the glossary item above on input formats for more information.)
    • If you want your content editors to be able to insert images at random spots into the content they are editing (as opposed to templating pages with images at fixed locations), I recommend the Insert module, along with ImageField (see below for more information on ImageField).
  • CCK (Content Construction Kit) allows you to create custom content types. CCK sub-modules give you more data types. See the planning section above for more information on how to use this module. You might also want to check out a talk I did on custom content types and views.
  • Views gives you the ability to create pages and blocks that display one or more nodes (or fields from nodes) in a list, grid, or other formats. Views sub-modules give your views more functionality (Calendar and Views Calc are especially recommended). See the planning section above for more information on how to use this module. You might also want to check out a talk I did on custom content types and views.
  • There are several possibilities for how to manage images and other media files (thanks to Scott, whose presentation at the Seattle Drupal Camp contributed to these recommendations):
    • Image allows you to make Drupal nodes, each of which holds and displays a single image. I don't think this is the best option.
    • ImageField is a CCK field type for images (based on FileField, a generic file upload CCK field module), which is good if you have content types that have specific images to be displayed in specific spots on the page (you can add more than one image field in a particular content type). If you're willing to do a little programming, it's also possible (I did it recently for a client) in a theming function to place images from ImageField more flexibly within the text of the page (for example, where the page editor has typed [PUTIMGHERE]). You can also use the Insert module (see WSYIWYG section above) to allow people to upload images and insert them in your content body.
    • Video Filter adds a very easy way to insert embedded videos from a wide variety of third-party sites (YouTube, etc.).
    • Asset manages images, video, etc. as files and URLs, and adds an open-ended "Add Assets" section to data entry on nodes. Do not confuse this module with Asset Manager or Assets, and make sure to read the installation instructions carefully. Check the Asset project page for related modules, such as the Asset Bonus Pack, which includes a video player.
    • Embedded Media Field provides CCK fields for embedding media in your site from third-party providers such as Flickr and YouTube.
    • ImageCache works with Image, ImageField, and Asset (check version compatibility to be sure!) to allow you to define processing steps for images (e.g. cropping, changing resolution, etc.). Once a set of steps is defined, accessing a special URL instead of the base image location will activate processing; once the image is processed once, the file is saved for later viewing. It has an associated API module you could use to create your own processing module, and ImageCache Actions provides some additional processing capabilities. Having ImageCache installed and pre-sets defined also gives you a lot of control over how images are displayed in your content in full node view, teaser view, and in Views.
    • If you need a gallery, my recommendation is to use Image, Asset, or ImageField to build nodes containing images, ImageCache to define how the images should be displayed, and then use Views to create the gallery itself. The Views Bonus Pack provides a grid view that might be helpful, though if you are using Views 2.x, the grid view is built in.
  • Webform allows you to create multiple web forms for your site. The optional core Contact module creates contact forms for individual users and one site-wide form, but Webform gives you flexible forms.
  • Meta Tags lets you edit and include meta tags (description, keywords, etc.) for each page on your web site, or at least those pages generated from nodes, views, and panels.
  • Many sites will need some type of search functionality. I have a separate article on Search in Drupal, which suggests modules and methods for search in Drupal.
  • Making links between pages of your site can be a problem, especially if you are using Views (so that a particular piece of content may be displayed on various pages of your site). The Path Filter module is a good way to make these internal links feasible to maintain, as well as portable.
  • If your site needs to respond to events, the Rules module is a much better option than the Trigger module that comes with Drupal. It allows you to set up flexible responses to various events, such as sending email to several different people when a workflow status changes on a content item.

Other Recommended Modules for Site Building

These modules are not essential for all sites, but are highly recommended if you need their particular functionality.

  • Location and its related modules are the standard way to tag nodes and users by location.
  • CCK add-on modules for specific types of fields:
  • Panels allows you to set up pages with multiple "panel" sections (note: you probably want to use Panels Version 2, even if it is still in a "beta test" version). See the planning section above for more information on how to use this module.
  • Site Map creates a configurable human-readable site map page for your site, which can include full menu trees, taxonomies, and other features.
  • Nice Menus allows creation of drop-down and slide-left/right menus.
  • Menu Block allows you to create flexible copies of all or part of Drupal menus as blocks.
  • Custom Breadcrumbs allows you to define the breadcrumb navigation trail for your content types, as an alternative to using the standard Drupal breadcrumb trail, which relies on the Navigation menu (Drupal 6) or Primary Links (Drupal 5) to define the breadcrumb. Menu Trails allows you to customize which menus display as "active" when particular content types are being viewed; this is a good complement to Custom Breadcrumbs. It looks like this module may also include the functionality of Custom Breadcrumbs, but I haven't tried that part. Menu Breadcrumb is a Drupal 6 module that bases breadcrumbs on menus other than the Navigation menu. Note: As of August 2009, the Menu Breadcrumb module has a bug that makes it behave badly with the Admin Menu module -- see http://drupal.org/node/303247 for more information. It also looks like this module is looking for a new person to maintain it. Hopefully it will get fixed up soon, because it's quite useful.
  • Page Title allows you to make the HTML page title for a node page be something other than the node's title.
  • Context lets you create sections of your site, and define which blocks, theme, etc. are active when that section is being viewed.
  • Multiblock lets you have more than one copy of a particular block configured, which can be quite useful if you need to put a block in one region sometimes, and another region at other times.
  • Ubercart is an actively-developed e-commerce system for Drupal. For documentation and support, visit ubercart.org. You may also find the Ubercart quick-start guide from Top Notch Themes helpful.
  • Flag allows you and (depending on permissions) site visitors to mark content in ways that you decide on (examples: "important", "offensive", "featured", etc.). It is well integrated with Views, so you could for instance create a "featured" flag that only site admins could use, and a View that would show the featured content in a block. You can also set up Actions (Actions is in core in Drupal 6.x and later, and is a contributed module for 5.x) to take place when content is flagged.
  • Fivestar (based on Voting API) gives you the ability to rate nodes, comments, and users on a "1-to-5 star" rating system (it is configurable, so it doesn't have to be 5 and it doesn't have to be stars). It is also well integrated with Views.
  • Signup lets you set up events for site visitors to sign up for.
  • Notify lets registered users sign up to get email when site content changes.
  • Advanced Taxonomy Blocks allows creation of multiple blocks that list terms in your taxonomy vocabularies, with links to the taxonomy page (which lists content classified with the term).
  • Node Queue allows you to create prioritized collections of nodes, and do various things with them, such as display a random choice of one of the nodes in a block. Note, however, that it doesn't work well with Views.
  • Content Profile allows you to define standard node-based content types (presumably including CCK fields) to use as user profiles for each role, and integrates them into the user page. It's basically an alternative to the core Profile module, which doesn't use node types for user profiles, and is therefore harder to integrate into Views, searching, etc.
  • Advanced Forum extends the functionality of the core Drupal forum module
  • It is possible to combine the Mailhandler and Listhandler modules with the optional core Forum module, in order to integrate a Drupal forum with an email list (you have to set up the email list outside of Drupal). This article on drupal.org explains how to do it, and I know of at least one site that has done this successfully. Other modules related to mail and messaging:
    • Mail to Web - allows users on your site to email comments to your site for posting.
    • Notifications - allows users on your site to subscribe and be notified of various events by a means of their choosing (email, SMS, Twitter, etc.).
    • Both of these depend on the Messaging framework module.
  • Secure Pages lets you set some pages on your site to use the secure HTTPS protocol, while leaving the rest with HTTP.
  • Formfilter lets you turn off display of your choice of elements in Drupal-generated forms, without writing your own "form alter" module. This can be quite useful when you are setting up a site for inexperienced users, to avoid confusing them.

Essential Modules for Site Administration

These modules are pretty much essential for all Drupal sites, to make them easier to administer.

  • Admin Role creates an administrator role on your site, and then gives that role full privileges on any modules you install afterwards. This basically allows you to have multiple administrative "super-users", if you install it before any other modules.
  • Backup and Migrate allows you to back up and restore the Drupal MySQL database. Its companion Backup and Migrate Files (BMF) module backs up your files (uploads, images, etc.). Note that BMF is, as of this update (April 2010), under development and I haven't tried it yet. Another database backup option is DB Maintenance. The latest version of this module can schedule file backups as well as database backups, but it's a bit more difficult to configure than Backup and Migrate, and it doesn't come with an easy way to view and download saved backups.
  • Admin Menu puts the full Administration section of Drupal as a menu across the top of your site, when you're logged in as an administrator. It can save a lot of time navigating to various administrative functions.

Other Recommended Modules for Site Administration

These modules are not essential for all sites, but are highly recommended if you need their particular administration-related functionality.

  • Content Access allows you to restrict access to particular content types and particular nodes, on a per-role and per-user basis. The Content Permissions module that is distributed with CCK can be used to restrict view/edit permissions on a field-by-field basis for CCK-based content types (e.g., to create internal-use-only fields on your content types). If you just need to restrict access on a content-type basis (e.g., only certain roles have permission to view certain content types), then the core Drupal permissions system is sufficient.
  • Flexifilter lets you define your own filters for use in input formats (see the glossary item above on input formats for more information).
  • Filter by Node Type allows you to restrict which input formats are available for each content type (see the glossary item above on input formats for more information).
  • Workflow allows you to assign different states to in-progress content, such as Draft, Review, Published.
  • Poor Man's Cron allows you to run the Drupal cron (periodic) tasks on a schedule, if you don't have the ability to set up a "cron" job on your server. It is probably better to use a "cron" job though, if your web host provides you a way to set them up.
  • XML Sitemap creates a machine-readable XML site map for use in submission to search engines such as Google.
  • Google Analytics integrates Google Analytics with Drupal.
  • The optional core Throttle module allows you to deal with surges in web traffic. See the handbook page on Throttle on drupal.org for more information.
  • Boost adds a static cache to Drupal, to speed up page loads. It is complex to set up, but does work even on shared hosting sites, and can really speed up a site where most visitors are not logged in.
  • Drupal, by default, creates a "session" for each anonymous visitor to your site, which can add a lot of overhead to a site, and is not necessary for most sites. In Drupal 7.x, we'll apparently have the ability to turn this off; for Drupal 6.x, you can use the No Anonymous Sessions module.
  • Diff shows version differences in your site's content.
  • Mollom uses a service to protect your site from spam. If you allow non-admin users to post content on your site, you'll need to do something about spam.
  • Mass Contact allows you to send email to groups of registered users on your site.

Modules for Developers

This section lists modules that are useful primarily while you are trying to build and/or debug a site, modules, and/or themes. Most of these modules should probably be disabled once the site is released, as some of them will slow the site down (and in general, the more modules you have enabled, the slower the site will run, since they all get loaded whenever someone visits any page on your site).

  • Migrate (and its required companion modules) aids in importing content from previous sites and databases. At time of writing, it is not yet an official release; nonetheless, you may find it useful.
  • Devel gives you a lot of options for debugging themes and modules you are creating, including helper functions and on-screen debugging.
  • Coder gives a module developer assistance in adhering to the Drupal coding standards, improving the performance of their modules, and upgrading from version to version of Drupal.
  • Masquerade allows a site administrator to see the site as if they were logged in as another user, and then switch back when they're done.
  • Translation Template Extractor extracts text for internationalization into a POT file.
  • Selenium helps test Drupal web sites, using the open-source Selenium web testing tool. There is also a Simpletest module that assists in setting up unit tests for modules.
  • Demonstration Site (Sandbox) allows you to take a "snapshot" of your site and turn it into a demo site; the demo can be automatically refreshed on a schedule, too. Useful for creating a site to demonstrate a module or theme you have developed.
  • Drush is a command-line and scripting interface to Drupal, which lets you do various Drupal bulk and database operations from the shell. Patterns allows you to submit forms using XML files.

Back to table of contents


Further Reading

Back to table of contents

Comments

Link to the menu handbooks to a secured area.

Menus handbook on drupal.org - this is not accessible to the unwashed masses. I don't have permission to view.

Thanks for a great cheat sheet.

M

Thanks!

Link is fixed - there has been some drupal.org documentation restructuring since I wrote this article... Thanks for letting me know about the broken link!

Thanks for sharing the best presentation of Drupal ever written!

I have been an enthusiast of Drupal for quite a while. I even bought some books! And of course I have browsed drupal.org and the web, but I have never found such a clear explanation of:

a) Drupal's mains concepts;
b) What and how to install (although I think this is the easyest part) and
c) How to organize your: overall site structure, content and roles.

Thanks a lot for sharing!

cheat sheet

very informative and helpful, however I'm assuming based on the content, that the cheat sheet is addressing pre 7 versions of Drupal? I base this on the fact that many of the modules listed are not available or do not work in 7.

Correct...

Yes, this article is Drupal 6. I'll add a note at the top to make it clearer. The concepts are still the same, but the specifics are different.