1

Phase2 Review SeriesManaging Multiple Websites in Drupal

Why Multisite?

Rapid Deployment Functionality Standardization Maintenance Cost Efficiency

Native Multisite Implementation

Different URLs or Paths per Website Folder Naming Convention in the sites/ folder

Corresponds to URL/Path Shared Code: sites/all/{modules,themes}

for components that are on the same cycle! Websites can vary drastically in information

architecture and user interface, with similar core functionality

Native Multisite Implementation (cont.)

Different databases, with the ability to share selected tables users, locale_*, taxonomy, etc.

Websites can be deployed on different schedules. Similar to having N separate websites. Most useful with:

Common Installation Profiles. Synchronized Core/Contrib Updates

Subsites Custom Implementation

Information Architecture of all websites is identical Each website gets a slice of data from the main

pool of content. Data Items (nodes) can be selectively shared across

the websites All deployments must be synced. One database for all sites and content. Requires custom implementation.

Multisite Examples:

Subsites Examples:

Drag-n-drop Interface For Content Sharing

Condo Sites vs the Career Subsites

Condos Careers✴Same core functionality✴Independent release cycles.✴Different themes✴No shared data✴Separate SVN trees

✴Identical Functionality✴Identical IA✴Same theme layout✴Different slices of larger content pool✴Same release cycle✴Same SVN tree

Challenges with the Native Drupal Multisite

Not scalable: All sites must reside together

No flexible, content item-level sharing. Core/Contrib upgrades cascade to all sites

One Step Beyond....

One site per Drupal instance Share core/contrib code selectively

svn:externals git submodules symbolic links

Implement content-sharing approach from the “Custom Subsites”

Upgrades can happen on a site by site basis

3 Confidential

Questions?