Choosing Drupal modules

Modules extend the core, or ‘out of box’ abilities and functionality of Drupal. If you can think of a function or use for Drupal which is not included with a basic Drupal installation, chances are there is already a module to fit the bill. One of Drupal’s primary strengths as a CMS is the vibrant, active community development of modules, as well as core functionality.

• Community contributed modules can be found via the web here.
• Register for an account on Drupal.org in order to filter modules by Drupal version
• The ultra friendly and helpful IRC community support can accessed by visiting the #Drupal-support channel on the Freenode network
• Can’t find a module to fit your needs? Make your own!

Now to our tutorial; for our purposes it would be best to walk through an actual example. We’ll use one of the most commonly used modules, Views.

How to add (install) a Drupal module

First we download the module. Here’s how to find a module, and evaluate its stability and quality. Also, how to choose the correct release version.

1.  Navigate to http://Drupal.org/project/Modules
2. Click on the ‘Browse by name’ tab. Loading this tab can take some time, as you will be presented with a list of all contributed Drupal modules. 
3. Scroll down to the section for ‘Views’.
4. Click on the ‘Views’ link to view the full module information page.

Displayed is all the information/links you need to evaluate a module, including: name of maintainer, module description/overview, release versions and a host of support, development and bug/issue tracking links. 

1. First off, you should read all of the description notes for a module; this is the large block of bulleted text below the module name/maintainer’s name. 
2. Next, examine the ‘Releases’ table.

On this table you have the module release version (‘5’ meaning compatible with Drupal 5, ‘.x’ meaning compatible with all versions of Drupal 5, and ‘-1.6’ is the version of Views within the Drupal 5 release), the date of release, the size of the module download, a download link and release notes (notes from individual developers detailing issues dealt with or functionality added).

Here you are presented with two main choices: Drupal 5 or Drupal 4.7. This tutorial is aimed at Drupal 5.x users, so obviously you’ll be more interested in the 5.x-1.6 release. Now, you could just go ahead and get this module via the ‘Download’ link, or you could take another minute to make absolutely sure you know what you’re getting into! So in the spirit of gathering all available, useful information before making a tedious, possibly painful-to-undo decision, we’ll explore this module detail page in a bit more depth.

1.  For the beginner oriented scope of this tutorial we’ll skip the Release notes; Click on the ‘View all releases’ link at the bottom of the ‘Releases’ table.
2. What will load next is long list of all releases of this module, and a list of release notes for each version.

There are many, many releases for the Views module; from 4.6.x-1.x-dev at the very bottom of the page, to 5.x-1.6 and 4.7-1.6, the most recent releases, at the top. One excellent way to judge the quality and stability of a module is to gauge the number of total releases and the amount of time in between releases; this way you can make some very educated guesses at how much use, support and development is going on for a module. If there are only one, or two or three releases, or if development seems to happen once every couple of years or so, then the module is not in active development, which could mean that it is not used due to negative issues and bugs, or there is little demand for the module, so no one really works on it. Choosing modules is sort of like choosing leftovers to eat from the refrigerator; if there’s an old, dusty module found in the back corner of the contributed modules section of Drupal.org, you definitely want to use caution before consuming!

Next we’ll want to take a look at the module issue queue, which is found via a link near the bottom of the module detail page here:

Here is what a module issue queue looks like:

Notice that this page is a list of bugs, problems and incompatibilities involving ‘Views’ module, sorted by the most recently updated. Assessing a module based on this view is similar to an assessment based on analyzing a set of release notes for a module.

You should always go to view all open issues and take a quick look at the queue to see if there are a ton of issues (which may mean it’s either buggy, or more likely very large/complex and popular), or next to none (which usually means it’s new or unpopular), or see if there are any that would be red flags for your particular setup (ie. an issue declaring that this module doesn’t work with another module you’re using). Combining this analysis with the analysis of related release notes can give you a good overall ‘birds eye view’ of whether or not a module, or specific release of a module, is a good match for you installation. Sometimes you just need to install it, to see if it fits your needs and is working properly, but these steps above should give you another tool in evaluating Drupal modules.

Installing Drupal modules

Now that you have a better picture of the development cycle of a module, it’s time to actually pick a release to install.

“Dev,” “stable,” “alpha,” huh?

Module release versions are generally separated into two categories: development and stable. Development releases are, as the name suggests, under active development. This means less stability, but more features. Stable releases are, as the name suggests, the reverse.

Development releases will have the word “dev” in the name as an indicator. You may also see an “alpha”, “beta”, or “release candidate” (RC) version of a module. These are also used to indicate the overall stability and completeness of a module (alpha as least stable to RC as most stable).

Unless you need a specific feature that is in a development release, or need to preview what your site will look in the next stable release, always pick the stable version of a module. The latest release of a module may be a stable or a development one. If it is a development one, the latest stable version may be found by clicking on “view all releases” and searching for the last release not marked “dev”. Note: this page is not always sorted by date so make sure you scroll.

After you’ve located the desired module, you will upload it to the proper place on your server to use it. Two common methods for doing so are with a GUI FTP client and using a direct SSH connection to your server. Both will accomplish the same thing, so it’s merely a matter of using the method that you are more comfortable with. This document go over both methods.

Uploading via FTP

