[development] Site specific modules

Jerad Bitner sirkitree at gmail.com
Wed Apr 28 15:11:50 UTC 2010

I usually like to keep all of my site specific changes in one place as
well - makes it easy to figure out where I customized something. But
recently I've come across a couple of other techniques that you might
be interested in trying.

Feature specific modules: these end up being modules that are
customizing certain features - so if you have a blog feature for your
site and you need to form alter it, or add a new view, or what ever,
you create a site_blog.module and have all the various components
there. Then you can simply svn up these particular changes in the
particular modules.

But most recently, I've gotten introduced the wide world of actual
'features', i.e the features module, which in a couple words is just a
module wrapper which can hold configuration, upgrade paths, and makes
the actual features generally easier to lump together when you have a
particular feature that is implemented across multiple modules. The
feature itself has a .module file as well so you can do your form
alters, theme registry alters, or whatever customizations you need for
that particular feature.

So I guess in both instances it's separating your customizations out
into whatever specific functionality that particular customization
effects. This may mean multiple instances of hook_form_alter(), but
it's a bit more reusable with the separation.

On Wed, Apr 28, 2010 at 9:42 AM, nan wich <nan_wich at bellsouth.net> wrote:
> At my current location, I have developed a major site-specific module (well
> over 100K). I have already split the admin, pages, and blocks out into
> separate files. I have largely done this on the same model as I use for my
> DO contribs.
> At any given time I may have four or five changes in place at various stages
> of testing, and working on the next change. The problem is that the
> powers-that-be occasionally want one change moved to production quickly. I
> can't do that without potentially moving untested changes too.
> So I'm looking for ways that others get around this situation. Certainly I
> can move various smaller pieces into include files; this is not a major
> problem as we use eAccelerator to cache all the modules any way. Is that the
> best way or only way? We do have SVN available.
> Nancy E. Wichmann, PMP
> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King,
> Jr.

~Jerad Bitner
Lead Developer and Drupal Trainer at Lullabot

More information about the development mailing list