One of the challenges with an extensible platform like Drupal is the sheer number (tens of thousands) of available modules can be a daunting task to evaluate which ones are the best fit for your application. Every year, I have posted a round-up of the top modules to help steer newcomers to a vetted list of essential contributed modules. This article will go a step further by offering guidelines to help your project team assemble modules that meet your organization’s needs.
Methodology
There are many criteria to consider when evaluating Drupal community projects. Each factor is not weighted the same and very few should be considered in isolation. Before reviewing the list below, it’s important to assess your organization’s risk profile.
For example, an agency with full-time Drupal developers is going to be able to provide upstream support for modules in the form of patching and other improvements. As a result, modules that might have otherwise been disqualified could be supported in a way that mitigates risk. Many smaller organizations, however, might want to steer more towards stable, vetted projects. Doing so will ease the maintenance burden over time.
Example Project Page
Say, for example, you are evaluating Metatag. Maintained by Mediacurrent, this module provides a flexible system for customizing the meta tags used on a website.
Evaluation criteria
1. Module Usage
The project page will show downloads and site usage. Usage can be viewed by version (ie Drupal 6, 7, 8) and is weighted higher than download counts. Low usage of a few hundred sites, or less, would likely disqualify a project.
2. Issue Queue Activity
The project issue queue will indicate the level of activity and number of bugs including critical issues and issues flagged for security. The volume of bugs is not necessarily a problem in that larger projects will have more issues reported. The severity of bugs should be considered as well as the overall activity. Projects with only a handful of open issues logged should be considered as a higher risk. Projects with frequent issue updates and patches are considered lower risk.
3. Security
The Drupal community has a dedicated security team to review projects for potential security vulnerabilities. Each module maintainer has to “opt-in” to receive security coverage and must have a stable release available. Projects that have not opted into security coverage do add risk, which needs to be considered. Check out our blog for more ways to assess modules for security.
4. Manual Review and Testing
If possible, have developers spot check module code. Look for red flags in terms of code styling, organization and general adherence to Drupal.org best practices. Additionally, even after a module has been preliminarily screened it should be further evaluated when installed and configured. If the module appears buggy, unstable, or does not appear to fit the project needs, it might need to be replaced with an alternative solution.
5. Release Status
The release status is solely managed by the project maintainers’ and does not fully indicate the stability of the module. The release version is a factor in that it indicates the project maintainers’ assessment of stability. There is no governing model for how releases are labeled. Projects could have 1.0 stable releases and have outstanding security bugs or critical issues while development or sandbox modules can sometimes be production ready. It is important to consider other factors before making a final judgment. Modules with dev releases should be further scrutinized and vetted, including a more exhaustive manual code review. Alternatives should be evaluated. It should be noted that a sandbox module in some cases will still be advantageous to a fully custom coded alternative.
6. Commit Activity
Project code updates and the frequency of stable releases are highly weighted. Projects without commits in 6+ months are considered higher risk. Frequent project updates and releases are a good indicator of stability and support.
7. Project information
The maintainer will indicate whether a project is actively maintained, minimally maintained, obsolete, or abandoned. Obsolete projects are immediately disqualified.
8. Risk Assessment
The size and scope of the module’s functionality should be very strongly weighted. A module that has very few lines of code and adds simply functionality, e.g. a block on a page, is considered relatively low risk. A module that manipulates data in any way is higher risk. Problems or the module's removal could result in data corruption or loss. A module that provides critical functionality to a project will be evaluated much more deeply than a module that provides marginal benefit.
9. Benefit
Modules should be evaluated based on their fit for the project. Every module added to a project generates some level of risk in terms of stability, security, maintenance overhead, etc. Therefore, inclusion depends on the demonstration of benefit.
Your Feedback
Have any suggestions or feedback? Talk to me at https://twitter.com/drupalninja or use the comments below. We are always looking to make improvements to our processes.
.webp)