Finding the Right Drupal Module for Your Needs

Finding the right module to use is not always easy. Every time I need to add features to a project I use these questions before I test the module myself:

1. Is the module actively maintained?
2. How does the issue queue look?
   1. How many open issues are there?
   2. How quickly are bugs being fixed?
3. How well is it documented?
4. What dependencies does it have, both required and optional?
5. Are there any known incompatibilities with other modules?
6. Does the module add complexity to other parts of the website?

I don't particularly pay much attention to the statistics about how many are using the module. Reason for this is that most live sites turns of the update module and thus are not reflected in that statistics.

Questions 1-3 are pretty straightforward and I'm sure they are on your list as well. Therefore I will focus on the last three in my list.

3 - What dependencies does it have, both required and optional?

For me, this question has become more and more important. Even though dependencies can be both good and bad, I have found that when it comes to Drupal they are generally good.

When a module depends, required or optional, on other modules it means that the maintainer has done the homework. Instead of adding all the needed functionality to their own module they have researched what already exists and opted to use that instead. Then they leverage on work by other developers and can instead focus on the core functionality of their own module.

A great example of this is the Node Limit Number module that I wrote about in this post a few days ago. Instead of adding its own UI and code for configuration, it leverages on the Rules module. Not only does this end up with a much smaller module, but it also gives it much more flexibility. With the integration with rules I am now able to use it in ways the author didn't think of. Without that integration I would have either been forced to write a patch, or make a feature request for it hoping the author finds my idea appealing enough to spend his own time to add it.

Big modules such as Views, CCK (now in Drupal 7 Core), Panels, Rules, Display Suite and others offers well documented API's making possible to quickly develop small sub modules that focuses on solving single tasks.

Since many of those big modules are used on a majority of Drupal websites, it will result in many benefits, such as:

• Smaller code base
• Higher quality of the code
• Less maintenance
• Less administration
• Easier to implement
• Greater flexibility
• Easier to use

All things we love to have since we can then spend our time where it is better used.

5 - Are there any known incompatibilities with other modules?

Luckily this is not a very big issue in the Drupal community compared to other open source projects. Drupals community have worked very hard, much thanks to Dries Buytaert's great vision and leadership, on guides for how to develop for Drupal as well as the implementation of simpletest on d.o to name two things.

Still, you need to read the documentation, and check the issue queue, to make sure there are none for the module you are interested in.

6 - Does the module add complexity to other parts of the website?

Complexity is something you ant to avoid as much as possible. The more complex you website becomes, the harder it will be to administrate, maintain and change or add new features to.

With 6-7,000 modules available for Drupal it is not so easy to find candidates containing the functionality you need. Then, of course, its not very fun to spend hours on reading the documentation, downloading, testing and so on. You want to get back to implementing new features in your projects as quick as possible.

I argue that it is very important to spend quite a bit of time doing the research and testing. If you don't there is a big risk that you will have to pay dearly for it in the future.

One of the most common ways of adding complexity is to use a module for a task it was not intended to solve. Below I give you an example of such a case.

Example about creating future complexity problems

I will once again use the Node Limit Module and the project I am currently working on.

This particular project is going to be made live in phases. The features on the initial release will be quite limited, but as the project goes on many more features will be added.

A requirement for the first release is:

• Limit the number of nodes for a content type a user/role can create to one.

It would have been easy to use the otherwise excellent Content Profile module to achieve this as It quickly would solved the task.

But, when we looked at how this limitation is going to work in the future we would have built ourselves into a corner that would have been quite difficult to get out from: Those requirements are:

• User/role shall be able to create one node for certain content types.
• User/role shall be able to create X number of nodes for certain content types.

That means we will need something that gives us great flexibility on a per user or role situation in setting these limits. Something Content Profile simply isn't designed for.

When I finally found the Node Limit Number module and started to test it, I quickly realised it would suite as perfect. It will not only give us all the flexibility we need, but it will also be future proof, including when we start developing our own custom modules.

Node Limit Number solves one simple task, limiting the number of nodes a user or role can create, either in total or over a period of time. Its integration with Rules adds all that modules powers to it as well.

We will be able to:

• Solve the immediate requirements of limiting to one node per user/role.
• Allow us to create custom limitations for individual users or roles.
• Let us integrate its, and Rules, functionality in our own future custom module.

All that with next to no added complexity to administration, maintenance or future development.

Conclusion

By allowing yourself to spend enough time to do proper research and testing of modules you will greatly avoid complexity of your projects. You will also end up with a website that works better, is easier to maintain and administrate. Most importantly, you will be able to focus on enhancing it instead of rebuilding it.

I hope this post has given you some valuable tips based on my experiences about the process I use to select modules. It would be very interesting to hear about your own experiences regarding this.

Please feel free to use the comments to tell me about how you do it.