Multi-Headed Drupal

by Larry Garfield

Thursday 23 August 2012

@Crell

Senior Architect, Palantir.net
Drupal Association Advisor
Web Services & Context Initiative Owner
Co-Author,
Drupal 7 Module Development,
Packt Publishing
Architectural Gadfly
Nerf Gunslinger

What we do

Multi-Headed Drupal

Case study

Drupal University

3[0] Colleges
4[0] Departments each
Over-worked IT department wants to keep things simple and centralized
Departments want to be special snowflakes

I hate my life...

How do we do that?

Let us count the ways...

The purpose of this session is to confuse you with options, then unconfuse you with guidelines

Not rules, more like guidelines

Separate sites

Never mind, KISS
Give everyone their own Drupal

Separate sites

Benefits

Standard platform
No added complexity
Complete freedom for each implementation
Mixed Drupal versions

Drawbacks

No economy of scale
No (intrinsic) standardization
Many sites to have to manage

Features.module

Dump configuration to code
Packages of functionality
Easily distributable (Sometimes)

Install profiles

Since Drupal 5
Quasi-modules in Drupal 7
All the power of a module...
- Hooks
- Alter hooks
... plus install wizards
- Create content types
- Create content
- Create roles
- Create users
- Set variables
- ... Do anything that has an API

Install profiles

+

Features

=

Distributions

A web application built with Drupal
Examples:
- Open Atrium
- Managing News
- Drupal Commons
- OpenScholar
- Conference Organizing Distribution (COD)
- Open Academy
- Your custom distribution here
Many many more...

Example: Field Museum Microsites

Install profile for major exhibitions
80% of a site in-a-box
- 10 content types
- Media, WYSIWYG, text formats, user roles etc.
- Common navigation

Multi-site

Drupal feature since at least 4.5
One code base, many sites
"Separate sites with shared code"

/
  sites/
    default/
      settings.php
    www.drupal.edu/
      settings.php
    biology.drupal.edu/
      settings.php

Multi-site

sites/sites.php

      $sites['www.drupal.edu'] = 'main';

      $sites['fapi.api.drupal.edu'] = 'fapi';

      $sites['multisite.building.drupal.edu'] = 'multisite';

      $sites['fundraising.drupalassociation.com'] = 'da_fundraising';

/
  sites/
    sites.php
    default/
      settings.php
    www.drupal.edu/
      settings.php
    fapi/
      settings.php
    da_fundraising/
      settings.php

Multi-site

Benefits

Same as Separate Sites, plus...
One codebase to update
Lower memory overhead (APC)
Table sharing (but don't do that!)

Drawbacks

Same as Separate Sites, plus...
Only one core version
Multiple module versions are hard

If you have one server admin team...

... use Multi-site

If you have many server admin teams...

... use Separate sites

Example: Washington University St. Louis

Drupal 6, Pre-features
Partially built database dump
4 themes to choose from
Clone DB, flush cache, create settings.php, customize

But you probably don't mean multiple sites anyway...

Domain Access

Access Control module
Node grants (here be dragons)
Domain == subsite
Affects node view
Suite of modules

Domain Access: Basics

Domain Access: Settings overrides

Domain Access: Themes

Domain Access: Timezones

Domain Access: Node editing

Domain Access

Benefits

One site to manage
Content sharing
Per-domain theme
Some system configuration per-domain
Consistent architecture

Drawbacks

Consistent architecture
Must use multiple domains
Uses node access
Single point of failure
Everything gets a little bit more complicated

Example: Environment America

One install with Domain Access
National site, various state-level sites
Easy content syndication
Way cheaper than many separate sites

Organic Groups

Very old Contrib; totally rewritten for Drupal 7
Any entity == "group"
Any entity belongs to a "group"
Users join groups

Organic Groups: Access control

Per-group Roles
Per-group user membership
Per group node/field edit/delete permissions

Organic Groups: Integration

Views plugins: Included
Ctools/Panels Context plugins: Simple
Very good Chaos suite integration

Organic Groups: Group nodes

Organic Groups: Permissions

Organic Groups

Views plugins: Included
Ctools/Panels Context plugins: Simple
Very good Chaos suite integration

Organic Groups

Benefits

One site to manage
Content sharing
Per-group theme
Only one domain
Consistent architecture

Drawbacks

Only one domain
Consistent architecture
Still site-wide settings
Single point of failure
Everything gets a little bit more complicated

Example: Mystery University (in progress)

Every College or Department is a Group
- Group node has hidden settings (default slideshow)
- Lots of Entity Reference
Panels Everywhere
Panelizer
Separate roles per department
Very similar themes

Single-site

Just because it's different sites now doesn't mean it has to be

Just because you call it a "site" doesn't mean it is

What does "site" mean?

A presence on the web
An organization's home page
A path root
"What I have access to"

Access control: Workbench Access

Divide site into administrative sections
Sections != path (unless you want it to be)
Assign roles or users to sections
Affects edit, not view

Variable themes: Options

Sections module (D6, needs port)
Panels
Panels Everywhere
hook_custom_theme()
... Or just don't

Single-site

Benefits

No/little mental overhead
One code base to manage
Easy on the server admin and site-admin

Drawbacks

Limited variability between "sites"
Public understands only a single "site"
Single navigation hierarchy

Example: Mt. Holyoke College

Many departments, centrally managed
Workbench access
All departments have the same design

Mix and Match

Multi-site can host any combination of sites

Multi-site / OG
Multi-site / Domain Access
Multi-site / Workbench Access
Multi-site / Domain Access / OG

Example: Barnard College

50 departments and programs
One site with Domain Access
... and Workbench Access for even finer control

Decisions, decisions...

If you want...	Probably means...
Multiple core versions	Separate installs
Different content types	Separate installs, multi-site
Single user base	Domain Access, OG, Single-site
Subdomains	Separate installs, multi-site, Domain Access
One domain	OG, Single-site
Simplified server administration	Domain Access, OG, Single-site
Shared content	Domain Access, OG, Single-site
Per-department ACL	Single-site, OG
Department autonomy	Separate installs, multi-site (maybe OG)
Per-department Views	Separate installs, multi-site (maybe OG)
Staggered migration	Separate installs, multi-site, Domain Access, proxy server shenanigans
Per department theme	Separate installs, Multi-site, Domain Access, OG
Inexperienced site admins	Separate installs, Single-site

Remember what we said about guidelines