In the previous posts we’ve focused on defining your requirements and the basics of searching for modules. Once you’ve found a Drupal project you’re interested in, now you can make a quick evaluation of the project to determine if you should dig deeper before you test it out.
Evaluation Criteria
Each module you select and install on your site must be maintained. There will be security updates, feature improvements and bug fixes offered on a rolling basis. The update manager within Drupal will notify you when new releases are available. This means you will never miss a key security release.
If a module is actively maintained it will mean that one aspect of your site is more likely to be secure and bug-free. One less thing to worry about! Take a “maintenance first” approach to module selection to limit potential issues arising from compatibility issues or security issues that might arise.
An initial evaluation is something an experienced Drupal developer might do in about one to two minutes, simply to compare two modules to decide which to download and try first. However, let’s tease this apart. There are three useful criteria for evaluating a module.
- Reputation: How many maintainers? What other contributions have the maintainers made? Is the individual or company a member of the Drupal Association?
- Reach: Is there a community around the module? Are there related modules which integrate with it? What is the total number of installations? Checking the usage over time is there a stable arc?
- Currency: Have there been recent commits? Are issues being added by users? Is the maintainer responding? Is there a stable (green/not alpha or beta) release available?
These criteria can give you some indication of the level of effort that is being invested in maintaining the software, and help you interpret information on the project page.
The Project Page
You can determine how a project scores against those criteria based on the information available on the project page itself. A wealth of information is available.
- Description: This should provide some basic information about the project and you should be able to tell what requirements the module has.
- Project information: Maintenance status and how many reported installations. Just because only two others use a project, doesn’t mean it’s not a good start for a solution for your team.
- Downloads: Is there a compatible version available? If it's not recently updated it might be a warning sign, or it might just be a stable, well-used module that just works.
- Maintainers: Is there an active team of maintainers? You can look at their profiles which also list other contributions and activities.
- What are current issues? The graphs indicate recent activity and also a brief analysis of how responsive the maintenance team is. Keep in mind most of this work is done on a voluntary basis, so if you’re willing to help out, you can often get a better response.
- Is documentation available? This will help you in the next step of testing and exploring the module.
The project information provided should be considered in relation to the other information. For example, you might see a project like Bean doesn’t have a Drupal 8 version. This might make you wonder if the solution is future-friendly. In this case, similar functionality has been incorporated into Drupal 8, so it actually makes this module unnecessary.
To give another example, a project with few installations could be just that unique solution you need to connect your Drupal site to an obscure third party application. And as another example, a project managed by a Drupal newcomer who has few contributions could be a great sign that someone is bringing in new skills and experience to the community.
I would never disparage or dismiss a project based on just one of the criteria. Make sure you look at each aspect of the project and balance it with the rest of the information available.
How can I help?
OK, now we’ve whittled down our choices and found a module or two we’d like to try out. In the next blog post, we’ll actually install and test out a module. After that, I’ll show you how to explore and “learn” a new module.
In our Drupal Site Building course we focus on the essential building blocks of Drupal and contributed modules. In fact, some of the contributed modules we use in the Drupal 7 course have become core in Drupal 8, which is a good sign that the community has convened around specific requirements and solutions.
If you’re stuck trying to find a module for X, please leave a comment and I’ll help you find the module you’re looking for.
