To summarise my setup:

* Drupal is installed into the root of the first domain www.lightbeingcreations.co.uk with it's own database
* I've changed the web directory for my second domain www.lightbeingcreations.org to point to host/username/lightbeingcreations.co.uk within my DreamHost control panel
* Sub-folder for second domain created within the sites folder, into which I have copied & edited the setting.php file to indicate the seperate database for this domain

When viewing www.lightbeingcreations.org I get a page full of errors that seem to be that the tables haven't been created for the database for this site. So I don't know how to create those as I thought they were created automatically by drupal.

If I set the web directory to host/username/lightbeingcreations/sites/lightbeingcreations.org then I just get the contents of that folder listed

I'm wondering if I need to set up symlinks, but I'm sure that's not needed with Dreamhost.

Suggestions folks?

Comments

vjordan’s picture

You need to install drupal on the lightbeingcreations.org domain. Although the drupal files are there, the installation script still has to put the tables into the appropriate database for that domain.

When you go to: www.lightbeingcreations.org you ought to get the installation script But it looks like this is being redirected to the .co.uk domain. Are you sure the base_url in the settings.php for this second domain is correct?

mfh’s picture

I also had this problem.
I don't know if $base_url must be edited and whether this solves the pb.
For me, the install worked fine by typing the address : www...org/install.php

Dubber Dan’s picture

vjordan - I did have to change the $base_url to point to the domain in question. I thought it was to go to the base url for the main drupal install

mfh - yep, just run the install script and tis working at last

The drupal instructions aren't very clear in a few points, so here's a summary of what was needed to get a multisite install working when hosting with Dreamhost.

The scenario
Two or more websites/domains sharing a single Drupal codebase, each with it's own MySQL database

How to setup
1. Create MySQL databases for each domain

