With over 10,000 modules to choose from, and more added every single day, finding the contributed module you need for a given task can be a daunting process. Throughout this book, we have endeavored to highlight and identify most of the “must-have” modules, particularly architectural modules that are commonly used to build Drupal websites. We’ve also endeavored to cover modules that have a proven track record and are likely to continue to be used to build sites.
However, each new website project has unique requirements that may be outside the scope of what this book has covered, and the landscape of available contributed projects is a constantly shifting space. Modules that were once critical building blocks may be abandoned or deprecated by superior alternatives, and new modules may come along that completely blow away anything else that came before them.
This appendix, therefore, attempts to highlight some of the best practices used by those “in the know” for evaluating and selecting the right module for the job. It’s important to keep in mind that no simple set of guidelines—these included—can tell you everything about a module. The important thing to remember is that evaluating modules carefully before you commit to them will help prevent unpleasant surprises down the road.
The first step to choosing the right module for your needs is actually finding it. Fortunately, all Drupal modules (with only a few rare exceptions) are located directly on the main Drupal.org website, so there’s only one resource for finding them. Here’s how you do it.
The main module listing page at http://drupal.org/project/modules, and pictured in Figure B-1, lists all of the available modules and sorts them so that the most popular modules (based on the number of active installations) are listed at the top. If the module you want to use is on the first few pages of this listing, you’re in good company. You can narrow this huge list by using the variety of filters at the top of the page. You can see a list of all the categories for modules at http://drupal.org/project/modules/categories.
Warning
Drupal 6.x modules are not compatible with Drupal 7.x, and vice versa. To see an accurate list for your site, make sure to change the “Filter by compatibility” filter to show only those modules that are compatible with your Drupal version.
Note
Another nice Drupal.org “hack” is keeping an RSS reader pointed at http://drupal.org/taxonomy/term/14/0/feed, which is a list of all the newest modules on Drupal.org as they are created. You can see this listing in the regular module browser by changing the default sort order from “Most installed” to “Date.”
Drupal.org also provides several places for searching the downloads on the site, also shown in Figure B-1. There is a search box directly on the module page, and the main site search box also provides an option for you to limit your search to just modules by clicking the “Refine your search” link, then selecting modules from the options. Searching by keyword allows you to drill down to modules specific to your needs faster than browsing by the default category view.
http://groups.drupal.org/ is a collaboration space for working groups, event planning groups, and geographical groups. There are over 450 local user groups worldwide listed at http://groups.drupal.org/groups. Many of these groups hold monthly meetups where you can meet other human beings in the “real world” who’ve heard of this “Drupal” thing before. Whether you’re in New York City or the Philippines, attending these meetups can be a great way to learn about new modules and technologies, get help on questions you might have, brainstorm on solutions with others, or just meet friends!
The Similar Module Review group at http://groups.drupal.org/similar-module-review provides posts that perform comprehensive analysis of all modules that overlap in certain areas of functionality. If you want to know which is the best WYSIWYG module to use, or why you’d want to use one sort of voting module over another, this is a great place to look first (and, if the comparison you’re looking for doesn’t exist already, research and contribute your own)!
The Drupal.org support forums at http://drupal.org/forum, particularly the “Before you start” forum at http://drupal.org/forum/20, can provide a wealth of information in the form of questions from other users about the modules they used for their own projects. Often, you can receive some helpful advice not only about the feature you’re trying to implement now, but also for future things your website will need to take into consideration. The “Drupal showcase” forum at http://drupal.org/forum/25 is also filled with people showing off websites they built with Drupal—and they are often more than happy to share details about how they built a particular piece.
Chances are good that no matter how crazy the use case, someone else has had to solve the very same problem with Drupal as you have. You can cut down tremendously the time required to find modules by discovering how that person went about it. The Drupal documentation contains a section for case studies at http://drupal.org/cases. These consist of detailed writeups, often about major websites using Drupal, why Drupal was chosen, and how the site was put together.
Planet Drupal (http://drupal.org/planet), pictured in Figure B-2, is an aggregation of Drupal contributing members’ blogs and is a great way to find out what’s new and hot in the module world. Module tutorials, reviews, and news are often posted there, and Planet Drupal is also a great general resource for keeping your finger on the pulse of what’s happening in the larger community.
http://drupal.org/node/289913 provides a list of third-party websites—that is, separate from Drupal.org—that often provide useful information for evaluating modules. For example, http://drupalmodules.com provides user ratings and reviews of Drupal modules, and http://www.lullabot.com has a variety of articles, videos, and podcasts, many of which highlight popular modules and how to use them.
An open source project’s strength comes from the power of its base of contributors, and the Drupal project is no different. Although every line of code added or changed in Drupal core goes through rigorous peer review, contributed modules are more of a Wild West where anyone who jumps through a few basic hoops can add modules for everyone to download. Drupal strives to keep the barriers to contributing code as low as possible in order to facilitate growing Drupal’s thriving development community. This approach has both pros (for almost any problem, there’s a module that can get you fully or at least partway there) and cons (developers’ experience levels are varied, so contributed code quality is uneven; the code can have inefficiencies and security problems; and developers can become overextended and unable to keep up with maintenance of their modules).
Whether or not a module is well maintained, its overall code quality, and how well used it is in the overall community are all important factors for you to consider when selecting modules. This section will talk about determining these factors by closely inspecting the tools Drupal.org provides, starting with the central feature of all Drupal modules: the project page.
Modules, themes, and even Drupal core itself are all referred to as projects on Drupal.org. Each project has its own page at http://drupal.org/project/project_name, which contains a wealth of information that you can use to evaluate a module’s health.
Figure B-3 shows the first part of a module’s project page. Here you can find the name of the module’s lead maintainer (usually the original author and/or the module’s primary developer), the date the project was first created, some basic project information, a description of what the module does, and sometimes a screenshot showing what the module does. The project information section gives you important information, like whether the project is being actively maintained, and shows the number of reported installations of the module. The usage statistics are helpful to gauge how widely used a module is. A module that only has 50 or 100 sites using it may (or may not) be a good module, but the community support for improvements and troubleshooting will be very limited. The original project creation date can be useful when you are looking for time-tested solutions (if the module was created in the past week, it’s probably best to let it mature a bit before depending on it). But also be aware that some older modules may be legacy solutions that more modern modules deprecate.
The sidebar on the project page contains a lot of useful information as well. Here you will find a full list of up to four of the most recently active maintainers—that is, people who have permission to modify the code—and a search box to do a search within the project’s issue queue. You can also see the number of currently pending issues for this project and a short list of the latest issues that have been updated. Farther down the sidebar is a list of related projects, which is very useful to investigate to make sure you are using the module that best fits your needs. The resources section is an optional list of links, including resources such as a project’s external home page, a link to its documentation, or a demonstration site. The presence of these links tends to indicate a maintainer who is passionate about his module, and wants it to be as high-quality as possible.
Further down, we see the module release table (pictured in Figure B-4), which we discussed briefly in Chapter 2. A plethora of useful information is available here, including the date that the code was last updated; whether the module has “Recommended releases,” which indicate stable releases that the maintainer recommends for use; links to release notes for each release to tell what bugs were fixed and features were added; and a link to view all releases—even old, outdated ones.
The release table in Figure B-4, taken from the Organic Groups module on May 1, 2011, is indicative of a healthy project. The module has stable releases for both Drupal 6 and Drupal 7. The date on the module’s development releases indicates that the code has been updated very recently, which means that the maintainer is actively developing on the project. Clicking on “View all releases” shows releases of this module dating back to Drupal 4.7.
Here are some signs to look for on a project page that indicate it might be worth searching elsewhere:
If there are only development snapshots available and no recommended releases, or if there is no release table at all, this indicates that this module is undergoing development and should not yet be relied upon for production websites.
If the last updated date of the latest release (or at least the development release) is more than several months in the past, this could indicate lack of maintainer activity and interest in the module. It could also mean that you’ve found an example of a completely perfect module that has no bugs and needs no new features added (it’s extremely rare, but it happens), so you should investigate the module a little more to determine if this is a positive or negative indicator.
Development of code in the Drupal community happens in a project’s issue queue, such as http://drupal.org/project/issues/3060, pictured in Figure B-5. The issue queue is a log of bugs, feature requests, support requests, and tasks for a given project that module maintainers use as their public working space. Anyone in the community can log issues against a project, and anyone can provide solutions for them as well.
You can find an issue queue for a project in several ways. The most common way is simply to start on the project’s page. If you look in the sidebar, you will see an “Issues for Project Name” section, which has a quick search box and some links to the current issues. You can also look at the main list of all issues across all projects at http://drupal.org/project/issues, and use the Project box to select the project you’re interested in.
Because issue queues provide an open window into what’s happening with development of a given project, being able to “read” an issue queue is an invaluable skill in evaluating a project’s health.
For example, most people might logically assume that a project with lots of issues is a poor-quality project, and one with very few issues is a high-quality project. While this certainly can be the case, it’s worth pointing out that Drupal itself currently has more than 5,000 open issues, and its code is written to a very high standard of quality. More often than not, the number of issues in an issue queue indicates the popularity of a project, not necessarily a lack of quality.
That said, the specific details of said issues are very important. In Figure B-5, we see a number of things that indicate an overall healthy project. There is an issue that has been marked “fixed” within the past 24 hours. Several of the open issues have code associated with them in one way or another: one that is ready for larger community review, one that has been fixed in the current version and is ready to be back-ported to Drupal 6, and one that has been reviewed and is waiting to be committed to the code. This is indicative of a healthy developer community around the project. Only two of these issues are marked “active,” which indicates that they are still awaiting code to fix them.
Figure B-6 shows a different story. This is the issue queue from the Flexinode module, which was the predecessor to the current Field feature of Drupal core. At first glance, it looks similar to the Drupal issue queue that we saw earlier. Sure, there are a few more “active” issues, and none that are currently marked as having been fixed, but what’s the problem?
The problem is the “Last updated” column, which indicates when a reply was last posted to the issue. In the Drupal project issue queue, shown in Figure B-5, replies are typically at most an hour or two apart, with some replies as recent as eight minutes ago! This means that at almost any given hour, people from all over the world are constantly contributing to the project. However, the last time that anyone responded to Flexinode’s most recent issue was over a year ago. This is a sure sign of an abandoned module whose maintainer has lost interest.
Most modules are somewhere in between these two extremes, with a mix of issues that haven’t been looked at in a while and those that have more activity. Spot-check a couple of issues by clicking them and seeing who’s actually responding. Is it the maintainer, specifying what she found when she looked at the problem, or is it other desperate users who are saying, “I have this problem too. Help!”
All of Drupal’s contributed modules are stored in a central code repository. You can browse a project’s repository by clicking on the “Repository viewer” link on the project page, located in the bottom sidebar under the Development section. Once there, you’ll see a code browser page, as pictured in Figure B-7. Scroll to the list of “heads” (the code that development releases come from) at the bottom to find the version you wish to look at, and then click the “tree” link page to see the list of files to browse for that version. Obviously, people with a PHP background are going to be able to get more out of this, but in general anyone can spot some basic best practices. Look for clearly written, documented, well-organized code that conforms to a standard coding style. Code that does not meet these criteria is harder to maintain, and harder for other developers to jump in and help with.
Each contributor to Drupal is a unique individual who has his or her own areas of interest, expertise, background, and motivations for contributing. Some contributors are master programmers who live, breathe, sleep, and eat code. Some are backed by Drupal development and consulting companies, and are paid to maintain their modules. Others are hobbyists who run a fan club site and maintain one or two particular modules that act as the main backbone of their community. Still others help out for the fun of it, because it feels good and they enjoy it. There are those who get code as far as they need it, toss it out there, and move on to bigger and greener pastures. And, of course, there are those who are some, all, or none of the above.
Therefore, a critical piece to evaluating a module is to also learn more about the humans behind the code. Drupal.org has a few useful tools to help.
The first is the “View all committers” link in the project page sidebar (for example, http://drupal.org/node/3060/committers), which takes you to a table, shown in Figure B-8, displaying a list of the individual developers who are maintaining (or have maintained) the project. The data shown here are the commits, or code changes to a project, by everyone who has ever had access.
From this information, you can get a general idea of who within the project has been working on it the longest, how active each contributor is, and how much experience each has with a given project’s code. A sign of a good, healthy project is lots of recent commit activity, along with numerous contributors in the list if some of the original folks are no longer around. If this list is small, and the last commit was more than several months ago—and particularly if the project’s issue queue shows warning signs—it may be worth looking for alternative solutions, or perhaps offering the maintainer payment for the changes you need in order to help spark her interest again.
Anytime you see a username on Drupal.org, you can click it to view the user’s profile (for example, http://drupal.org/user/35821), as shown in Figure B-9. Although there’s information here that’s typical of any user profile on any site—such as first and last name, a list of interests, gender, and country—there are a few elements that are particularly useful if you’re looking to find out more about the person behind the code.
The user profile begins with a brief blurb about the user’s contributions to Drupal. This typically mentions modules that he has written, various initiatives that he’s a part of (such as the documentation team or site administration team), and other such data. This information can help provide insight into the person’s motivations and background.
This information is followed by a series of “flags” that indicate things such as whether the person helps out with documentation, user support, and module development, as well as what Drupal conferences he has attended. Each flag is a link that displays a list of other users who have that flag checked. A user with many of these links displayed is generally much more tied into the larger Drupal community than one without.
The tabs at the top of the profile are useful as well. The Posts tab shows a list of all of the posts on Drupal.org that the user has created or responded to, including forums and issue queues. This can help gauge his overall involvement in the Drupal community and how active he is, as well as his general attitude toward others. The Commits tab is a list of the person’s code commits so you can quickly take a peek at the kind of code he has committed.
The Contact link, if it’s enabled, can be used to contact the contributor directly via email.
Warning
Although it can be tempting to use the Contact form to ask maintainers support questions or to report bugs about their modules directly, this is considered bad form. Time a maintainer spends answering emails is time that is not spent further developing the module and helping other users who might have the same problem.
Always use a module’s issue queue for reporting problems, as that method allows anyone who uses the module to respond, not just the maintainer, and allows the results to be searched by others. In general, use a maintainer’s contact form only for topics that are intended to be kept private, such as requests for hire.
Note that the contact form can also be used to send a general “thanks” for a job well done; most module developers hear only about problems from their users, so it can make a maintainer’s day to hear from someone who has nice things to say about the code she received for free.
Figure B-10. Drupal developers have a list of projects they’ve committed to at the bottom of their user profiles
Further down the profile page, there’s an indication of how long the user has been a member of Drupal.org, as well as a list of the projects that the user has committed code to during that time, shown in Figure B-10. Some maintainers have 1 or 2 projects listed here, and others have 50 or more. A list consisting of many projects is usually indicative of someone who’s been around awhile and likely knows what he’s doing. On the other hand, because he has been around awhile, he might also be overextended and trying to do too many things at once, and all of his modules may be suffering as a result.
By far, the best way to keep up-to-date on which modules are the most useful, and to ensure that those modules do what you need, is to actually get directly involved and help. The Drupal community offers a myriad of ways for everyone, from the person who just installed Drupal for the first time yesterday to the person who has been coding since she was in diapers, to give something back.
The Getting Involved handbook at http://drupal.org/getting-involved-guide is the main jumping-off point for ways to get involved in the Drupal project. Here are a few that are suited to nonprogrammers as well:
- Issue queue cleanup
While you’re evaluating modules, you’ll naturally be in the issue queue anyway. Why not take a few extra minutes and look for places you might be able to clean things up? If there are two or more similar issues, mark the higher-numbered one as a “duplicate.” See if a bug report is still valid, and if it’s not, mark it “fixed.” If you see a support request that you know the answer to, answer it. Every minute spent by someone other than the module maintainer on this type of activity is more time that she can spend improving her modules, and so this type of contribution is hugely appreciated by maintainers.
- Helping with user support
If you’ve gotten as far as getting Drupal installed, congratulations! You now officially know enough to help someone else. Head to the Drupal forums or #drupal-support on irc.freenode.net and look for opportunities to answer other users’ questions. You’re guaranteed to learn a ton in the process, and might end up with a job!
- Filing issues
If you come across a problem with a module, or something that you think would be really cool, file it as a detailed bug report or feature request in the module’s issue queue using the guidelines at http://drupal.org/node/317. Remember to search using the search box and filters at the top of the issue queue first to check for an existing issue before creating one of your own.
- Documentation
Did you just spend a frustrating half hour on something because there was a lack of documentation or an error in the existing documentation? Edit the page with your corrections, so that you can spare the next person the same fate. You can also join the documentation team at http://drupal.org/contribute/documentation/join to collaborate with others on the overall direction of Drupal’s documentation.
- Donations
Don’t have time to contribute yourself, but have some spare change rolling around? You can donate to the Drupal Association, the legal entity that provides server infrastructure, organizes Drupal conferences, and handles fundraising for the Drupal project at http://association.drupal.org/donate. Many individual developers also gladly accept donations. If using someone’s module has helped save you some money, give them a little back to say thanks.
Why get involved? Aside from the warm fuzzy feeling, there are a number of practical reasons, which include:
As a general rule, more attention is paid to your support requests, bug reports, and feature requests if you are known to be a contributor to the project.
Being an active part of the community helps forge relationships, which can lead to clients and employers.
Being involved can help take months off of your Drupal learning curve by exposing you to discussions and individuals that you wouldn’t otherwise have come across.
You can help shape the exact direction of modules and even the Drupal core itself, so that they meet the requirements for your project.
It’s also really fun! You meet people from all over the world, and get to learn from some of the best and brightest minds out there on web design.
The tips and techniques outlined in this chapter can help identify must-have modules long after this book is out of date. By assessing things such as how active a project’s maintainer is, how large the user community is around a project, and how well documented and easy to read its code is, you can help make smart, future-proof choices on your module selection. And by getting involved directly in the community itself, you can meet the awesome people who make Drupal what it is, and become one of them yourself!
Here is a list of the resources referred to in this appendix:
Bug report and feature request guidelines (http://drupal.org/node/317)
Case studies (http://drupal.org/cases)
Contribute page (http://drupal.org/contribute)
Contributed module list (http://drupal.org/project/Modules)
Developers list for the Drupal project (http://drupal.org/node/3060/committers)
Documentation team (http://drupal.org/contribute/documentation/join)
Donate money (http://association.drupal.org/donate)
Drupal core project issue queue (http://drupal.org/project/issues/drupal)
Drupal.org forums (http://drupal.org/forum)
Drupal “Before You Start” forum (http://drupal.org/forum/20)
Drupal showcase forum (http://drupal.org/forum/25)
Planet Drupal (http://drupal.org/planet)
Third-party resources (http://drupal.org/node/289913)