conf_path using SCRIPT_NAME does not work for sub-directory multi-sites

Well, the REQUEST_URI is user provided data so it should not be used as-is. That's why we migrated to using SCRIPT_NAME. Why are you using 404s? The url rewrite should not go through any 404s.

Unless somebody confirms real breakage, this sounds like an Apache configuration issue.

No activity, Close..

We had a similar issue with a D5 site. We had to turn off clean-urls to get it working. Here is why:

Because we had to rely on mod_alias to get subdir-based multisites, the rewrite rules were taking precedance over the Alias rule. This is mentioned in the mod_alias docs at http://httpd.apache.org/docs/2.2/mod/mod_alias.html (see the "Order of Processing" section). Turning off clean-urls mean the rewrite rules from .htaccess will not take affect and let mod_alias handle the urls. This results in $_SERVER['SCRIPT_NAME'] containing the subdir name in its value.

So we now have a working subdir-based multisite with ugly-urls :-(

This is the documentation supplied in default.settings.php:

 * The configuration file to be loaded is based upon the rules below.
 *
 * The configuration directory will be discovered by stripping the
 * website's hostname from left to right and pathname from right to
 * left. The first configuration file found will be used and any
 * others will be ignored. If no other configuration file is found
 * then the default configuration file at 'sites/default' will be used.
 *
 * For example, for a fictitious site installed at
 * http://www.drupal.org/mysite/test/, the 'settings.php'
 * is searched in the following directories:
 *
 *  1. sites/www.drupal.org.mysite.test
 *  2. sites/drupal.org.mysite.test
 *  3. sites/org.mysite.test
 *
 *  4. sites/www.drupal.org.mysite
 *  5. sites/drupal.org.mysite
 *  6. sites/org.mysite
 *
 *  7. sites/www.drupal.org
 *  8. sites/drupal.org
 *  9. sites/org
 *
 * 10. sites/default
 *

This seems to be completely at variance with the current implementation (6.15 in my case) where it would seem it will NEVER work as advertised.

I came to the same conclusion as the original poster after inserting my own debug statements into conf_path following several hours of head banging and messing with sym links.

The documentation clearly shows thet the user input is used as the basis for the search but the implementation ignores the user input by design.

So, are sub-directory multi-sites actually supported? Can we have some definitive answer on that?

cheers.

Works perfectly for me, with the following in my sandbox.lab vhost configuration:

Alias /test-site /var/www/drupal

The following conf paths are tested:

sandbox.lab.test-site
lab.test-site
sandbox.lab
lab
default

Apache 2.2.12, PHP 5.2.10, Drupal 6.16

So your supplied URL in the first case is:

http://sandbox.lab/test-site

I can get multi-site sub-domains working with no trouble whatsoever, it's the sub-directory config that requires URLs like the one above that is the problem.

Updated:

Early days yet, but just tried the Alias statement in the VirtualHost definition and it seems to be making a big difference.

Update 2:

That does indeed make everything work.

Many thanks :-)

I'm also experiencing this bug, in which $_SERVER['SCRIPT_NAME'] contains /index.php, preventing sub-directory multi-site from working. For example, if I request http://drupal.example.com/subdir/, $_SERVER is populated with:

Array
(
    [REDIRECT_SCRIPT_URL] => /subdir/
    [REDIRECT_SCRIPT_URI] => http://drupal.example.com/subdir/
    [REDIRECT_STATUS] => 200
    [SCRIPT_URL] => /subdir/
    [SCRIPT_URI] => http://drupal.example.com/subdir/
    [HTTP_HOST] => drupal.example.com
    [HTTP_USER_AGENT] => Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.17) Gecko/20110302 Firefox/3.0.6 (like Firefox/3.5.17) GTB7.1
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5
    [HTTP_ACCEPT_ENCODING] => gzip,deflate
    [HTTP_ACCEPT_CHARSET] => UTF-8,*
    [HTTP_KEEP_ALIVE] => 300
    [HTTP_CONNECTION] => keep-alive
    [HTTP_COOKIE] => XDEBUG_SESSION=default
    [HTTP_IF_MODIFIED_SINCE] => Tue, 26 Apr 2011 20:22:25 GMT
    [HTTP_CACHE_CONTROL] => max-age=0
    [PATH] => /usr/local/bin:/usr/bin:/bin
    [SERVER_SIGNATURE] => <address>Apache/2.2.14 (Ubuntu) Server at drupal.example.com Port 80</address>

    [SERVER_SOFTWARE] => Apache/2.2.14 (Ubuntu)
    [SERVER_NAME] => drupal.example.com
    [SERVER_ADDR] => 192.168.1.2
    [SERVER_PORT] => 80
    [REMOTE_ADDR] => 192.168.1.3
    [DOCUMENT_ROOT] => /htdocs
    [SERVER_ADMIN] => [no address given]
    [SCRIPT_FILENAME] => /path/to/drupal/index.php
    [REMOTE_PORT] => 55555
    [REDIRECT_QUERY_STRING] => q=subdir/
    [REDIRECT_URL] => /subdir/
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => q=subdir/
    [REQUEST_URI] => /subdir/
    [SCRIPT_NAME] => /index.php
    [PHP_SELF] => /index.php
    [REQUEST_TIME] => 1303850227
    [argv] => Array
        (
            [0] => q=subdir/
        )

    [argc] => 1
)

Here's our workaround when Alias and Rewrite don't work well together for sites like:
http://same.domain/site-a/
http://same.domain/site-b/

RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteCond %{REQUEST_URI} ^/(.+?)/
  RewriteRule ^ %1/index.php [L]