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.

Comments

sime’s picture

Status: Needs review » Closed (duplicate)

I 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

wrunt’s picture

Status: Closed (duplicate) » Needs review

That 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.

killes@www.drop.org’s picture

Version: 4.7.0 » x.y.z

No new features for 4.7, moving to cvs.

tenrapid’s picture

Version: x.y.z » 4.7.0
Category: feature » support

Actually 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.

moshe weitzman’s picture

many 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.

drumm’s picture

Title: Allow site-specific module overrides » Display module paths in the UI
Version: 4.7.0 » x.y.z
Category: support » task
Status: Needs review » Active
LAsan’s picture

Version: x.y.z » 7.x-dev

Is this feature implemented in current version?

Moving to cvs

Tor Arne Thune’s picture

Version: 7.x-dev » 8.x-dev

This is still relevant after the release of 7.0. Moving to 8.x.

bdone’s picture

Status: Active » Needs review
StatusFileSize
new219.58 KB
new216.85 KB
new2.24 KB

considered adding a new modules-info section, but in seven, this looked better within the collapsible requirements section.

before patch

62563-modules-before.png

after patch

62563-modules-after.png

bdone’s picture

adding tags, per some suggestions in irc

Bojhan’s picture

I 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.

yoroy’s picture

Status: Needs review » Closed (won't fix)
Issue tags: -Needs usability review +Usability

Gonna be blunt here and mark this won't fix for the reasons in #11