When to develop a new drupal module vs. work with what exists?

Question

This can probably apply to other extensible content management systems, but I've been working with Drupal. Specifically I created an image sharing web application whose functionality relied on more original code than Drupal core code. I used the WebForm module and point its forms at Custom Pages with hard coded php to have nodes created programmatically and other strange voodoo.

Just before I was done I realized I perhaps should have just made my own module, or should I have? Even in retrospect it's difficult to tell.

What do you use to decide when a new module needs to be written and when the functionality you're seeking can just be kludged together from what's available?

Answer 1

Make a new module when you want to share or reuse the functionality easily. There is overhead in doing so, so if it's a one-off it's not worth it.

Answer 2

What i prefer doing is a full-on search on drupal.org for any/all modules that have the functionality that I require. I search drupal.org & groups.drupal.org (& maybe even the forums) with that module(s) name to see what other folks are saying about it. Lastly, I always check drupalmodules.com to see what others in the community are saying about it.

If I can't find exactly what I need, I roll out my own module. Plynx is right also, if you plan to reuse the functionality, create a new module IF it's unique enough to not exist yet.

Answer 3

I have a strong opinion on this, which is that all custom coding should be done within custom modules, with only one possible exception (see below):

I discern three cases:

1. Completely new functionality - this obviously calls for a custom module that encapsulates the new functionality. It makes it reusable and can even turn into an 'official' contributed Drupal module, if the functionality meets popular demand.
2. Tweaking existing functionality - for every site, I immediately setup a blank, custom module (named after the site). All custom code used for tweaking existing functionality (be it from core or contributed modules) happens within this module. That way, all my customizations are cleanly separated, which makes it much easier to update the core or other modules without constantly having to reapply my customizations to the updated code (of course one has to check if the customizations still work after the update and adjust or remove them as needed).
3. Fixing bugs/adding missing features - this is the possible exception mentioned above. If my changes are just a bug fix or an addition of an obvious, but missing feature, I might just do that within the original code, submitting my changes as a patch to the original module, hoping that they will get incorporated in a future release, thus making my changes obsolete.

In my experience, the 'overhead' of separating the customizations from the original code isn't really an 'overhead', as the 'one-off' tweaks & fixes usually stick around much longer than anticipated, and have a tendency to grow over the lifetime of a site. Having them separated from the start saves a lot off troubles down the road in maintenance, as applying updates & security fixes, as well as extending the tweaks will be much easier.