1. Download the file to your own computer. With most browsers, you may right-click on the file link (labeled “views-5.x-1.6.tar.gz” above) and select an option such as “save link as..” to save it locally.
2. Unzip the compressed file using a program such as Winzip into a directory
3. Start an FTP client such as FileZilla
4. You must provide connection information before your client will connect to your site. The screenshot below illustrates the typical fields in an FTP client. The “host” field will contain the domain name that you have set aside for your website. The “username” and “password” fields contain the username and password that you use to access your website.                                                                                                                                                                                                            
5. The section labeled “Local site” represents your own computer. Navigate to the location where you downloaded the module here.    
6. The section labeled “Remote site” represents your website. When connected to a website to a Drupal installation, the file structure will resemble the image shown above.
7. Scroll down to the “sites” folder in the “Remote site” section and enter it. Inside, there will be an “all” folder and a “default” folder. Enter the “default” folder. If it doesn’t exist, create a directory named “modules” and enter it.
8. Drag the decompressed folder containing the module from the local machine over to the “modules” directory. Once you’ve done this, the module will be uploaded to your site.

SSH

An SSH session is less visibly user-friendly than a GUI FTP session. This tutorial will not go over detailed instructions on commandline usage, but will give enough to upload a file.

1. If you have Windows, puTTY is an SSH client that is freely available to you. When you start it up, you’ll be asked for a server, a username, and a password. The server is the domain name of the server you will be connecting to. If you are using Mac OS X, the terminal application is in /Applications/Utilities. The command to begin an SSH session is “ssh username@domain.com”. You’ll then be asked for the password for your server.
2. Once you’ve logged in, you’ll be presented with a command prompt. The “ls” command will give the name of every file in the current working directory. Directories inside this one will either end in a / or will be a different color. You can change directories with the command “cd ” or go back to your initial directory with “cd”. Using these commands, you can explore the directory structure of your site.
3. The top directory for your site will contain an “index.php”. If you can’t find this, you may wish to consult your tech support or webhost help pages.
4. Once you are there, type “ls” and you should see something similar to this (but with a different prompt/directory path)  
5. There are two notable directories here: “modules” and “sites”. The “modules” directory contains the core modules bundled with Drupal. You could put this module here, but it’s somewhat sloppy. The preferred place to put this module is inside the “sites” directory. Type “cd sites” to change into that directory. Inside this directory, there is an “all” directory and a “default” directory. Go into the “default” directory.
6. If it doesn’t already exist, make a directory called “modules” here by typing “mkdir modules”. Enter the modules directory by typing “cd modules”. Every module you install should go into this directory.
7. Keep this window open and go to the webpage with the desired module on it. Right-click (or ctrl-click on a mac) on the link and select “copy link” or “copy link address”. Go back to the terminal window, type “wget “ (including the space), and paste the link in. It should look like this: “wget http://ftp.drupal.org/files/projects/views-5.x-1.6.tar.gz"   Press the enter key. The file will then download directly to the server. 
8. There will now be a file that ends in .tar.gz in this directory, which you can see if you “ls” once.  
9. This file contains the entire module and must be decompressed before it can be used. To dcompress it, type in “tar -xzvf “ followed by the name of the file. The screen will then look like the following image, which displays all of the files that are being uncompressed.
10. Once you’ve done this, the module’s files will be uploaded to your site.

Enabling modules

Before the files can be used by your site, the module must be enabled.

1. The standard location for a Drupal site’s module administration page is “[sitename]/admin/build/modules”. Enter that in your browser and you will go to it.     
2. This page is where modules are listed and managed. There are two tabs to this page: “List” and “Uninstall”. For the moment, we’ll just be dealing with the “List” tab. This page contains all the modules that are currently installed. Scroll down the list, and you’ll find a series of them that begin with “Views”
3. Note that “Views” is both checked and greyed out. Modules can be interdependent. They may rely on other modules’ functionality in order to run. The modules labeled “required by” are modules that require this module to be enabled for functionality. They themselves must be disabled before this module can be disabled or removed. The modules labeled “Depends on” are modules that this module depends on. This module must be disabled before they can be disabled or removed. In this case, the Views module can’t be disabled until Location Views and Views Panes are disabled first.
4. Enable the other modules in the Views section by clicking on the checkbox and clicking on “Save Configuration”. Once the page has refreshed, you should see a screen that looks like this screenshot. The green text will notify you that you successfully enabled the modules. The exact text may be different depending on the modules you enable.                                                                                                                        
5. If you forget to enable a required module, Drupal will notify you of this gracefully. It will also allow you to enable the required module from the notification message. Read the notifications and enable the desired modules.                                                         
6. If the module is not installed, red text will appear notifying you so. If this appears, you must install that module first before enabling the one you want.

Using Panels 2

Now that the Panels 2 module is in beta and relatively stable, there is an important decision new site owners or developers need to make -- should I build my site using Panels or not?

There are pros and cons to each.

With Panels, you gain greater flexibility and power over your content, including the ability to place blocks in multiple areas, create custom per-page layouts, and customize the layout of node add/edit forms. All of this can also be done through an administrative interface right on your site. The major downside is that this is a large, complex module with a learning curve that also carries a performance hit unless you export the panels to a module.

Our themes come with additional styling and a custom TNT panel layout, if you choose to work with Panels.