I finally got around to stopping by the IBM developerworks forums and leaving some feedback for the folks that are doing the great series of articles on developing a site with Drupal. They're diving all the way down into developing modules, including explaining Drupal's hook system, which is great to see.

Here's the feedback I left:

Figure 2 shows the base "modules" directory with a bunch of extra modules in it.

Best practices are to actually put all non-core modules in your local sites directory. So, for domain.com, you would put all non-core modules in /sites/adtech.internet.ibm.com/modules. This keeps the main base of Drupal clean and easily updatable -- you can replace/upgrade everything not in the base directory without having to worry.

Also, as of 4.7, Drupal supports .install files, which contain the SQL necessary to automatically initialize the database tables for you. This should be used instead of the .sql file shown.

So, that little post about keeping all modules in your local "sites" folder is just the start of best practices. Pretty much every Drupal install I work with is multi-site. Many will use a similar set of modules, but not the same. To be working from a single codebase, I have things setup like this:

Now, to update my base Drupal, I only need to do initiate a cvs update command. I can do the same on a module by module basis. I use the CVS command as follows:

Sometimes you will want the CVS version of a module, so simply remove "-r DRUPAL-4-7" from the command. There are more details on using the CVS contrib repository at Drupal.org.

But what if you want to use different versions? Or perhaps develop a module? Or override/patch a core module? Well, to use a CVS version with one site (say, beta.domain.com), simply check it out as /var/www/modules/module-CVS and symlink to that version rather than the tagged version.

Overriding a core module is no problem. Any core module you place in /var/www/html/sites/domain.com/modules will override the main install core module. This is a safe way to have patched core modules without having to wonder if you'll run into trouble updating your main Drupal install.

Hope those details on some more best practices are useful. The Bryght Hosting service (yeah, it's not quite publicly launched yet -- it's designed to be production grade hosting for Drupal sites), powered by Firebright, comes pre-configured with this layout, and we additionally maintain a Bryght Base in our public SVN that we keep patched and up to date. For instance, tinymce is installed with all the necessary configurations for the img_assist plugin, spellchecking, and the drupalbreak button.

That barely starts to scratch the surface of some best practices. Questions welcome!