Technology Blog »

Made to Measure Drupal Modules: Put Some Elastic in the Waistband

Something I find myself doing on practically every site I work on is the creation of an ad-hoc module to contain site customisations that go beyond what can be done with themes. Such modules are often needed to put the finishing touches to a site design, but they present certain challenges to the conscientious developer.

Here are some typical requirements that might be met by one-off module code:

• Another module adds unwanted controls to every node edit form, not just to relevant ones (hello, E-Commerce), so you need to turn them off. Other typical form customisation tasks include reordering elements or inserting additional explanatory text for the benefit of the user.
• The provision of an API for use in views and blocks, for such tasks as determining characteristics of the current page so output can be tailored to the context. You may need to make the same test – such as checking the value of a particular node field – for every one of a set of related blocks, so a simple API function for the purpose makes life a lot easier.
• The implementation of any very site-specific needs, where a general approach, though desirable, would be expensive to implement. For example, suppose there’s a particular taxonomy category which you need to style differently from others used on the site, and provide specialised navigation facilities. In such a case it’s not unreasonable to take shortcuts based on your knowledge of the site’s requirements; you might for example not bother to test whether the category is hierarchical or not.

One benefit of this type of approach is that it’s relatively lightweight: often the alternative is to load up the site with a number of prewritten modules many of the features of which are not needed and which clutter up the administration interface. The major disbenefit is in coping with change: will the choices you made in developing your module still be valid as the site grows?

A partial solution is, where possible, to expose these decisions as settings in an administration panel for the module. Since the module is often something of a ragbag of unrelated functions, it may be wise to create switches that can be used to turn its logical component parts on and off so they can be substituted by better alternatives should they become available.

The administration panel is also a good place to put a description of what your made-to-measure module does, exactly, highlighting any potential issues. Be considerate to the owner of the site and the developers who work on it in future. Even if you are the only person who works on the site, reminders of the choices made and why can save a lot of time when you come back to the module after some months spent on other matters.

In summary, although your made-to-measure module may be a compromise, it need not be a kludge: put enough elastic in its (metaphorical) waistband for future growth and you could avoid some pain.