Many Drupals

Presented by Larry Garfield (@Crell)

@Crell

Larry implements Huggable
  • D.R.I.E.S., Platform.sh
  • Drupal 8 Web Services Lead
  • Drupal Representative, PHP-FIG
  • implements Huggable

Formerly...

Palantir.net used to pay me!

Stop me if you've heard this one...

Drupal University

  • 30 Colleges
  • 40 Departments each
  • Over-worked IT department wants centralization
  • Departments want to be special snowflakes
Picard-Riker Face Palm

How can we square that circle?

Too many options

Not rules, more like guidelines

Not rules, more like guidelines

Separate sites

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)

And there's even a Drupal 8 version (That's a good thing!)

Install profiles

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

Install profiles

+

Features

=

Distributions

Distributions

  • A web application built with Drupal
  • Examples:
    • Open Atrium
    • Drupal Commons
    • OpenScholar
    • Conference Organizing Distribution (COD)
    • Open Academy
    • Panopoly
    • Your custom distribution here

Many many more...

Example

DEIMS

  • Drupal Ecological Information Management System
  • International Long-Term Ecological Research Network (ILTER)
  • Data collection site-in-a-box
    • Local team data
    • XML feeds to share data
    • No inter-dependence
Drupal Ecological Information Management System

Multi-site

Multi-site architecture

Multi-site


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

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

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

Drawbacks

  • 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

Modern deployment practices mitigate the first

Example

University of Minnesota

  • ~15 Installs
  • Many sites per install
  • 100s total
  • 2 install profiles
  • No features updates
  • Can have custom themes
University of Minnesota

You probably don't mean
multiple sites anyway...

Domain Access

Domain Access architecture

Domain Access

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

Domain Access: Basics

Domain Access: Basics

Domain Access: Settings overrides

Domain Access: Themes

Domain Access: Themes

Domain Access: Timezones

Domain Access: Node editing

Domain Access: Node editing

Domain Access: Node editing

Domain Access

Benefits

  • One site to manage
  • Content sharing
  • Per-domain theme
  • Some per-domain config
  • Consistent architecture

Drawbacks

  • Consistent architecture
  • Must use multiple domains
  • Uses node access
  • Single point of failure
  • Scales to low-tens
  • Everything gets a little bit more complicated...

Example

Interlochen Center for the Arts

  • One instance, ~6 domains
  • Shared theme w/ color tweaks
  • Easy content sharing

Organic Groups

Organic Groups

  • Rewritten for Drupal 7
  • Drupal 8 version in progress...
  • 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 Group Node configuration

Organic Groups

Permissions

Organic Group permissions

Organic Groups

Benefits

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

Drawbacks

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

Example

California State University Northridge

  • College or Dept = Group
    • Group node has settings
    • Lots of Entity Reference
  • Separate roles per dept
  • Panels Ev. / Panelizer
  • Very similar themes
California State University Northridge

Do you even need multiple "sites"?

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

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

What does "site" even mean?

What does "site" mean?

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

Single-site

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

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
  • ThemeKey for (some) theme switching
Mt. Holyoke College

Mix and Match

Mixed Multi-site with Domain Access

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
  • One site with Domain Access
  • ... and Workbench Access for edit 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 admin Domain Access, OG, Single-site
Shared content Domain Access, OG, Single-site
Per-department ACL Single-site, OG
Department autonomy Separate installs, multi-site (less so OG)
Per-department Views Separate installs, multi-site (less so OG)
Staggered migration Separate installs, multi-site, Domain Access, proxy server?
Per department theme Separate installs, Multi-site, Domain Access, OG
Inexperienced site admins Separate installs, Single-site

Remember: guidelines

Not rules, more like guidelines

Larry Garfield

Director of Runtimes and Integrations Platform.sh

Continuous Deployment Cloud Hosting

Stalk us at @PlatformSH

Thanks to Palantir.net for helping develop these slides