Aliased multi-site support

Oh yes. Patch added during DrupalCon code sprint. :-)

@catch: Where? Viewing the file in KWrite I don't see any "noise".

I can confirm the problem catch is talking about. Where spaces should be, there are … some other kind of symbols. I tried UTF-8 and ISO-8859-1 (Latin1 and Windows).

It turns out something did change in conf_path() between D5 and D6, so the previous patch would have been a regression anyway. Here's a new version that should (a) have no regressions and (b) not have any stupid character encoding. I hope. :-)

Please review.

Thank me by testing it and setting it RTBC if appropriate. ;-) Thanks.

@moshe: No, this is unrelated to putting settings.php outside the web root. That would be a much larger change, since you'd need to move settings.php but not the module and theme directories (since those must be web-accessible for CSS, JS, and image files). Not that allowing settings.php to be moved is a bad idea, but it's a separate issue from this one. (I suppose the sites.php file could be used for that as well, but let's take it one step at a time.)

Here are the benchmarks.

Without the patch, install to sites/default as usual

With patch and a sites.php that has one entry:

Caching is off in both cases. One node on the front page.

Conclusion: the difference is negligible, and this patch has no adverse performance impact.

Get it in Dries ...

Good stuff - subscribing.

@gaele

Yes, that is how I tested it.

Update patch for new coding standards. No other changes. Still RTBC.

Tell me how I can write unit tests for a function that depends on the file system having a certain state when I can't reliably modify the file system as part of the test and I will happily write tests for it. :-)

We have been using this patch on a few D5 sites in production for 6 months now without incident.

The latest patch will probably apply against D6, but I haven't tried. I will probably make backport patches available, but not until this patch lands in Drupal 7. Which means someone needs to commit it (hint hint).

And of course, all of this time and I JUST NOW find the one bug in this thing. We should be using include, not include_once, as if conf_path() is called with a $reset a second time (as happens in the installer, and nowhere else, I think) then we don't get the alias file.

No other changes from last version.

I don't believe so, since it's used higher up when files get included. I wasn't tracking that issue too closely, though, so I'll defer to Dries/webchick.

Patch adds DRUPAL_ROOT

The primary reason is so that what gets into the database is, in fact, the "production" domain.

In our dev setup, everyone working on a given site has their own domain for their own sandbox. That would map to a different directory on disk in the current Drupal setup. That means places where Drupal stores a file path into the database (files, system table, etc.) will always be wrong for someone, because the database is shared.

A symlink may get Drupal to the right settings.php file, but it won't get it to save the right, shared values to the database.

The underlying problem is that Drupal multisite is far too tightly coupled to the domain name it happens to be running on at any given time. As soon as you try to move the site to a new domain (company rebranding, administrative decision, multi-server development process), it breaks down and cries.

In our shop we experience the same problems as outlined by Crell in #33. We handle the problem by adding symlinks, but it easily becomes a lot of symlinks.

<background-info>
Here is a brief description of our setup. Buzy developers may skip this section :-)

We have a number of developers (John, Alice, Peter) who each develop on a number of sites (site1.org, site2.com etc.). We have several shared development servers (dev1.acme.tld, dev2.acme.tld etc.). We use rule-based hostnames like these:

• john.site1-org.dev1.acme.tld - John's development site on development server 1 for the site whose hostname in production is site1.org
• alice.site2-com.dev1.acme.tld - Alice's development site on development server 1 for the site whose hostname in production is site2.com
• peter.site3-com.dev2.acme.tld - Peters's development site on development server 2 for the site whose hostname in production is site3.com
• cvs.site4-net.dev2.acme.tld - snapshot of CVS HEAD for the site whose production hostname is site4.net

Developers on the same development server can share the same symlink, e.g. site1-org.dev1.acme.tld, so we need one symlink per development server and one for the production hostname (and one for the temporary production hostname used when testing the site on the production server prior to launch).

The product of developers, sites and development servers is big and rapidly changing, so with this patch we would probably not enumerate all combinations in sites.php but rather do something like this:

Well done. ;)

Ok, I can commit this. I want to make one change though. 'example.com' => 'otherexample.com' isn't a very clear example. I'd rather use something "real world" which *seems* like it would be:

example.com => localhost

or

example.com => dev.example.com

is that true? It'd be easier to tell if the docs were a bit more clear in that section, so let's update that as well. I'd like to see those capture some of the discussion on this thread: why this is useful, what the left vs. right side of the array should contain (a code comment like 'The normally publicly accessible domain => A directory within the sites directory), etc.

Also, can we get a CHANGELOG.txt entry too?

$sites = array(
'dev.example.com' => 'example.com',
'mymachine/example' => 'example.com'
);

I'm not sure the first is the best possible example, because IIRC, the existing system will allow that mapping automatically. Maybe it should be:

$sites = array(
'mymachine/example' => 'example.com'
'dev.example.com' => 'example2.com',
);

or

$sites = array(
'mymachine/example' => 'example.com'
'localhost' => 'example2.com',
);

sprugman convinced me on IRC that dev.example.com to example.com already works. So changing the docs to devexample.com

Cleaned up DRUPAL_ROOT in conf_path().

Fixed the i

Found the issue now patching

Yeah, you can't put constants in strings and have the substituted like variables:

D6 Patch, excludes DRUPAL_ROOT fixes. Does it exist in D6?

Couple quick final nitpicks:

