Click to watch "There Might (Not) Be A Module For That"

One of the first steps in a new Drupal project is to walk through the wireframes and functional requirements of the new site to try to decide exactly how you would implement them in Drupal.

Sometimes that is dead easy to do. A simple list of the titles of the latest content can be constructed using Views. Done!

Sometimes that is an enormously complicated problem because there isn't any existing Drupal solution, or there are multiple possible Drupal solutions, or the Drupal solutions won't meet the functional requirements, or they don't seem to be ready for production.

If you've been around Drupal for any length of time, you've heard the phrase "There's a module for that", referring to the fact that there are over 15,000 contributed modules on Drupal.org that extend the core functionality and do almost anything you might imagine anyone would ever need. Sometimes you can do a quick search of the module list, find a module that is a perfect fit for your needs, and drop it in place. But often that's not sufficient. Both the cost and the timing of a Drupal project can be significantly affected by the decision about how to respond when there is no drop-in Drupal solution that will meet the project's requirements.

At Lullabot we call this the 'discovery' phase of a project -- the process of understanding the functional requirements of a new site and exploring the best ways to achieve it in Drupal. We've helped clients of all sizes determine how to use existing contributed modules to build out the site that they need, and when (and how) to respond when the existing solutions just don't work.

Some of the questions this session will cover include:

• How to find existing modules that might solve your problems.
• How to test drive potential modules to see if they work the way you need.
• Digging for sometimes obscure or hidden documentation about how the module works.
• Mining the module issue queues to tell if a module is really suitable for your needs.
• Deciding which version of a module is really 'safe' to use.
• Choosing between alternate modules that might solve the problem.
• What to do if existing modules aren't ready?
• When and how to roll your own solution.
• When and how to contribute your modules and/or changes back.
• Validating your decisions in the face of ambiguity and uncertainty.