Building Multiple Drupal Sites from One Database

LEGO men start building a Drupal SiteA Quick and Dirty Solution

I’m sure a better solution has come around since I put these few lines of code in action a couple years ago, but here’s a quick and easy way to make two Drupal “sites,” with different domain names (or a subdomain), behave as relatively independent sites, but share the same database.

Why?

You might be able to get away with styling a chuck of your site to appeal to one segment of readers, while another part appeals to a broader audience, but in order to completely differentiate the two (while still being able to share resources such as content, user table, modules, etc.), a pair of domain names provide two points of entry. This allows each one to have it’s own identity, but makes the single site, acting as two, much easier to manage. Administrators or content contributors that need access to both “sites” will be able to take care of business from one interface. Keep in mind that both domain names need to point to the same Drupal installation.

Structure

Drupal’s use of theming allows for easy customization at multiple levels of the site. Each piece of content in Drupal is called a “node.” Nodes can be categorized by content types. The default types allow for pages, stories and forum topics. But using an additional module called CCK, users can create limitless custom content types, each with their own custom fields. The only point in explaining all this is to show that when dividing a site up into two sharing the same database, a different content type for each site needs to be used. Once that content type is defined, we can use a little bit of code in the template files to keep the pages for each site divided.

Method

Using page.tpl.php as a template, duplicate it and rename it with your content type substituted for “subsite.” This tells Drupal to use that template for pages that are categorized under the “Subsite” content type:

  • page.tpl.php – The generic template file for pages. Exists by default.
  • page-subsite.tpl.php – The content type that categorizes pages shown for the subsite.

Now we need to tell Drupal to use the “Subsite” template file when browsing a page of that content type. In the first part of your default page.tpl.php file, use the following PHP code:

$alias = drupal_get_path_alias($_GET['q']);
if (stristr($alias, "subsite-landing-page") == true) { include 'page-subsite.tpl.php'; return; }
if ($node->type == 'subsite') {include 'page-subsite.tpl.php'; return; }

$domain = $_SERVER['SERVER_NAME'];
if ($domain == 'www.subsite.example.com') {
include 'page-subsite.tpl.php'; return; }

The first part checks the path alias and looks for what you’ve named the landing page of your subsite (I will get to this later). Next, it checks the content type and switches to the Subsite template which can be developed to have a different look and feel from the default page.tpl.php template. The second part looks at the domain name and does the same.

On page-subsite.tpl.php, we need to tell it what to do when the default page template file points it in that direction. A mock landing page needs to be created so it will have somewhere to start, since this subsite homepage is different from your default one. Here’s the code needed:

$domain = $_SERVER['SERVER_NAME'];
$alias = drupal_get_path_alias($_GET['q']);

if ($domain == 'www.subsite.example.com' && $is_front) {
drupal_goto('subsite-landing-page'); }

Once again, it grabs the domain name and the page’s path alias. Second, it checks the domain, and points it to the landing page for the subsite. This will make your URL show something like “www.subsite.example.com/subsite” when on the subpage landing site, but can easily be renamed to keep it from sounding redundant.

Conclusion

There are a lot of options when it comes to configuring Drupal. The typical “multi-site” installation uses a shared codebase (the Drupal core), but a different database and configuration for each site within the sites folder. For purposes beyond this basic guide, users with more than two sites that need to use the same database should go with a set up that uses table prefixes in the database.


Photo by Gábor Hojtsy, Flickr.

About the Author

 Avatar

Jeffrey Stevens

Jeff Stevens is the Assistant Web Manager for UF Health Web Services. He focuses on user experience, information architecture, content strategy, and usability.

Read all articles by Jeffrey Stevens