Improve INSTALL.txt description of multi-site installation with subdirectories

Concur: I had a similar fix to the one listed here, and was about to file a bug report on it. I tested the fix here, and it works exactly the same as my slightly-different fix did.

NOTE that earlier in the bootstrap.inc file, there is some hoop-jumping to deal with the lack of REQUEST_URI on servers other than Apache. The fix here should ideally incorporate that hoop-jumping to achieve the same effect in this part of the script. I run Apache, so all is well.

jonathan

wimisin: Nice for you... Can you share your solution?

This is still an issue in version 6.13, and presumably with Drupal 7.

At a minimum, the documentation in INSTALL.txt and also in the Handbook should be fixed to note that this doesn't actually work if clean URLs are active.

But it would be better if the code itself were fixed so that this type of multi-site setup would work, since it has been documented to work at least since Drupal 6.0 (and possibly Drupal 5?)

Note that this issue was duplicated in:
#311421: Automated installation of subdirectory-based multisite (single code-base)
#577292: Subdirectories not obeyed in multi-site installations?

I have marked those other issues as duplicates of this one, since I think this issue has the most complete description of the problem and fixes.

This forum post provides a long description of other methods to make this work with symlinks; not sure if accurate or not...
http://drupal.org/node/117658
(there are many other similar forum threads on this topic as well) (Just to point out that this is a common problem and really ought to be fixed in both Drupal 7 and Drupal 6)

So I tried the above fix in Drupal 6. I found the line in function conf_path() in file includes/bootstrap.inc that said:

$uri = explode('/', $_SERVER['SCRIPT_NAME'] ? $_SERVER['SCRIPT_NAME'] : $_SERVER['SCRIPT_FILENAME']);

and changed it to:

  $uri = explode('?', request_uri());
  $uri = explode('/', $uri[0]);

Now when I try to go to whatever.com/abc, it is apparently recognizing that I have a sites/whatever.com.abc folder with settings.php in it, and that Drupal has not yet been installed for that subdirectory. So it sends me to whatever.com/install.php.

However, that doesn't work -- it just says "Drupal is already installed" (Drupal is already installed at whatever.com in the main directory).

If I try to go directly to whatever.com/abc/install.php, it also pops me back to whatever.com/install.php and I get the same "Drupal is already installed" message.

So I don't think this fix is enough to make everything work.

The behavior reported in #9 appears to be due to the following lines from db_set_active() in includes/database.inc:

  if (empty($db_url)) {
    include_once 'includes/install.inc';
    install_goto('install.php');
  }

This does a redirect to the main install.php file, which then apparently has no memory of the fact that you were trying to install for a subdirectory, so the conf_path() call this time is just going to to the main whatever.com site.

Just one more note that install_goto() uses the global $base_url and redirects to $base_url/install.php.

This $base_url is set in includes/bootstrap.inc in function conf_init(), and will ignore any subdirectories. But you can override it by setting $base_url in the settings.php file. It looks like the person in comment #5 above found that adding this to the settings.php file made it work...

So I put

$base_url = 'http://whatever.com/abc';

into the settings.php file in sites/whatever.com.abc -- but this also didn't work. When I went to whatever.com/abc, I got a generic "page not found" message from the installation already at whatever.com. And when I went to whatever.com/abc/ (with a trailing slash), it tried to redirect to whatever.com/abc/install.php, and I got a "The page isn't redirecting properly" message from Firefox.

So that didn't work either. No solution yet for me... and by the way this is on a LAMP shared server. Not Windows, Mac, etc. And I have not modified the .htaccess file or any of the other core Drupal files, except to make the patch to bootstrap.inc noted above.

Some forum pages reporting this issue and various attempted fixes:

http://drupal.org/node/239583
http://drupal.org/node/32853
http://drupal.org/node/195031

Those three forum pages (or at least the first two) seem to be reporting problems in using clean URLs, after they have successfully gotten subdirectory multi-sites working.

That is interesting, but I am not sure it is relevant to this issue. This issue is reporting that if you install the main site (example.com) and have clean URLs working on that site, it is apparently impossible to then get a subdirectory multi-site installation working in the first place (or at least, it appears to be impossible to run the install.php script).

Subdomain-based multi-sites do work, but not subdirectory-based multi-sites.

