Multi-site or Multiple Drupal Sites

Drupal provides several different options when creating multi-site installations. Each presents its own set of benefits and drawbacks. Let's go through a few combinations we've explored for some of our clients:

1. A Single Drupal Site with Community Modules

This technique brings together data from all sites involved into a single set of database tables. Security policies, content, navigation, and user information would be managed by the community modules. This would result in a single Drupal site with centralized source code and a consolidated database with separate content spaces created using group-based modules provided by the Drupal community.

2. Install Individual Drupal source code per sub-site

This technique would duplicate the Drupal source code and database for each department site. The result would be duplicate Drupal source code, modules, media, and database for every sub-site.

3. Single Drupal Source code per sub-site

This technique would provide multiple sites using a single Drupal source code tree. Each sub-site would have separate database tables shared within a single database.

In regards to number 1, some of the things that recommend it are totally automated group creation, which reduces the need for technical personnel when a new sub-site is needed. Also, it provides a consistent security policy, features, and display of information.

However, there are a few things that may be considered drawbacks, depending on the project's requirements. There is no clear way to change the theme from sub-site to subsite, because all sub-sites would be within a single Drupal instance. Also, any change to the security policies, settings or features would require custom development to integrate into the group community modules. Group modules may have a specific work flow, that wouldn't support changes requested by a particular sub-site.

The second option would reduce any possibility of corruption from another site. It would also allow total freedom in customizing each sub-site with new modules and themes without affecting other sub-sites, as each would have its own separate database tables.

The drawbacks from this method are tied to that separation between the sites. There is no easy way to update modules and source code. This could easily become unmanageable if the number of sub-sites begins to grow.

The final option provides consolidated source code for easy updates to all sites, but includes the benefits of having the database tables separated from each other, so that themes and security configurations can differ from site to site. It also provides a framework through which data can be shared between the sub-sites.

The major drawback of this setup is that since the source code is shared, an error that affects one site will affect them all. Of course, this is true of almost all shared hosting solutions.

Please contact Swipht to discuss a custom multisite strategy that will work for you!