As we have seen, there is more than one way to map multiple sites onto one server. Do we use Apache with virtual hosting? Several virtualized servers on a single physical server? Machine instances in a cloud? Or do we do it with Drupal itself? Each method has its own advantages and limitations.
In this book we are going to focus on just one strategy. We are going to examine how to use Drupal's built-in multi-site support to take one instance of Drupal and serve more than one site. If you are using Drupal for your web CMS, there are some distinct advantages to this method:
The combination of added features and simplified administration is a boon for would-be multi-site administrators. But there are a few drawbacks to using Drupal's multi-site method, and these should be considered before you begin building a multi-site installation.
In fact, there are two limitations that deserve very clear mention:
Security: Since the sites in a multi-site installation share the same code (and the same directory locations), they share the same files. Thus, if a person has access to the server's file system for one site, that person has access to the same files that are used for all of the sites on that multi-site installation. This makes it a less-than-secure fit for cases where different people are managing different sites.
Sharing: While Drupal's multi-sites share the same Drupal source code, they do not share the same database data. Nodes, users, and comments in one site are not accessible to the other site. Typically, this is a good thing, but in situations where you want sites to share information, this can become a hurdle that multi-site was not designed to clear.
If security between sites is an issue for your configuration—if the different sites are managed by different people—then Drupal's built-in multisite is not the best solution for your needs. Instead, consider using something like Apache's virtual hosting, with each site getting its own distinct Drupal instance. While you will lose the advantages enumerated above, your sites will be protected from mishaps.
On the other hand, if your sites need to access each other's data (or if you really have one site that listens on multiple domains, but serves the same basic content), you may be better off with another Drupal configuration. The powerful Domain Access module for Drupal (http://drupal.org/project/domain_access) provides a sophisticated suite of tools for building a single Drupal site that handles different domains. Domain Access is a complex module—a topic worthy of another book this size—so it could not be covered in this book. The best place to start with Domain Access is on the site given above.
Note
It is possible to configure multiple instances of Drupal to share common database tables, but this is not only a complicated setup, but also one with known security and stability issues. This is discussed in more detail in the last chapter.
The sweet spot for Drupal's built-in multi-site support is handling multiple distinct sites (each with its own content, users, and so on) while sharing a single code base. Modules, themes, and even to some extent files can be shared in a multi-site configuration. But nodes, users, and comments are not shared. Later in the book, we will see some ways of sharing a limited amount of data (such as allowing users to log in to all sites using the same username and password). This sharing, however, will not achieve the same level of flexibility that the Drupal Domain Access module provides.
It is one thing to state the advantages and disadvantages to Drupal's multi-site feature, but another to determine whether or not Drupal is a good fit for your own needs. Here is a quick guide to determining whether Drupal multi-site is the right choice for a given scenario.
|
Goal |
Method(s) |
|---|---|
|
Multiple sites should share the same code, but have separate data |
Drupal's multi-site configuration |
|
Multiple sites should share no code or data, but live on the same web server |
Virtual hosting with the web server |
|
Multiple sites (or domains) should share the same code and the same data, though they may have different layouts and styles |
Drupal with the Domain Access module |
|
Sites should not even share the same operating system or file system, but should run on the same hardware |
Virtualized servers or cloud platforms |
Again, this is a book about using Drupal's multi-site support and these other three methods are not covered. But Drupal itself can run in any of the environments mentioned above. If you're interested in the other three configurations, you may find it best to start at http://www.drupal.org/documentation and read the documentation, or head to http://groups.drupal.org and find others with similar needs to your own.
So far we've been focused on what multi-site hosting is about and which configurations are right in which scenarios. But now it's time to narrow the focus and start working on practical matters.