Any serious Drupal Developer would admit that one of the most challenging tasks in Drupal development is to identify, evaluate and adopt contributed modules. This is so, for the following reasons:
- Many of the contributed modules are written by developers, with specific Requirements in mind which need not be exactly matching you requirements
- There are many modules doing the same task but with different approaches
- The code quality is unknown until tested
It is therefore important to take a systematic approach to evaluation of modules in order to derive the best value out of them.
In my last blog, I wrote about the key questions to ask while evaluating a Drupal module. The questions are:
- Is the module well maintained?
- How much of the requirements does it cover?
- What is the effort to customize / add / remove features?
- Does its design employ Drupal’s best practices for writing modules?
- Is the code well commented and easy to understand?
It is most likely that you don’t get positive answers to all of these questions. How the answers affect your decision would depend on a number of things including:
- The volume of traffic the sites is expected to handle
- Your Drupal skills and ability to maintain modules
- Time and resources available
Module Maintenance
A well maintained module with a lot of community support can be safely adopted. Following is the screen garb of the Webform module taken form the Drupal website.
As you can see there is continuous development and maintenance happening for this module and is current with Drupal’s latest release. The Maintenance Status says “Actively Maintained”.
Another indicator is usage statistics. While this need not provide the complete picture, it is a good indication of adoptability of the module. Here’s a screen grab of usage statistics for Webform module:
As you can see, there is a large and growing user base making it very safe to adopt.
It is also important to take a look at what are the pending issues for the modules and have a good understanding of them. If some of the pending issues come in the way of using the modules, consider fixing them and sharing them with the community.
Requirements Coverage
The best way to understand how much of your requirements would be met by the module is to install it and try it out. Some modules provide screen shots and demo sites with which you can experience the functionalities.
If you don’t have a development team capable of customizing modules then you don’t have many options. Pick up the module that best suites your requirements and use it.
There are modules which can be used as a basic framework to build specific functionalities on top of it. Organic Groups (OG) module is an example. Many people use OG to create and manage user groups and build custom functionalities on top of it.
Many of the popular Drupal modules provide well structured interface functions / APIs for extending the module’s functionalities. Such modules can be easily extended without worrying about how the code is written and the possibility of breaking upgradeability. This very useful if you wish to use the module as a basic framework to build specific functionalities.
Effort for Customization
If you have the skills and resources then you can compare the effort of developing a module yourself with customizing an existing module. Module customization can involve both extending functionalities and equally importantly, removing unwanted functionalities – which can be a very hard thing to do. Therefore, careful analysis of the design is required to assess the effort requirement.
Too much customization required? You are very likely to break the upgradeability of the module. Well maintained modules receive regular patches covering various fixes including the ones related to security and functionality enhancements. Over customized code is very likely to break during patch updates and upgrades. However, if you have the skills and resources to maintain your own code then you can still make use of code blocks from the module saving some development time and effort. Again, if you think what you are building is generic in nature, consider giving it back to the community.
Employment of Best Practices
Drupal website has a detailed guide to module development . While certain methods and guidelines must be followed by all modules, others are ‘best practices’ and therefore optional. For example, a module can by-pass Drupal’s APIs to directly query or update database tables. Similarly, a module can use custom code for database access rather than using Drupal’s API. While there could be valid reasons why some of the guidelines are not followed, employing best practices will make it more maintainable and easy to understand.
Coding Standards
Code written by experienced developers are always well structured and easy to comprehend. If you plan to customize or maintain the module then make sure that the code can be easily understood. A well organized code is also an indication of bug-free code.
Can’t find it? Build it.
With ever growing base of contributed modules, it is very likely that you will find a module that meets your requirements. The very reason you are looking for a module is because, your requirement is generic in nature. Therefore, in case you don’t find the module you are looking for, build it as a generic module and contribute to the community. And when you build it, ensure that it has all the qualities that you were looking for in a module!
Please leave you comments below. If you like this blog, please follow.