So, we have a large, complex Drupal 6 site, which has lots of secret sauce and magic glue making it work.

Where we can, we've contributed modules back and made them generic, but we still have 30 or so custom modules to keep it working the way we need it to. Each module (in most cases) has a specific function e.g. our hook alters for the notification system.

We are doing a huge code review at the moment and looking at improvements we can make. One thing suggested is to merge the large number of modules into a few smaller master modules, with lots of include files. We would, perhaps group by general site area e.g. "community", "admin" and "messaging", instead of specific modules per functionality.

  1. Is the effort in doing this worth it? Will it speed up the site?
  2. What module grouping would you recommend?
    • by site area ("community", "admin", "upload")
    • by hook ("form", "node", "user", "theme")
    • everything in one module
    • something else?
  3. What naming conventions should we use for the include files to keep the codebase sane?
  4. Am i right in assuming the goal should be tiny .module file with includes per hook / menu / area?
  • Should we mark this CW?
    – mpdonadio
    Commented Nov 2, 2011 at 14:39

4 Answers 4


It sounds like you don't really know what your bottleneck is. This restructuring will likely have very little impact on performance (unless you happen to find and trim some major bloat in the process), but it may make things easier for you to maintain. If you do decide to restructure I would recommend splitting up along "site features" (blog, image galleries, etc.).

But if performance is your concern you first have to diagnose the problem before you attempt surgery.

  • Performance was the wrong think to ask about. Its more about best practice than shaving nano-seconds.
    – a_c_m
    Commented Nov 3, 2011 at 14:08

Modules should do one thing, and one thing well. The "thing" should be a piece of functionality on the site. That module should include all of the hooks to do that one thing. As much as possible, disabling a module should have limited side effects on the site, and should be limited to just disabling the "thing".

Ask yourself:

Can I have multiple hands in the project with how I am splitting / combining modules?

If I need to change the module a year from now, am I going to have an easy time honing in on where things are implemented?

If I need to edit some code, am I going to have to be worried about mucking up another feature (think shared hooks like form_alter, block_view, etc)?

I always choose ease of maintainability over minute performance impacts on a site.

  • We went down that route and ended up with 30+ custom modules. The defintion of "thing" is quite vage, it could be "customise ubercart emails" (small module) or "send emails to users" (large) or "control email communications" (huge, includes notifications customisations, ubercart, signup, password reminders etc). The question really is how to define the "thing" to split with :).
    – a_c_m
    Commented Nov 3, 2011 at 14:11
  • If you disable ubercart, would you need to edit a monster module? I would rather have 100 modules that can be enabled/disabled easily w/o dependency hell. If would also have 100 modules if it means that I can find exactly what I am looking for a year later without having to wade though a monster module.
    – mpdonadio
    Commented Nov 3, 2011 at 14:35

You'll need to carry out performance testing to answer the question of if it will speed up the site. Search for Mark Sonnabaum's recent XHProf presentation, as this is a painless way to do so.

Another approach beyond the ones suggested that you could take is seeing if you can now re-implement any of your custom code using contributed modules. Rules, Views, and other contributed modules have probably come a ways since you first wrote your code, so this could be another way to simplify, although you will likely end up exporting those configurations again with Features anyway :) - still, at least it'll be a bit less code/configuration for you to maintain in the end if that's one of your goals.


Using the Drupal core code as example, each module should implement independent functionalities. For example, in Drupal, the module for handling the taxonomy term is the Taxonomy module; it is not the Node module that include that functionality in its code.

The question is then, when do you split a module in two, and when do you keep the code in the same module?

  • If the code that should go in the new module is just few lines, then the code should be kept in the old module.
  • If in the old module you keep writing in different hooks is similar to if ($option_enabled) { /**/ }, then the code should be written in a new module; in this way, instead of having a module that tests if the functionality has been enabled, the administrator users enable the new module if they want the functionality.

Keep in mind that, when you split code in two modules, the main module should not depend from the secondary module, but vice versa. This means the main module should not verify the secondary module is enabled before to execute some code; if this happens, you should consider re-write the code to use a hook that is then implemented from the secondary module.

Between the following snippets, the second is preferable.

if (module_exists('secondary_module')) {
  // Code that requires the secondary module.
// Invokes the hook that is implemented by the secondary module.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.