One of the crucial steps in building any Drupal project is selecting which modules to use. When you are reviewing your functionality needs you may ask yourself;
- What do I need to build?
- Where and how can I find the modules I need?
- Will this module solve my functionality needs?
- Will I need to patch this module?
- Should I write my own module?
To quickly and correctly answer these questions, there are four steps you should follow. It's as simple as remembering how to R.E.A.D.
Research what exists.
Take any functionality specs, documents, stories or descriptions you have and train yourself to identify keywords that can be used to search for modules. Focus on nouns and verbs that have specific meanings. Train yourself be able to quickly isolate the key functionality needs
You want to take these keywords and search for potential modules. Drupal is a huge active community and there are plenty of resources for searching;
- Use your favorite search engine and search on "Drupal <keyword>"
- Search on drupal.org and filter by module
- Ask the #drupal-support IRC channel if anyone has had to build similar functionality
- Ask a question on http://drupal.stackexchange.com/
After using these resources and others, you should have a handful of potential modules identified. If after you have done your due diligence and have not been able to find any potential modules, then you may want to consider writing your own.
Evaluate the options.
Take your list of potential modules and use different metrics to determine which one may be the best fit for your needs. All of the following metrics can be found on the drupal.org page for the module.
- Read the module description. A well written description should tell you what a module does, what it does not do and what other modules or technologies it depends on.
- Look at community adoption. Pay attention to the number of site installs and downloads comparative to the modules age. An old module with a high number of downloads and installs, may indicate that this module solves the needs of the community.
- Look at the issue queue. Does the community contribute to the issue queue? providing bugs, patches and improvements. This indicates community backing and support of this module.
- Look at maintainer activity. Is the maintainer active? Do they close issues in the issue queue, do they make regular commits and releases to the module. A module with an inactive maintainer does not have a strong likelihood of being updated with bug fixes, security fixes or new features.
After looking at these different metrics, you should be able to pair down your potential modules to one or two best fit. If you eliminate all your potentials, then you may want to consider writing your own custom module.
Analyze the gap.
Having found a best fit module, you want to then find what gaps there are in the functionality it offers vs. the functionality you need to build. Download the module into a sandbox environment and play wit it. This will allow you to know how easily the module is to work with, how close "out of the box" it can get you to your end goal and what, if any, gaps there are in functionality.
If you do not find any gaps, then great you are done. The module does exactly what you need it to do.
For any gaps you do find, use the Drupal community again to see if any existing solutions exist.
- Search the issue queue for patches or sub-module recommendations.
- Ask questions on the Drupal IRC channels, or stack-exchange.
- Perform a search using your favorite search engine "Drupal <module> <functionality>" to see if someone else has already solved the missing piece.
After searching, if you do find a solution to close the gap. Great, use the solution.
Determine the amount of change.
If you do find a gap in functionality and no existing community solutions, then you will need to determine what you have to change in the module to close that gap. You will ultimately have to answer two questions about the changes you have to make.
- Will you have to change a lot of the code in the module to complete your functionality?
- Will your changes extend or alter the module?
If you have to change a large portion of a module, the chances of your changes (if submitted as a patch to the issue queue) being merged back into the module are very low and the cost of maintence very high. You may consider instead to write a sub-module that utilizes hooks and API's to interact with the module to complete your functionality needs.
If your changes extend the module and add to the functionality it already offers, then you may want to write a patch for the module. Take into account how much you are extending. If you are writing a whole new suite of functionality, then create a sub-module. If you do write a patch submit it back to the issue queue so that others can benefit from it and hopefully the maintainer merges it.
If the changes you need to make ultimately alter what the module seeks to accomplish, then you may want to instead write your own custom module. If you are completely changing what a module seeks to do, then you are essentially making a new module.
In my experience, following these four steps allows for quickly and correctly determine what functionality I need to build, which (if any) modules I can use and if I need to patch them or write my own module. The four steps of R.E.A.D can be summed up with a easy to follow flow chart.
If you'd like to learn more about following these steps and see some real world examples then you can watch my presentation on it from NYCCamp 2014.