“Setting up multi-sites is an easy task that requires just minutes” …or so I thought. "Welcome to Multi-site Hell!"
Several frustrating hours later and after reading and rereading and yet again rereading the instructions.txt and several other posts, my multi-site installation remains a persistent “page not found” message.
Could someone please point out what it is I’m doing wrong? (This question could also be worded as, "Could someone please point out what hasn't been clearly explained?," but that just seems bitter)
Your comments and suggestions would be most appreciated. Here follows my information:
Drupal 4.7.2
Apache 1.3.33
PHP 4.3.11
MySQL 4.1.13a
Unix (Mac OS X 10.4.7)
Directories:
Default: sites/default/settings.php
New: sites/sicherungstechnik/settings.php
Default install settings:
$db_url = 'mysql://root:password@localhost/drupal';
$base_url = 'http://localhost/drupal';
New site settings:
$db_url = 'mysql://root:password@localhost/sicherungstechnik';
$base_url = 'http://localhost/sicherungstechnik';
When I enter http://localhost/sicherungstechnik into my browser, I get the original (default) site with a “page not found error”.
Note 1: This is all local
Note 2: Clean URLs: disabled
Note 3: I created a new database, hence the lack of database prefixes
Comments
I've set up a lot of
I've set up a lot of multisite installs. But as far as I know, if you want one or more of the installs to be a subdirectory rather than a seperate domain or subdomain, you have to create a symlink or some .htaccess work.
Domain vs. Directory / .htaccess and Subdirectories
Thanks for your comments Brenda.
Does this mean that I wouldn't have these problems, if I set up domains or subdomains? Am I needlessly creating these problems by choosing directories? Is this information documented anywhere in handbooks, or is this information something that simply pops up here and there in disconnected posts?
Regarding .htaccess, would you know what ".htaccess work" would need to be done? Is there a post for "modifying .htaccess for multi-sites subdirectories"?
you need to name the site
The notes in settings.php indicate that you must have at least some trace of a hostname left in the path in order for Drupal to find the file.
Notice that "org" never disappears in these examples. Try renaming your settings directory from sites/sicherungstechnik/ to sites/localhost.sicherungstechnik/
* 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
Thanks for your reply, but "page not found" persists.
I tried renaming the directory as suggested, but it unfortunately still doesn't work.
Should I also revise the base URL and the Url that I enter into the browser to find the site?
No, it's easier than that
You do not need a base_url declaration in settings. php as of 4.7, and you're much better off without it.
As several have suggested, your webserver is looking for a subdirectory and not finding it. This is not a problem when you serve multiple domain names from a single directory tree, but if you have a single domain name and multiple paths, you've created yourself a problem.
Here is how to fix it.
ssh to your webserver # or open a terminal window
cd to your docroot # usually htdocs, where you installed Drupal
ln -s . sicherungstechnik # notice the dot ... create a symbolic link back to the current directory
Now, when apache looks for docroot/sicherungstechnik, it finds docroot (unless it is configured NOT to follow links) and executes index.php correctly. Drupal then follows its documented rules for figuring out which settings.php to load and obey.
These instructions will work just fine with Unix/Linux/OSX. As for Windows, I have no idea whether Windows "shortcuts" work the same way.
All of this is MUCH simpler with multiple domains (rather than multiple directory paths) because the server can simple deliver everything from one directory tree, without needing any links to be created, and because Drupal's rules for that situation are easier to understand.
Just create sites/foo.example.com, sites/bar.example.com, et cetera, and place settings.php in each of those directories.
If you are running all of this on your personal computer and not making it available on the Internet (for testing purposes, for example), you can run multiple domains quite easily.
Just edit your hosts file and put the example domains in it, each mapped to 127.0.0.1.
The reason it works is that in HTTP/1.1 requests, a "host" line is included that tells the webserver the hostname that's being requested. Drupal uses that info in combination with the URI to figure out which settings.php to load.
What else have you done?
You can't set up multi site stuff without at least some tweaking of the web server or its underlying filesystem. This is because all requests to Drupal come through the web server and unless you configure your web server for this Drupal will never see the request.
You need to configure your web server so that it serves requests to both sets of urls from the same Drupal index.php file. And you need to set this up before bothering with settings.php files.
This means things like configuring virtual hosts, or aliases in Apache, tweaking .htaccess files or symlinking directories etc.
IMO the multisite docs should have a big notice at the top persuading people against it unless they understand how web servers work or why they actually 'need' multisite stuff in the first place.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal
Why?
I have four sites running off multi site and I don't know anything about any of that. This is what I do:
I have my Drupal install at public_html/drupalsites. I think most people have it at just public_html but I like to keep that neat. :)
Under drupalsites, I have sites/site1.org and sites/site2.org etc.
site1.org, site2.org, etc all point to public_html/drupalsites. That's the critical part a lot of people miss. When you do an add-on domain at the hosts I've been at, it makes a new subdirectory and points it there. If you can repoint it through your control panel, that's great. Otherwise, contact your host and have them point it to the right spot.
Oh, I just re-read and realized you said you're doing this locally. I'll leave this in case it helps, but it may be something to do with having the localhost in there that's confusing it.
Michelle
Indefinite Stay in Multi-site Hell
Thanks to everyone who took a moment to help. But sadly, it still doesn’t work.
I always stumble where Drupal relies too heavily on forums rather than usability design in the code base or clear documentation. I had a similar problem with site maintenance before the 4.7 release.
Therefore, I’m going to give up and move forward. I’ll revisit this issue and retry after some time has past. In the interim I hope for the following:
Multisite Handbook
Something more than what now exists, which is essentially a suggestion to reread instructions.txt or try the forums.
Multi-site Module
User Requirements
1. Enters site name
2. Selects database option: Share existing or Create new
3. Submits form
System Requirements
1. Creates directory in sites
2. Writes settings.php file
3. Modifies or creates database
4. Displays all sites for the corresponding code base
P.S. As a temporary solution, I've done a multi-install (2 full installations of Drupal).
The reason there is no one single set of steps
is that there is no way around tweaking your web server in some way, and there are many different ways your web server could be configured. The handbook can only really say what your web server will need to do, telling you exactly how get to that point depends on your specific hosting set up.
I think many newbies are better off doing two separate installs like you've done. It is more flexible and upgrades can be staggered easily. Drupal takes up very little space on the server anyway.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal
Multi-sites vs. Multi-installation
Thank you Styro, and I agree. If you’re having trouble configuring multi-sites, then you should consider a multi-installation. I spent several frustrating hours over a span of 2 days trying to get multi-site configured. When every attempt failed, I grudgingly abandoned multi-sites and simply did a multi-install. With that decision, I had my additional site up and running in 5 minutes.
The only disadvantage is that multi-installation requires a database for each installation. Luckily, that is not a problem for me, because I can create several databases. However, for those of you who are restricted to one database, you’ll need to upgrade your hosting account.
Good luck everyone!
Are you sure about that?
I haven't actually tried to use the same db with multiple installs... I don't even use the same db when doing multi site, but I don't think it should matter. Multi site or multi install, you still have a config for each site and you can point it at whatever db you want. You just need a different table prefix, which you'd need in multi site anyway if you're using just one db.
Sorry to hear multi site didn't work out for you. I didn't find it difficult at all but that's probably because I'm doing it on a hosted account so I don't have to worry about getting the webserver set up right or anything.
Michelle
Thanks for the correction Michelle
My latest thoughts on this matter...
The Drupal code base comes in at only 2.1 MB. If multiple installations can all share one database, as suggested above, then 5 installations would only set you back 10.5 MB. Yes, your single database may grow, but that would be the case under a multi-site or a multi-install.
Can someone please point out a clear advantage of multi-sites? It simply can’t be that you save 2.1 MB of disk space.
Advantage
With multi site, you have one code base to maintain. When it's time to upgrade, you upgrade one codebase. This is great for security fixes that aren't likely to break your sites because you can apply it in one spot and all your sites are upgraded. It's also nice if your sites use the same modules because you can upgrade them all at once as well.
Unfortunately, this can also be a disadvantage if you don't want to upgrade all your sites at once. I ran into this going from 4.6 to 4.7. I have a site that I really didn't want to do anything more with but it was part of the multi site so I had to upgrade that as well.
I don't think there's huge advantage for using one over the other. It's a matter of preference. If you've got it working with multi installs and don't mind doing multi upgrades, I wouldn't fight to get multi site working.
Michelle
One less common use case for multi site...
We use it, even though there is only one actual site as such.
We keep our Drupal codebase in subversion (a source control system like CVS) so that multiple developers/designers can work on themes and modules. Every developer or designer has a few virtual hosts (not subdirectories) to themselves on our internal development server for development and testing. We also have a test site (access restricted via IP addresses) and the production site on our internet accessible server.
We use Drupal multisite to create a 'site' for each development virtual host plus the two internet accessible ones. Each one points at its own database, and some modules only exist in a site subdirectory (eg devel for developer ones and notify for the production one).
With this set up we can copy our codebase to any server and it will automatically pick up the correct url and database settings. And we also have scripts to synchronise development versions with the latest data from the production instance (where the actual content gets created).
This set up would be overkill for most users though. Setting it up was more effort, but it makes ongoing development changes easier to handle.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal
Multisite vs DB sharing
As Michelle said, strictly speaking multisite doesn't have anything to do with sharing databases. This is a bit of a misconception.
The two concepts (although they can be used together) are independant of each other. You can have a multisite instance that shares one database or has independant databases or mixes up multiple databases with some shared tables. Likewise a single non multisite enabled Drupal install could still connect to another database or share tables etc (I'm not sure how well locking works in this scenario though - I haven't actually tried that out).
Multisite is when one Drupal code base can respond to multiple incoming url paths and optionally treat them differently (eg different settings.php files, or different modules and/or themes available). With multisite you could have two different virtual hosts ('sites') that served up the same content from the same DB, just with different themes depending on which url the visitor used etc. There are quite a number of different ways of using it for different purposes - which also makes it hard to document.
Sharing databases or just tables is an extra optional step.
But in my opinion, this stuff is only really for people that have a clear idea of why they want to do this (pros and cons etc) and what is happening under the hood. If they still want to hang in there, they just need to have some expectation of frustration and probably doing more background research (ie non Drupal info like webservers etc) than they anticipated.
And there is no disgrace with just setting up two independant Drupal instances - keeping things loosely coupled is a good thing when it comes to fixing problems or upgrading etc.
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal
I had similar problems, but here is how I managed to do it:
After I created softlinks just like yelvington suggested above, it stopped giving me an error, but kept relying on sites/default rather than on sites/mycoolsite.
If the path of your site is complex, like
http://localhost/~syquest/drupal/sicherungstechnik
the trick is to figure out where Drupal looks for the settings and other site-specific files.
You need to temporarily modify conf_path() in bootstrap.inc, and add this line:
print "checking dir: $dir
\n";
right after the line that says:
$dir = implode('.', array_slice($server, -$j)) . implode('.', array_slice($uri, 0, $i));
Later, go to your sub-site URL in your browser, and notice what paths corresponds best to your sub-site. That's how you should name your sub-site's directory in sites directory. Something like
localhost.~syquest.drupal.sicherungstechnik
Hope this helps.
Don't forget to un-do the print statement above.