Aliased multi-site support

+1 from me, would be very handy. There's some weird character encoding noise in the patch file though.

Hmm, my browser auto-detects ISO-8859-1 when I view the patch (on two different machines), manually selecting UTF-8 the noise goes away again. I'll put it back to needs review since it may not be an issue. It's the conf_path() section of the patch only, first bit is fine either way.

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

@Crell: I saw the encoding before as well (catch had already mentioned it). The latest patch does not show any oddities. Thanks.

Will this allow us to store credentials outside of web root?

This was on my list for several months. It is a pain to deploy a site that was at test1.example.com without symlinks.

No longer do we need to move files around and hack the database for file locations ...

Thanks for doing it sooo much. I owe you a (non-alcholic) beer ...

Works as advertised.

So, +1 from me.

Here are the benchmarks.

Without the patch, install to sites/default as usual

Concurrency Level:      5
Time taken for tests:   6.286319 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      2444000 bytes
HTML transferred:       2180500 bytes
Requests per second:    79.54 [#/sec] (mean)
Time per request:       62.863 [ms] (mean)
Time per request:       12.573 [ms] (mean, across all concurrent requests)
Transfer rate:          379.55 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   4.8      0      46
Processing:    23   61  47.5     51     628
Waiting:        0   59  48.1     50     628
Total:         23   62  47.6     53     628

Percentage of the requests served within a certain time (ms)
  50%     53
  66%     68
  75%     76
  80%     82
  90%     96
  95%    123
  98%    192
  99%    252
 100%    628 (longest request)

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

$sites = array(
 'sub1.example.com' => 'khead-test',
 );

Concurrency Level:      5
Time taken for tests:   6.347545 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      2444000 bytes
HTML transferred:       2180500 bytes
Requests per second:    78.77 [#/sec] (mean)
Time per request:       63.475 [ms] (mean)
Time per request:       12.695 [ms] (mean, across all concurrent requests)
Transfer rate:          375.89 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   6.7      0      48
Processing:    23   60  43.9     55     738
Waiting:        0   58  45.1     53     736
Total:         23   62  44.0     56     739

Percentage of the requests served within a certain time (ms)
  50%     56
  66%     70
  75%     77
  80%     82
  90%    100
  95%    123
  98%    158
  99%    188
 100%    739 (longest request)

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

Subscribing, I'm having a similar problem I solved (for now) using symlinks.

Good stuff - subscribing.

Crell, just to be sure: would this allow

$sites = array(
  'example.com' => 'foo'
);

where foo is not a domain, just a directory?

If so you would make me very happy.

@gaele

Yes, that is how I tested it.

No tests?

Still applies with offset. I don't see how this can be tested either. It's annoying messing around with system paths etc. when moving sites around, so confirming the RTBC.

is this working on d6 as well?

The Crell patch #19 still applied successfully on CVS HEAD.

Is it relevant to use DRUPAL_ROOT here?

We did take a lot of steps to *not* ever include directly without DRUPAL_ROOT. So I think this is needed ask DamZ for a review to be sure.

Patch adds DRUPAL_ROOT

Hm. This seems a little bit hackish, and something symlinks were basically designed for. We handle this by checking in symlinks to our SVN repository and it works just fine.

Someone care to sell me on why this should be a Drupal problem and not a filesystem problem?

Also Windows and symlinks don't go well together.

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:

// Translate e.g. "peter.site3-com.dev2.acme.tld" to site3.com
$production_hostname = getProductHostnameByDevHostname();
$sites = array(
  $_SERVER['HTTP_HOST'] => $production_hostname,
);

This may not be the intended use of this feature, but it solves the problem :-)
</background-info>

Folks - please reread Crell's answer in #33. The sticky problem is about file paths in the database, not about identifying a sites directory.

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?

Does this make more sense?

$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',
);

I thought webchick might not like me for not listening to one of her excellent suggestions so I quickly added some more comments and patched is attached.

@sprugman:I don't believe it happens now. Maybe the attached patch will give a better description.

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

This probably doesn't work.

In conf_path():

-  $confdir = 'sites';
+  $confdir = DRUPAL_ROOT . '/sites';
+
+  $sites = array();
+  if (file_exists($confdir . '/sites.php')) {
+    // This will overwrite $sites with the desired mappings.
+    include($confdir . '/sites.php');
+  }

But in conf_init():

  if (file_exists(DRUPAL_ROOT . '/' . conf_path() . '/settings.php')) {
    include_once DRUPAL_ROOT . '/' . conf_path() . '/settings.php';
  }

Conclusion: conf_path() should return a path relative to DRUPAL_ROOT. The DRUPAL_ROOT must only be prepend in file_exists() and include() in conf_path().

Cleaned up DRUPAL_ROOT in conf_path().

+ * named $sites, which maps domains to directories.  It should be ini the form

Extra "i" on the end of "in".

Fixed the i

Went to test this patch and multisite stopped working after applying. Still looking into the cause.

Steps to reproduce.

