Sites

Sites is a Drupal 6 module that segregates content and various settings based on domain, subdomain, or other path parameter.

Current features:
- Views that see content across all sites
- Views that see content on a single site
- Different active theme for each site
- Different primary and secondary links menus for each site
- Different front page for each site
- Set up sites based on domain, subdomain, path prefixes, and anything else that the PURL module can handle.

Forthcoming:
- Rules integration
- Features integration
- User integration
- Organic Groups integration

Sites was originally conceived as a way to make it easy to create multi-site Drupal configurations without the problems and complexities incurred by using Domain Access. Sites is a less-articulated solution than Domain Access: it has fewer features at present, and does not integrate as deeply into the Drupal access stack, but is consequently more stable. Most importantly, it avoids rebuilds of the node_access table, which can be slow (and, in the case of very large sites, can even cause your servers to grind to a halt).

There are several considerations that came into play in the decision to write the module. First, we wanted to be able to create multi-site installs of Drupal wherein some views could show content existing across sites, while others could discriminate between those sites and show only content from the current site. If we simply created a new folder under /sites, there would be no clean way to know at the level of the controller (nodeapi, Views, etc) what site was being used to access content. Furthermore, if we decided to segregate content into different databases, it would be difficult to share that content across sites (the easiest alternative would probably be to publish feeds, which seemed like far more trouble than should be necessary).

Second, for the sake of flexibility, I wanted to use Development Seed's excellent PURL module. Instead of forcing administrators to discriminate sites based only on domains (i.e. www.mysite1.com versus www.mysite2.com), PURL allows us to make distinctions based on other components of the URL. For example, we could have one.mysite.com and two.mysite.com, or mysite.com/1/node... and mysite.com/2/node.... This flexibility is important, as our clients frequently want to keep everything under the same top level domain, but change themes and show and hide content under certain subdomains or base paths.

In its first few iterations, the core functionality of Sites revolved around making the Context module react to elements of URLs (via PURL). Through this mechanism, you can enable and disable blocks, inject CSS classes, set the active menu trail, and do anything else that Context reactions permit -- all based on the currently active site.

To augment this list of capabilities, I've also written a plugin called Context Reaction: Theme with users of the Sites module in mind. Sites allows us to trigger different Contexts, and CR:T allows Contexts to trigger themes. Therefore, it's now possible to have two different sites rendering content using two different themes. Sure, we could conceivably use CSS magic to accomplish a similar end in certain scenarios (body.section-one-... ), much as we do on the various components of the Seventh Generation site. However, this allows us to keep big unrelated blocks of CSS separate. After all, site 2 should not have to override site 1's CSS -- they should both simply override a base theme.

Sites also allows you to set different primary and secondary links menus per site. This is accomplished with a template_preprocess_page hook as well as Strongarm integration (courtesy of nquocbao, a brand new co-maintainer). You can also set a different front page for each site (this is most useful when you set PURL to discriminate on the level of the domain or subdomain).

As development progresses, we expect to add User integration (so that users can only login to certain sites), more Views integration (namely, a Site ID argument), Organic Groups integration, Rules integration (if on site X, do Y), and Features integration. Keep an eye on the project page: http://drupal.org/project/sites ... this should be exciting!