Some things that I haven't tested yet that would be good to test:

a) On the setup where I ran the tests for #9, #10, and #11 above, if I turn off clean URLs on the top level site, can I then get a subdirectory-based site installed using the install.php script? My guess is no (see #11), but haven't tested yet.

b) If I directly edit the settings.php (avoid running install.php), can I get a subdirectory-based site working with clean URLs turned on for the top-level site? My guess is that it will work with the fix in #9 and fail without the fix in #9, but I haven't tested yet.

c) If you directly edit the settings.php file (avoid running install.php) and have clean URLs off on the top-level site, can you get a subdirectory-based site working, without the fix in #9? My guess is yes, but I haven't tested yet.

d) Are there fixes to the .htaccess file that will fix any of these issues? Maybe some of the forum posts mentioned in #12 would have something to offer after all, even though they are addressing slightly different problems (trying to get clean URLs working, rather than trying to get *anything* working with subdirectory-based multi-site).

One more thing that would be useful to test for subdirectory multi-site: whether any of the above (a, b, c, d) is improved by creating a symbolic link. E.g. if you're trying to get whatever.com/abc to work, make a symbolic link from (www doc root for whatever.com)/abc to (www doc root for whatever.com), and see if that improves anything.

Just as a note, it is NOT mentioned anywhere in INSTALL.txt that this should be necessary!

As another note, many folks on shared hosting would not be able to make symbolic links, and I don't think that they are universally followed by Apache (probably there is a setting? I'm not sure what the default is, if so).

OK, this is interesting. On this particular host (A2, one of the official Drupal recommended hosts), adding a symbolic link from the subdir to the main dir fixed all the problems. I am now able to run the install script, and both sites can have clean URLs. So probably this should be added to the INSTALL.txt, as well as the handbook doc on drupal.org.

This worked fine with or without the fix in #9 installed.

But as a note, the people in the forums linked to above in #12 generally had symbolic links, and they were not able to get clean URLs working, so I don't know if my experience is representative.

Another thought: turning off clean URLs really doesn't have any effect on any of this. All it does is make it so that Drupal doesn't *emit* clean URLs. It doesn't change the fact that Drupal *recognizes* clean URLs.

Further testing:

If I have no symbolic link, and I have edited settings.php, and I have the fix in #9 installed, I can navigate to individual pages in my subdirectory site if I know the URLs and use the non-clean URL format. e.g. I can go to whatever.com/abc/?q=node/1 and that works OK. But I cannot seem to get administrative access to the subdir site without a symbolic link in there. I tried turning off clean URLs on the subdir site, and many other combinations of having or not having the fix in #9, but nothing made the subdirectory site work completely without a symbolic link there.

So my conclusion is that at least for this particular hosting setup, the crucial thing in getting subdirectory multi-site working is to make a symbolic link from the subdirectory to the root directory. This should be noted in INSTALL.txt and in the docs on drupal.org in the Handbook.

However, given the forum postings mentioned above, I don't think this is enough for all users to get clean URLs working on both top-level and lower-level sites, so even with that change to the INSTALL.txt file, I wouldn't consider this issue fixed. Not sure what to do about that.

Anyway, I'll go change the docs on drupal.org meanwhile... this page: http://drupal.org/getting-started/6/install/multi-site or its sub-pages...

One quick note: adding only the ln as described in http://drupal.org/getting-started/6/install/multi-site does not seem to be sufficient. I can replicate the problem (but no solution) on two different hosting set-ups (both are Apache/*nix based).

Have tested this carefully and you certainly can install multisites in subdirectories with clean urls in the current pre-alpha D7 version.

The majority of the problems reported above appear to be due to a failure to follow the configuration instructions correctly, in this admittedly complex setup. The OP's difficulties appear caused by the configuration of rewritebase. Some of the documentation may have been significantly improved since the original post. Note the instructions in the Drupal installation guide that note a more complex structure for the rewritebase is required if using a subdirectory multisite setup: http://drupal.org/node/15365

However, it is confusing and given the INSTALL.txt does go into quite a bit of detail about how subdomain and subdirectory sites are configured in terms of the directory structure in /sites, including describing the precedence in how Drupal searches for them, it is somewhat of an omission that the need to create a symlink is not discussed there. Attached patch proposes to address that.

