At the time of writing, Drupal has 31,072 modules available. Whenever you need to do something, there’s a module for that. Choosing which modules to include in a project, and at which point to make something custom, is very important in a site. More modules mean that there’s more to keep up to date and test. Conversely, less modules may mean re-inventing the wheel.
The following are some thoughts and insights around the process we go through in choosing modules, and at what point we decide to write our own.
Firstly, there are some go-to modules: Views (only until D8!), Context, Transliteration and so on. These will be used in all projects and are in the install profile we use, so they’re always available.
When it comes to needing extra functionality, a Google search will usually bring up a module or two. I will also take a look at the drupal.org project page, and consider the following:
Is it well written, does it clearly explain what the module does?
If project owners have taken the time to create a good project page, it’s likely they’ve put effort into the module too.
Does the project have a stable release?
Always avoid in-development modules for production (unless absolutely necessary!) - I prefer to skip alpha/beta/release candidates too, but a lot of modules seem to stay at those release versions.
When was the last release - both stable, and to dev?
If the module has recent commits to both, it’s under active development. It’s likely issues are being worked on & committed, and new functionality may be added. Modules that haven’t been committed to for a long time are likely to be unsupported.
How many issues are in the issue queue, both open and closed?
A large number of issues suggests a lot of people are using it, so issues are going to be found and (hopefully) fixed. A glance over the issue queue can show any incompatibilities or things to be aware of before using the module.
Does it list any related modules, and how it compares/differs?
Check out the related modules, incase they offer more suitable functionality.
I also like to use simplytest.me to try out new modules. It’s a great way to quickly see what it does and if it’s likely to fit your needs.
Once I’ve decided a module is a good candidate, I’ll open it up. What’s the readme file like if present? Does it have a documented API?
What about if a module *almost* provides the required functionality, or provides too much? Providing too much functionality is a concern in that it could impact performance unnecessarily, or provide a confusing interface for end users.
If it doesn’t quite do what’s needed, could it be patched & contributed back, or does it provide hooks that can help?
If it’s too much, are there elements of the code that could be copied to a custom module that just does the bare minimum? Could you use functionality from other modules to achieve the same result?
A real world example
For a recent project, we needed to be able to send private messages between organic groups. According to our brief, these messages could be replied to and there was also the possibility of sending a message to many groups.
The user experience for this was very important - creating, viewing & replying to messages needed to be simple. We always put the UX first wherever we can.
I took a look at the message stack, and the message private module which added organic groups support. After turning the modules on, I quickly realised that the module didn’t provide the functionality I needed, nor the user interface I desired. It provided a lot of functionality I didn’t need too - with this project most traffic will be logged in, so it was critical to keep the site lean and mean.
Rather than start from scratch, I considered what options there were to achieve the result I was after.
In the end, I used the ECK module to create a custom message entity. This had two organic group reference fields. One for whom the message was from, and one for whom the message was to. I planned to use comments for the message replies, but discovered that core comments aren’t supported on custom entities. As stated earlier, there’s usually a module for whatever you need & the reply module came to the rescue in this case.
So instead of having several messaging modules & their dependencies, I achieved the same result using two different modules - one of which was already in use on the project (ECK).