1) new checkout
2) copy sites/default/*.* to sites/site1/
3) Go to http://site1
4) Reach requirements page and it is looking for the settings.php in the sites/site1 directory. Good
5) Apply patch and do the same. It is looking for the settings.php in the default directory. Bad

Found the issue now patching

Ok the issue was that I used for example, file_exists("DRUPAL_ROOT/blahblah") it needed to be file_exists(DRUPAL_ROOT . '/blahblah')

I changed it throughout and tested on my local machine. Works great! Thanks Crell.

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

define('DRUPAL_ROOT', dirname(realpath(__FILE__)));
echo "DRUPAL_ROOT/ferzle";

Outputs: DRUPAL_ROOT/ferzle

Oops forgot to move to CNR

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

Couple quick final nitpicks:

+ * $sites = array(
+ *   'The normally publicly accessible domain' => 'A directory within the sites directory'
+ * );

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

+ * $sites = array(
+ *   'devexample.com'    => 'example.com',
+ *   'mymachine/example'  => 'example.com'
+ * );

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.

Fixed

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.

The documentation should probably end up on the d7 version of http://drupal.org/getting-started/6/install/multi-site

Blah didn't switch the project

Backport for D6. Should this go into an issue of its own?

I am not sure whether new features like this are still being added to D6 or even D5. The patch is low-risk and doesn't break BC (unless people happen to have a file named sites.php inside their sites directory).

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

Problem with documenting this is that to my knowledge we don't have a 7.x section in the handbook and until we do the documentation will have to wait. Any plans of adding a d7 section to the handbook anytime soon or possibility of copying the d6 over to d7 and make changes as things go?

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?

@ HansBKK, yep, versioning of docs is one of our biggest, hardest problems to solve. Feel free to join the redesign group documentation discussion.

@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 ;{

The most important place to document this is in Drupal's '/sites' directory. Especially until we figure out where to document it on drupal.org.

People who know about this feature are likely going to look for instructions and an example in the very place where they need to implement it. This is also a likely place for people (who are unaware of it) to fortuitously stumble upon it.

Patch attached to add a 'sites/default.sites.php' file to core, analogous to 'sites/default/default.settings.php' (except that this one is never copied and renamed automatically). The code comments are borrowed and modified from conf_path() in includes/bootstrap.inc (i.e. from the original patch in this thread) and from settings.php.

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.

Looks like this was a testbot glitch.

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.

Set -D5 extension on last patch to avoid bot.

RTBC is on the documentation D7 patch, for clarity

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.

@adrian - that is the reason for using the sites/all/[modules/themes] directories. Admittedly it does clutter up other sites modules.

Have you looked into Junctions - they are the NTFS equivilent of sym- and hard-links.

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

Marking this fixed, for lack of a better status.

Can we get a comment on porting to D6? #60 has a D6 backport, and webchick did say we could discuss backporting it once the documentation was done...

Here is a backport for D6.

Setting title back for D6.

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

New features are not added to stable versions. This is a won't fix in relation to Drupal 6.

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

FWIW, I agree that this is an inappropriate change for a stable branch.

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.

@Pedro Lozano

#83 is the D6 patch

all for the grace of statistics ;)

+1. Thanks, I needed it.

Rerolled patch for conflict in CHANGELOG.txt and rename from default.sites.php to example.sites.php

Still works beautifully in Drupal-6.15.

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

Patch still applied for 6.16 but CHANGELOG.txt obviously conflicts, so here's a reroll.

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.

Strange, how did that happen?

Thanks for the pointer. Incorporated that small change.

Let's see if this one works.

subscribe

How about we just use the drupal/sites/default folder and create 1 subfolder per website.
this path doesn't rely on the domain name so it will work on all environments without patching anything...

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

Thanks for the patch at #83 which seems to me like the best one for D6

It gave me a conflict on the CHANGELOG file - but as this change won't be officially supported it probably shouldn't be in the log anyway.

@Crell re #62 "We do however sometimes maintain backports in the issue queue ... What's the proper way to do that again?"
- did you figure this out? There have been a few issues like this I've come across and if there's a proper way to maintain the patch I'd like to know what it is :-)

Rather helpful - subscribing

Re-rolled this patch for drupal 6.19
note - no changes were made to changelog.txt as this was done from a git repo instead of cvs.
I had to re-roll tis patch manually for myself since comments were added to bootstrap.inc between 6.16 and 6.19 making the earlier patches in #83 and #98 fail.

Works like a charm for me and hopefully will help others with multisite workflow under D6

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.

I was testing the Aliased multisite support if it also applicable for custom ports. After reviewing the code in includes/bootstrap.inc, I got to finally figure it out.

I suggest that we add an extra example on how to use custom ports.

Attached is a patch adding an extra aliased multisite example using ports and modified text in the code comments in includes/bootstrap.inc and sites/example.sites.php.

+++ includes/bootstrap.inc
@@ -354,15 +354,16 @@
+ * "example.com", "devexample.com", "localhost/example", or "localhost:8080". ¶
+ * That is useful on development servers, where the domain name may not be ¶

Below as well: Trailing whitespace.

Powered by Dreditor.

@jorap can you open a new issue for 8.x that suggests making the documentation change. You can link to the issue in this issue.

Thanks

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

Here is the patch in UNIX format.

@redndahead, created the said issue at http://drupal.org/node/1018324

From #111 - Another patch created from CVS.

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

@jorap please post it to that other issue.

For Drupal 6.22

Has anyone been using the D6 patch on a site with per-node-type template files (node-article.tpl.php)? Those templates aren't found when I use this feature, but if I disable sites.php and go back to the expected folder name, they work normally.

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

Great job.
subscribing...

re-rolled for 6.24

Does this patch also work for Drupal 6.25?

also, this was fixed in D7 not 6.24