Hofmockel.org

ref: http://www.contractwebdevelopment.com/drupal-multisite-configurations-an...

How to Correctly Set up Drupal Multisite?

The ability for Drupal to run multiple sites from one account is a huge plus for admins that are deploying multiple Drupal installations. The simple reason for this is that all Drupal installations can be updated at once. Basically each additional domain "points" to the document root of your primary Drupal installation. All you need to do to update the files of each additional Drupal site is update the files in the root install once. Caution: Before deploying production sites in a multisite environment I urge you to read my notes on security below and updating multisite codebases.

Security

Before proceeding with these multisite installations please note that it's possible for malicious users of one site to access protected files of multisite installations if they are given the ability to run PHP code. For example, the normally protected settings.php file (which hides confidential database access information) of one multisite could be accessible by another by running the following PHP snippet:

Therefore it is vital that you follow the below guidelines:

• Only administrators of the multisites should have access to the PHP input format that would enable them to do this in the first place, and never give the owners uid = 1.
• If you need PHP input for users, run each user's php process as fast-cgi and only link their sites subdirectory from the primary installation.
• It's recommended that you use a Virtual Host setup to begin with. You can also set up chrooted Apache environments. A V-host will usually do this for you.

Individual settings and themes for each site

In addition, each site will have its own settings and themes. This is where the "sites" folder comes in. You place each additional multisite in the /sites directory as its own directory. For example, the domain example.com would be added in /sites/example.com. It will have its own settings.php file, and its own theme folder.

Separate databases for each site

In the settings.php file for each site you will enter the information for its respective database. This way, each multisite will run off its own database. In addition, each will have access to its own theme files.

Fully separated control for each multisite

Finally, when you log into example.com (multisite pointing to your primary domain), you will be able to select which modules it uses, which theme, and will have full control over its settings as if it were its own separate Drupal installation.

How to set all this up?

The key behind Drupal multisite installations is that your host must enable you to point your additional sites to your primary Drupal installation's document root. This can be done via domain parking, symlinks and virtual hosts.

Multisite via parked domains

It is also possible to implement a multisite configuration by simply parking the multisite domain on top of your primary domain. This may in fact be the easiest route to take. You can then administer emails for the parked domains as well as access their databases by logging in to your primary root's admin (Cpanel).

Steps to park a domain on top of another

Domain Parking Via Cpanel

To park a domain in Cpanel (Control Panel), simply click on "parked domains," add your domain, and it will be parked on top of the root domain. To unpark the domain go back to "parked domains," select which domain you wish to unpark from the drop-down box and select "remove domain."

Domain Parking Via WHM

To park a domain in Web Host Manager, go to DNS Functions, and click on "park a domain." From here you will be able to select a) the domain to park on top of, and b) the domain to park. To unpark the domain select "List Parked Domains" from Account Information, and click "UnPark" next to the domain you wish to unpark.

Multisite via symlinks

Symlinks point subdirectories at your root installation.

Configuration with shell access

First create a subdomain (ie. newsite.primary.com). This will create a new folder: /root/public_html/newsite. Delete the "newsite" folder, as it will be replaced by your symlink. Inside "public_html," create the symlink with the following code (shell access):

The symlink "newsite" now points to your document root (public_html) - voila!

Configuration without shell access

It is still possible to execute shell code without shell access. To execute shell code in Drupal, simply create a PHP page with the following and execute it from your root Drupal directory:

In this example the first path is the primary domain, followed by the multisite domain. PHP also has a symlink function you can use:

important: The first example uses backticks (usually to the left of the '1' key on your keyboard), while the second example uses single quotation marks. The backticks tell PHP to execute the code, which we need for the shell script, but in the symlink function we are simply inserting values into an existing function.

Multisite via Virtual Hosts

In order to use this method you or your host will need access to httpd.conf. Since this file controls the entire server this option is normally only available in dedicated hosting environments.

How to Update Multisite Installations?

This is a little more tricky, as multisite updating is not quite as smooth (yet) as you might first imagine. First of all, if you are still running 4.6, I recommend NOT deploying multisite environments that you plan on upgrading to 4.7+. The reason? The update process is tedious to the point that you might as well install separate sites. As for those installing 4.7 codebases, as I currently have the majority of my production sites running on, the upgrade process to 5.0 should work as follows, although I have yet to test this (I plan on doing so this week and will post back).

Upgrading from 4.7.x to 4.7.y in a multisite environment

The process involves replacing all the core files, and the running "update.php" on the primary domain. This will update the primary domain's database, but if you have your multisites set up with their own databases, you will need to update these independently. Simply run "update.php" from each installation. The problem with 4.6 upgrades is that this simply results in a blank screen (ie. doesn't work).

Using database prefixes

The alternative to setting up a separate database for each multisite installation is to assign all sites to the same database as the primary domain, but with their own table prefixes. So for example, for the users table you would have:

Multiple Databases

Single Database

An advantage prefixing gives you is that you can update all the multisites as once. The obvious disadvantage is that you have all your sites crammed into one database, which can make maintenance (backups) more tedious. Yet another advantage is that you can use this to implement shared functionality, such as allowing login sessions to authenticate across multiple sites.