I'm using one drupal codebase to develop several sites. I find it useful to be able to override a module on a per-site basis. Here's how I'm doing it:
This is a truncated version of my drupal codebase:
drupal/
...
modules/
...
some.module
...
sites/
site1/
settings.php
site2/
settings.php
modules/
some.module
site3/
settings.php
...
My sites/site2/modules/some.module replaces modules/some.module. This means that site1 and site3 can use the original some.module, while site2 can have some customised behaviour.
This doesn't work by default in drupal, as modules/some.module will be loaded instead of sites/site2/modules/some.module, but it only takes a small change in bootstrap.inc, a patch of which I have attached. This may not be the best way to implement this change because it's very subtle and should probably be more explicit about what it's doing, but it's a nice quick fix.
Of course I could just call my custom module sites/site2/modules/someother.module and avoid the whole problem, but that makes quickly customising a module tedious, because after copying the module I have to go through it and replace most (but not all) instances of 'some' with 'someother'.
This also raises issues when some.module gets updated, because I now have to maintain my own modified some.module separately, but I am going to have to do this anyway to implement some features that only make sense in site2, and nowhere else. Until I can override individual functions of a module (like I can with theme_ functions), this seems like the best solution.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 62563-display-modules-dirname.patch | 2.24 KB | bdone |
| #9 | 62563-modules-before.png | 216.85 KB | bdone |
| #9 | 62563-modules-after.png | 219.58 KB | bdone |
| module-override.patch.txt | 607 bytes | wrunt |
Comments
Comment #1
simeI have a feeling that this functionality will be enabled with Crell's "all" directory idea:
http://drupal.org/node/44920
I've marked a duplicate on this assumption.
.s
Comment #2
wrunt commentedThat sites/all idea is similar, but Crell's current patch doesn't do what I want, which is to override a specific module for only one site, while leaving the original module functional for other sites.
Comment #3
killes@www.drop.org commentedNo new features for 4.7, moving to cvs.
Comment #4
tenrapid commentedActually this is already working in 4.7 with modules and themes.
But you have to note the following:
Let's say you have some.module in the base modules folder and it is enabled in site 2. Then you put a modified version of this module in the sites/site2/modules folder. At this time site 2 still uses the original module in the base modules folder.
Now all you have to do is to disable and then enable again some.module in site 2. After that site 2 will use the version in the site2/modules folder.
Comment #5
moshe weitzman commentedmany admins get bitten by this problem of multiple of same module and not knowing which is active. we should add something in the UI to reflect which is active.
Comment #6
drummComment #7
LAsan commentedIs this feature implemented in current version?
Moving to cvs
Comment #8
Tor Arne Thune commentedThis is still relevant after the release of 7.0. Moving to 8.x.
Comment #9
bdone commentedconsidered adding a new modules-info section, but in seven, this looked better within the collapsible requirements section.
before patch
after patch
Comment #10
bdone commentedadding tags, per some suggestions in irc
Comment #11
Bojhan commentedI am pretty sure we get this request every couple of years, and I am never sure other than developers who are debugging that this could be useful for. And those most likely will be able to find it anyway. So I am still very doubtful of the added value to the larger part of our audience.
Comment #12
yoroy commentedGonna be blunt here and mark this won't fix for the reasons in #11