a) Line doesn't wrap at 80 chars
b) If it's publicly accessible, mymachine/example doesn't make sense.

a) The spacing is off between the ' and the =
b) Let's use dev.example.com
c) Let's use localhost/example
d) 2nd array line needs a comma.

Note that b) and c) need updating below as well.

Committed. :) Thanks.

This needs to be documented... somewhere... hm. I guess whatever handbook page is talking about settings.php. Doesn't need to be extensive. Just the fact that this file exists and you can use it for what you can use it for. Read the file for more information. It might be a good to coordinate with the docs team on this.

Blah didn't switch the project

Features are not back-ported to stable versions.

How about get this documented first, and THEN worry about whether we do or do not backport to 6.x. :P

suggestion - sub-page of the relevant D6 page, clearly flagged as D7-specific for now

I'm finding all kinds of nodes relevant to D5 that got moved to the D6 sections, which therefore are gone as far as D5 people are concerned, makes for an even more "interesting" doc situation for newbies trying to find stuff. IMO copying's not the way to go, as pages that apply to both versions then get edits in only one version.

OT (not really, but sticking my neck out farther than I'd like :)

I'd suggest finding a good systemic solution to this problem before repeating the same method for D6->D7. Hate to say it but IMO we're really pushing the limits of Book and it's pushing back. . .

Separate platform? Or if we really have to keep this very complex doc set in our own dog food - well-managed vocabularies + Views and/or better search?

@add1sun

OK, but the way I'm feeling at the moment I'll probably regret it in the morning

http://groups.drupal.org/node/15965#comment-55186

Actually I'm regretting it already ;{

A core patch needs to go in the core queue. No one important will see it in the docs queue. ;-)

I have applied the Documentation patch, and following the instructions contained within, have setup the sites.php file.

Having it as an example file is helpful for shopwing the capabilities, but I also think that some d.o documentation will be good, when there are 7.x pages.

I cannot reproduce the testbot failure. Requesting review again.

Attached is a Drupal 5 backport of c960657's Drupal 6 backport. For all the people, like me, who need it.

Untested but should be fine.

The last submitted patch failed testing.

I know it's probably a weird place to bring this up, but i was going through some _VERY_ old issues of mine, and i found this :

http://drupal.org/node/25720

Basically, it allows the sites to add additional paths to search for modules / themes. One of the issues you will run into with windows is that without symlinks you will be duplicating a lot of code on multi-site installs.

Say if you had 10 sites on one drupal install, half of them need access to one shared module, the other some other module, and each of these has their own set of custom modules.

Without symlinks, or a way to specify this in code, you would need to either copy the exact set of modules each site needs into it's sites directory, or put the shared modules into the sites/all, and just live with the fact that half of the sites will have access to modules they shouldn't.

Cool. Committed Jaza's documentation patch at #68. Thanks a lot!

Marking this fixed, for lack of a better status.

Here is a backport for D6.

Successfully applied and configured D6 sites with the patch in #83.

@Gabor,

This isn't really a new feature. This fixes a fundamental flaw from testing to production. The fact that at the moment you have to go through each entry in the files table and replace the path of the files when you move from testing to production. You also have to change places in the variables table where this occurs. In the variables table it's not as easy because the data is serialized and depends on how the module stores the data.

Hopefully you can reconsider this for D6. It doesn't change anything fundamentally in core, but it fixes some serious issues in a multisite configuration.

Will try this. Althought it will never be commited it would be nice to have a working patch for people who need this in 6.

all for the grace of statistics ;)

+1. Thanks, I needed it.

Thanks for the D6 patch. Very handy and works like a charm.

The latest patch file is empty.

You may want to incorporate the fix for #748984: Fixed wrong multi-site directory aliasing example in your backport.

subscribe

I'm not a programmer, so I'm not confident I've understood this thread entirely. I'm running a 6.17 multisite setup. My understanding from the above is that bootstrap.inc in 6.17 needn't be patched or edited for this to work; I just need to add the sites.php file to sites/devmysite.com for this to work, right?

I've done that, but it doesn't seem to help the big problem I'm having. Everything works fine on my live sites, but on my localhost version, the auto-generated image paths are changing is this way:

Live site:

Dev site:

I am at a loss why this is happening, and it's driving me nuts. This thread is the closest I've yet found here to the problem I'm having. I don't even know how I should describe this, or how I might search for the solution.

My dev setup is XAMMP on Windows 7 64bit.

Look at this support document that I wrote. It should solve your problem. http://drupal.org/node/642712

Rather helpful - subscribing

6.20 made minor changes to bootstrap.inc ; however, it did not change the line numbering, therefore this patch still applied to 6.20 (I just successfully applied it to s multi-site install where several directories are aliased.

I am re-attaching the patch - the file name has been changed to reflect that it works for 6.20 but the contents of the patch file are exactly the same as in #106 above.

Below as well: Trailing whitespace.

Powered by Dreditor.

#108 was my first ever patch submission in an open source project.

Here is the patch in UNIX format.

The last submitted patch, example_sites_php_port_example_fixed.patch, failed testing.

#109 still stands. Also I don't see any reason to have 2 issues for this. Drupal 8 hasn't even been branched yet, and once it has, IMO we can move this issue there and then backport.

For Drupal 6.22

It seems to be working fine for me. Not sure what else it could be. Did you clear all the caches?

re-rolled for 6.24