Skip to main content
Hero Background Image

A Guide to Drupal Module Evaluation

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.


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

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 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 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. 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 or use the comments below. We are always looking to make improvements to our processes.

Related Insights

  • Blog from the Mediacurrent Team

    Best Practices for Custom Drupal Modules Hollow right arrow icon

  • Headshot
  • Headshot
    Blog from Jay Callicott

    The State of Drupal in 2019 Hollow right arrow icon