However, each new website project has unique requirements that may be outside the scope of what this book has covered, and the landscape of the contributions repository 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.
Browse Module Listings
The module listing pages at http://drupal.org/project/Modules, pictured in the image below, "Module browse pages on Drupal.org", list modules by category (such as CCK or mail-related modules), by name alphabetically, and by the date they were last updated. Browsing these category-based pages can be useful for determining the modules that exist in a particular space, and keeping an eye on the modules that are frequently at the top of the date list helps highlight those with active maintainers.
Warning: Drupal 5.x modules are not compatible with Drupal 6.x, and vice versa. To see an accurate list for your site, make sure to change the "Filter by Drupal Core compatibility" filter to show only those modules that are compatible with your Drupal version. You will have access to apply this filter only if you are logged in to the Drupal.org website. Getting an account is free and easy, and opens up many useful tools to you.
Module browse pages on Drupal.org
Note: Another nice Drupal.org "hack" is keeping an RSS reader pointed at http://drupal.org/taxonomy/term/14, which is a list of all the newest modules on Drupal.org as they are created.
Drupal.org also provides a block for searching the downloads on the site, also pictured in the image above, "Module browse pages on Drupal.org". For example, searching for "wiki" brings up a list of modules with that keyword in their name or description. This allows you to drill down to modules specific to your needs faster than browsing by the default category view.
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 the time required to find modules tremendously by finding out how they went about it. The Drupal handbook contains a section for case studies at http://drupal.org/cases. These consist of detailed write-ups, often about major websites using Drupal, about why exactly Drupal was chosen and how the site was put together. Some of the more comprehensive case studies include:
- Popular Science magazine: http://drupal.org/node/233090
- Sony BMG MyPlay: http://drupal.org/node/241344
- New York Observer: http://drupal.org/node/141187
Planet Drupal, pictured in the image below, "Planet Drupal, which aggregates content from blogs of Drupal companies and contributors", 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 also a great general resource for keeping your finger on the pulse of what's happening in the larger community.
Planet Drupal, which aggregates content from blogs of Drupal companies and contributors
http://drupal.org/node/289913 provides a list of third-party websites - that is, separate from Drupal.org - that often provide useful information when 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.
Assessing a Module's Health
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. The Drupal community strives to keep the barriers to contributing code back 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 either can get you fully or at least partway there) and cons (developers' experience levels are varied, so contributed 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 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, translations, 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/file_name, which contains a wealth of information that can be used to evaluate a module's health.
The image below, "The project page for the Devel module" shows the first part of a module's project page. Here you can find the name of the module's maintainer (usually the original author and/or the module's primary developer), the date the project was first created, a description of what the module does, and sometimes a screenshot showing what the module does.
The project page for the Devel module
The original project creation date can be useful when 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.
Further down, we see the module release table (pictured in the image below, "The module release table for a typical module"). A plethora of useful information is available here, including the date that the code was last updated; whether the module has "Official releases," which indicate stable releases; 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 module release table for a typical module
This release table, taken from the Date module on September 7, 2008, is indicative of a healthy project. The Date module has stable releases for both Drupal 5 and Drupal 6 (although the Drupal 6 version is only a release candidate, this shows that it is nearing completion and ready for testing). 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, and it even has a Drupal 7 development release, although Drupal 7 is currently in active development and is not close to being released yet, as of the current date.
On the other hand, signs that it might be worth looking elsewhere include:
- If there are only development snapshots available and no official 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 is 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, but those are pretty rare.
Finally, at the bottom of the project page 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. 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.
Also, don't miss the project's usage statistics, which are invaluable in evaluating the popularity of a module in relation to others.
Development of code in the Drupal community happens in a project's issue queue, such as http://drupal.org/project/issues/3060, pictured in the image below, "The issue queue from the Drupal core, an example of a healthy project". 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.
The issue queue from the Drupal core, an example of a healthy project
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 scroll to the bottom, you will see a list of links for support, features, etc. The handiest link in that list is the "View open issues" link under the Support section. You can also look at the main list of all issues across all projects at http://drupal.org/project/issues, and use the Project drop-down list 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 merely indicates the popularity of a project, not necessarily a lack of quality.
That said, the specific details of said issues are very important. In the image above, "The issue queue from the Drupal core, an example of a healthy project", we see a number of things that indicate an overall healthy project. There are a couple of issues that have been marked fixed within the past 24 hours. Two of the issues are also assigned to developers, which normally indicates that they are taking responsibility to find solutions for the problems. Most of the open issues have code associated with them in one way or another: a couple that are ready for larger community review, and one that still needs more work, but is at least the start of a solution. 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.
The image below, "The issue queue from Flexinode, an example of a project that has been abandoned" shows a different story. This is the issue queue from the Flexinode module, which was the predecessor to the current CCK module. 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 there are still a few issues that have some code attached, and even some that are assigned to developers. So 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 the image above, "The issue queue from the Drupal core, an example of a healthy project", 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 18 weeks ago, and for most issues, over one 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 awhile 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, "Yep, I have this problem too. Any ideas?"
The issue queue from Flexinode, an example of a project that has been abandoned
All of Drupal's contributed modules are stored in a central code repository at http://cvs.drupal.or...utions/modules/, which you can browse through in order to get a sense of how the code looks for a given module prior to downloading it. 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.
The People Behind the Code
Each contributor to Drupal is a unique individual who has his 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 "Developers" link at the bottom of project pages (for example, http://drupal.org/pr...developers/3060), which takes you to a table, shown in the , "A list of developers for the Drupal project, along with commit activity", 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 several months ago, 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 entice her interest again.
A list of developers for the Drupal project, along with commit activity
Anytime that 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 the image below, "User profile page on Drupal.org". 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 to those 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 they have written, various initiatives that the user's a part of, such as the documentation team or site administration team, and other such data. This information can help provide insight as to the person's motivations and background.
User profile page on Drupal.org
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 the user 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 along the top edge are also very useful. The Track tab shows a list of all of the posts on Drupal.org that the user has created or responded to. This can help gauge his overall involvement in the Drupal community and how active he is, as well as his general attitude towards others.
The Contact tab, if he's enabled it, can be used to contact the user 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: 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.
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 the image above, "Drupal developers have a list of projects they've committed to at the bottom of their user profiles". Some maintainers have one or two 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 over-extended 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 what 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 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.
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 click on the "Advanced search" link at the top of the
issue queue first to check for an existing issue before creating one of your own.
Did you just get done spending 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 your same fate. You can also join the documentation team at http://drupal.org/co...umentation/join to collaborate with others on the overall direction of Drupal's documentation.
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.
Looking forward to meeting you on Drupal.org!
Learn more about this topic from Using Drupal.
With the recipes in this book, you can take full advantage of the vast collection of community-contributed modules that make the Drupal web framework useful and unique. You'll get the information you need about how to combine modules in interesting ways (with a minimum of code-wrangling) to develop a variety of community-driven websites -- including a wiki, publishing workflow site, photo gallery, product review site, online store, user group site, and more.