2. Install Drupal into the root of the main domain (ie the first domain you're setting up, domain1 in this example) and test it works correctly

3. Within Manage Domains of your DreamHost control panel, change the Web Directory location for the other domains that are to be sharing that initial Drupal codebase (ie. /host/username/domain1) remembering to leave off the www. if you're domain is viewable without it

4. FTP to the Sites directory of your first Drupal install and create a sub-directory that matches the name of each additional domain (ie. /domain1 /domain2 etc)

5. Copy the settings.php file from the default directory to each of these new directories

6. Edit these new settings.php files as per the Drupal install.txt directions so that

$db_url = 'mysql://username:password@localhost/databasename';

You will most likely find that you do not need to edit $base_url =

7. In Firefox/IE/etc browse to www.domain2.com/settings.php and the Drupal install should run to configure you database tables

8. Browse to www.domain2.com and you should now be presented to the initial screen at which point you need to create your first user

Although some of these steps may only apply if you have the same setup as DreamHost, the vital step that seems to be missing from the Drupal INSTALL.txt is step 7. Without that, the tables are not created in your seperate databases for the additional domains.

vjordan’s picture

Dubber dan, You're now up and running which is a good thing.

Remember base_url is the address at which a user will access the website. It's not a pointer to the drupal source files.

Your instructions above may have a couple of typos which are important to note should somebody else come across this.
#6 - base_url will have to be edited for a separate website to come up on the second domain.
#7 - you probably mean /install.php not /settings.php. (Either way it's been reported elsewhere, by folks who know a lot more than I do, that you shouldn't have to specifically call /install.php. Personally, I prefer invoking install.php when I want to do an install.)

Dubber Dan’s picture

Aye was meant to be install.php in step 7 (I can't seem to follow your link to further info) but it certainly wasn't automatic for me and did need running.

As for step 6, thanks to you I now realise that base_url is the location of the domain in question and not the main drupal codebase. But it doesn't necessarily need to be edited. I had it edited originally, but reading the comments above it in settings.php it says it's optional, so I tried it without, and hey presto it works fine without on DreamHost.

fossilfool’s picture

Hi, I'm also having trouble getting multisites up and running.

Is Cpanel any different from dreamhost?

I've created the a folder in the sites directory called "sandbox" and copied settings.php there, changed the db settings to my new mysql database, and changed base URl to "example.com/sites/sandbox". I also tried "example.com/sandbox"

So, my question is, what is the URL that I am supposed to type to install the sandbox installation of drupal?

I have tried "example.com/sandbox" and "example.com/sites/sandbox". These both produce a Views error within my current install.

Your help is appreciated.

Paul

www.fossilfool.com and www.worldbike.org
Bicycle entrepreneur, inventor, musician, advocate.

Dubber Dan’s picture

It certainly is. The DreamHost control panel was built by them, where as cPanel is a solution many hosts used. My old host used cPanel, but I didn't try a multisite setup until recently moving to Dreamhost.

I think, but my be wrong, that if your host uses cPanel you're most likely to need to setup symlinks for your multisite

fossilfool’s picture

The following three methods have something to do with multi-site installation:

- adding 'Symlinks'
- .htaccess
- bootstrap.inc

Questions: Which of these is necessary for a 5.0 multisite installation.
Which of these can I do through Cpanel?
Which of these is necessary for a subdomain multisite? a subdirectory multisite?

Any help here would be appreciated.

www.fossilfool.com and www.worldbike.org
Bicycle entrepreneur, inventor, musician, advocate.

Dubber Dan’s picture

They are applicable in some multisite installs for both 4.7 and 5.0, but with my host (DreamHost) I didn't need to involve any of those things. So it does depend largely on your host, how they set things up and what sort of access they give you.

As for cPanel my host doesn't use it, but I have read other threads for users who are on cPanel so have a search for some of those

Drupal doesn't make much distinction between subdomain or subdirectory multisite installs, the principles used are the same

vjordan’s picture

Paul - it's not clear to me what you are trying to achieve.

Bear in mind the following:

  • Base URL is the URL that your user will use to access any given instance.
  • An entirely separate install, in a separate directory is often better for a test / sandbox site. You can do what you like with the modules and themes and not risk messing with your production site.

But if you want to have two sites hanging off the same drupal files then in summary you could try to do something like the following:

  1. Decide on the URLs you want to use. e.g. test.example.com and 'www.example.com'
  2. Install drupal into a suitable location.
  3. Use your control panel to ensure your chosen URLs point to the same place in your filesystem. (In some situations, including my own, you have to ask your hosting provider to do this for you.)
  4. Create the databases.
  5. Create directories sites/example.com, sites/test.example.com with settings.php files present
  6. Go to 'www.example.com' and follow the installation prompts - base URL will be 'www.example.com'
  7. Go to test.example.com and follow the installation prompts - base URL will be test.example.com
jakes’s picture

I finally got this to work with subdomains

www.site1.example.com
www.site2.example.com
www.site3.example.com

What I needed

  1. subdomain redirection in cpanel
  2. symlink
  3. not editing settings.php
  4. blank settings.php forces install script to run (which creates tables)

Set up best practices folder structure http://drupal.org/node/53705
...drupal/sites/www.site1.example.com

.

1. Simple subdomain redirection in cpanel - I don't know other hosting services gui's
in cpanel go to subdomains (not redirects) create subdomain www.site1.example.com then setup redirection to www.example.com - you will know if you have succeeded by the creation of a folder in public_html that is the name of you new subdomain (site1 in my example)

2. Delete that file (in my example: site1) and replace with a symlink. I had no access to ssh so i downloaded a php script www.psychogenic.com/en/products/PHPsh.php (thanks to fili for that - cron works too I guess) how do you run it? Put it up on you server with a ftp client. Use cpanels file manager to find it (in file manager: left column browses - right column selects) and by clicking on it's name and selecting it you will see that cpanel creates a link on the upper right that you can then click on that runs the page. You will get and error with an ip address copy the ip and back your browser up and reselect the phpsh.php file click edit and replace the ip in quotes where you see $MyIPAddress = '127.0.0.1';. Try rerunning the phpsh.php file. To enter in the ln -s command to create the symlink here is a command that worked for me
ln -s /home/user/public_html/site1/ /home/user/public_html/drupal/sites/site1.example.org
this creates a new site1 file - you can test it by opening it with your ftp client (...public_html/site1) and it should miraculously open up into you drupal folder -- so summarizing this step: the file you deleted should be your first argument in the ln- s command and will be created at /public_html/site1 and the subdomain still points at /public_html/site1 which now passes it on to the settings.php in /sites/site1.example.com

I grabbed a backup of settings.php from /sites/default - I then was able to run the install on the first subdomain by simply putting in www.site1.example.com into my browser but then I ran into pages of errors as I tried www.site2.example.com - it was looking for tables from the previous install so I put the settings.php from default (which had the info for site1 in it) into my ...drupal/sites/site1.example.com folder then put a clean copy of settings.php back in the default directory and reran the install for site2 by entering www.site2.example.com in my browser and repeated settings.php swap

I created 3 installations on one mysql db, by the way, by prefixing under advanced options during install site1_ then site2_....it's like free beer!

jake

Mojah’s picture

I've got a simillar setup but wish to share content between sites, as well as user tables. Each sub-domain will be a different language and I know that there are certain tables which should not be shared like cache and I'm thinking watchdog. Maybe the variables table as well. Any suggestions on what other tables should not be shared?

Quint’s picture

I am setting up a Drupal multi-site right now too. I don't want to share the content across the subdomains, just the users.

I want all users to be able to bounce around from sub-domain to sub-domain without users having to re-login. But I want the content to stay in it's own sub-domain. I want to use multi-site to effectively break up a big site into several sites by topic. Like

dogs.example.com only the dog articles
cats.example.com only the cat articles
fish.example.com only the fish articles

Is there a module for this, or do I just need to share certain tables?

Here are the tables that show up in phpMyAdmin

* Browse access
* Browse authmap
* Browse blocks
* Browse blocks_roles
* Browse boxes
* Browse cache
* Browse cache_filter
* Browse cache_menu
* Browse cache_page
* Browse comments
* Browse files
* Browse file_revisions
* Browse filters
* Browse filter_formats
* Browse flood
* Browse history
* Browse menu
* Browse node
* Browse node_access
* Browse node_comment_statistics
* Browse node_counter
* Browse node_revisions
* Browse node_type
* Browse permission
* Browse role
* Browse sequences
* Browse sessions
* Browse system
* Browse term_data
* Browse term_hierarchy
* Browse term_node
* Browse term_relation
* Browse term_synonym
* Browse url_alias
* Browse users
* Browse users_roles
* Browse variable
* Browse vocabulary
* Browse vocabulary_node_types
* Browse watchdog

A few like

_role
_access
_user

seem pretty likely, but I haven't found any list of the ones needed to share, so maybe I'm not thinking about this the right way. Or maybe theres a module for this?


I found this:

http://drupal.org/node/22267

Home » Installation and configuration » Basic site configuration » Database table prefix (and sharing tables across instances)

Table prefixing may be optionally applied to some tables and not others. This has the effect that multiple Drupal installations can share common tables. One interesting application for this is to share the taxonomy tables (vocabularies, term_data). Another interesting use is to share users across Drupal installations.

In order to use this capability, create two drupal installs in same DB using different database prefixes. In this example, one is prefixed 'master_' and the other 'slave1_'. Then edit the conf.php file of 'slave1_' so that it points some tables to the 'master_'. For sharing users, add the following:

$db_prefix = array(
"default" => "slave1_", // the prefix for tables that are not shared.
"users" => "master_",
"sessions" => "master_",
"authmap" => "master_",
"sequences" => "master_"
"profile_fields" => "master_",
"profile_values" => "master_",
);

but my database doesn't show "profile_fields" nor "profile_values" so I'm wondering if this article is old?

===


Then there is this this from the downloaded singlesignon.module:

http://drupal.org/node/50418
----------------------------------------------------------------------------------
/**
* @file
* Enables "Single Sign-Ons" between related Drupal sites on one server
* with a shared database.
*
* Installation and activation are simple:
* + Put this file in your modules directory.
* + If you haven't done so already, create site sub-directories in the
* "sites" directory for each of your domains. Put "settings.php"
* files in each of those directories. Edit each of the settings.php
* files to values appropriate for the given domain.
* + Make sure the "$db_prefix" variable is set correctly in each
* settings.php file (see details below).
* + Create the site specific and shared database tables defined in the
* "$db_prefix" variable (see details below).
* + On each site, starting with the master site:
* + Log in as administrator.
* + Enable the "singlesignon" module
* (via the checkbox in the administer | modules interface).
* + Enter the URL of the master site
* (via administer | settings | singlesignon).
* + Delete cookies from all of your Drupal sites.
*
* This module relies on several tables being shared between the master and
* slave sites. Here is an example of the "$db_prefix" variable you need to
* establish in all of your "settings.php" files in the "sites" directory.
* Each site should have a unique name in place of "somesitename_". While
* you can rename "shared_" to something else, the prefixes must be the
* same for all sites.
*
* @verbatim
* $db_prefix = array(
* 'default' => 'somesitename_',
* 'authmap' => 'shared_',
* 'profile_fields' => 'shared_',
* 'profile_values' => 'shared_',
* 'role' => 'shared_',
* 'sequences' => 'shared_',
* 'sessions' => 'shared_',
* 'users' => 'shared_',
* 'users_roles' => 'shared_',
* 'users_uid_seq' => 'shared_', // for pgsql
* );
* @endverbatim
*
* @link http://drupal.org/project/singlesignon
* @author Daniel Convissor
* @version $Revision: 1.21.2.2 $ (DRUPAL-5)
*/
--------------------------------------------------------------------------

This contains the extra bold fields.

I'm not sure what the advantage would be to the singlesignon module. Does it allow more control or something? I don't want to worry about updates to the module down the road, so it seems better to just share tables. I just need to figure out which tables to share.

thanks,
Quint

I posted this in the D.org forum too -=> http://drupal.org/node/125065 , in case any wisdom pops up there.

Mojah’s picture

...the localizer module. It occurred to me the other day. Localizer ( http://drupal.org/project/localizer) , can separate content based on sub-domains. Lets say your default language is English and the content for this is on name.com. The content for spanish would be displayed on es.name.com. Each node, vocabulary, site variables (site name, mission etc.) has a translation stored in localizer tables. A separate translated node is created for each original node. But you would also be able to create nodes in one language only.

So how does all this tie up to sub-domains with separate content? Well if you had to create different custom languages based on the core locale module; for example custom: dogs_english, cats_english, cows_english etc. and assigned each custom language the en-us or en international language code, then configure localizer to switch language by host name, Drupal would display only the dogs_english content in the dogs.name.com and the cats_english content in the cats.name.com sub-domains.

You would not have to share any tables, just have a multi-site setup using one database with no prefixes. Users would be able to login at any sub-domain and carry their information accross sub-domains.

It sounds like a nice idea, but requires some testing. If it works, localizer will provide an awesome (really really awesome) way to manage multi-site installations using one db without prefixes.

By the way, the profiles table will only show once you enable the profiles module in core.

Quint’s picture

This is a very interesting and creative idea.

I guess there are several ways to approach this:

Internally setup Drupal to share the users (roles, etc.) with the correct tables -- table prefixing

Externally share the users -- single-sign-on, CAS, LDAP, etc.

Keep it all in one database, but limit what content is displayed on what domain -- muti-domain, localizer

This makes me wonder if there's an even easier way to do this (without modules) with URL aliasing or controlling the menus with taxonomy, or something.

I'll have to fiddle around with this. Thanks Mojah.

Quint