(Not sure this issue is really "critical" given subdirectory multisite installations do in fact work, but it is a simple change to document what is required better so may as well leave it tagged that way and perhaps this can save some D7 beta testers a headache.)

Better wording.

Should have left this as a bug I suppose; feature requests are not for D7. It is a flaw in the INSTALL.txt.

The text in the above patch, at a minimum, needs editing for grammar/style/clarity. I don't think we should use the word "symlink" either -- it should be called "symbolic link", shouldn't it?

There also need to be instructions for what to do on Windows, I think? You can't use the ln command there, and I don't know if it's possible to make something equivalent to a symbolic link.

And someone needs to test these install instructions to see if they work as-is or if other patches are needed to get installations in subdirectories working.

Have corrected the one grammatical error I could find. Have changed all references to "symbolic link". Review welcome on how this could be made more clear or to match Drupal style better.

I disagree that there need to be instructions for Windows. If you review the rest of the INSTALL.txt file, there are multiple examples of commands that are designed for *nix and no Windows equivalents listed. Changing the entire INSTALL.txt file to be more Windows-useful would likely be a good idea but that is beyond the scope of this issue and certainly should not delay inclusion of this additional information that clarifies an important point regarding multisite installation that is otherwise not intuitive.

The instructions follow those provided in a number of forum posts in the past on this issue. I have tested the instructions and they work on my installations. Other testing of course most welcome.

I have also created #683892: Text clean-up of INSTALL.txt for a more general cleanup.

Marked #18641: INSTALL.txt: Include notes about Drupal subdirectories as a duplicate of this issue, since the current issue has an up-to-date patch. Clearly, this has been an issue for a long time.

#311421: Automated installation of subdirectory-based multisite (single code-base) has already been marked as a duplicate of this issue.

Thanks for the cleanup. I now completely approve of the writing style of your patch, and I concur with what you said about Windows.

I have also used this method to get subdirectory multi-site working, and I do think that creating a symbolic link is a necessary step.

So, I vote for getting this in.

I think probably at least one other person should look at it before going for RTBC -- you might ask on IRC.

errrr...? It looks like all of you don't know of the new site aliasing feature yet? Have a look into ./sites/example.sites.php ... ;)

Would you care to write something up about this for the install.txt?

bump... there's an effort underway (RTBC) to rewrite install.txt for clarity etc. Once that's done, we should revisit this issue, and see if the multi-site section needs attention.
#952606: INSTALL.txt needs correction and clarification

Subscribing - I'll try to look this week at this, if I have the time.

Subscribe

I don't get the whole issue. Or at least I am not sure if I do. Can somebody summarize, please! I'll give it a try:

1. Is there still a code issue left or will it be enough to just change the text?
2. What about sun's comment? Is it worth it to follow up the aliasing feature from sites/example.sites.php?
3. The patches proposed above proposes to change INSTALL.txt, but should we also change text in default.settings.php?
4. I am not sure I understand the proposed text, e.g.

   +For sites that are installed in subdirectories, it is likely you will need to

   subdirectories of what? Subdirs of the main site dir like this?
   

   sites
   sites/example.com.one
   sites/example.com.one/subdirectory
   

   Do we really have to care for this less than normal setting in INSTALL.txt? Would be fine on a handbook, if you ask me.

5. BTW: Something similar to symbolic links does exist now in Windows (since Vista I believe).
6. If at all shouldn't we not link to example.com.site3 to make it more druaplish and avoid the other remark?
7. What happened to $base_url = 'http://my.local/dir1';?

- We're only talking about updating INSTALL.txt here... I'm not sure what should be changed in default.settings.php? We just want to make sure it's clear how to set up multi-site installations.
- I think it's worth talking about using the sites.php file.
- Subdirectories mean separate Drupal sites that are at URLs like example.com/subdirectory, as opposed to subdomains, which are subdomain.example.com, and it's actually not all that uncommon. It does need to be covered. The INSTALL.txt says what sites directories you need, which are sites/subdomain.example.com and sites/example.com.subdirectory, not what you listed.

Not sure about your other comments... Anyway, someone who has a full understanding of all the possible considerations in making multi-site Drupal installations should be writing this update. That's probabaly not me...

yeah...sub directories dont work. Sub domains do.

/me no frustration
/me tough man

sudo killall apache2

subscribe...