Skip to main content

Blog Post

A Guide to Drupal Module Evaluation

by Jay Callicott
March 19, 2019

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 MetatagMaintained by Mediacurrent, this module provides a flexible system for customizing the meta tags used on a website.

Metatag page on Drupal.org

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.

 

module usage

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.

issue queue activity

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

Drupal.org security advisory

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.

index: metatag

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.

Metatag module release status 8.x

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.

commits for Metatag

7. Project information

The maintainer will indicate whether a project is actively maintained, minimally maintained, obsolete, or abandoned. Obsolete projects are immediately disqualified.  

project information

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 and problems or the remove of the module 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.

Meet team member, Jay Callicott

Jay is an engineer and leader with a passion for creating technical solutions that solve real-world problems. As a long-time advocate for Drupal and Open Source, he has spent over a decade speaking, writing, and developing enterprise solutions that advance Open Source worldwide.

Since 2009, Jay has worked in a variety of roles for Mediacurrent. For the first 6 years, he focused his efforts on perfecting his craft as an engineer. From Drupal consultant to Senior Developer, then Lead Architect, Jay created solutions and led teams that delivered dozens of enterprise websites.

In 2015, Jay was promoted to Director of Development where he was tasked with hiring developer talent and implementing processes and best practices for the team. Jay also split his time as a lead architect, launching several large projects during this period.

A few years later, Jay moved into his current role as VP of Technical Operations. Jay’s primary responsibilities are working with the revenue team to acquire and retain customers, overseeing Security, DevOps, and IT roles, and leading Mediacurrent’s technology vision. He also helps lead the development of tools and solutions, including the Rain distribution, which won Acquia’s “Open Source Giants” award in 2019.

Currently, Jay is a big proponent of decoupled architecture and the JAMStack approach to web development. Read more about Jay’s thoughts in “The State of Drupal in 2019

Learn more about Jay >

Related Insights