Multis
- McCreary on multitenancy: “a simple solution to a complex problem”
- Me: “To make things simple, you must first make them more complicated.”
Multisite
References
What
- Run multiple WP sites with one WP installation (files & DB)
Who
- Institutions: to allow department/individual sites or blogs without each spawning another WP install
- e.g. WordPress.com, NYTimes.com blogs, colleges
- Developers: to consolidate management and resources
- Build shared library of themes and plugins
- Theme designers: to demo themes
- Testers
- Spin up a test site to try out a new theme/technique/etc without the drag of WP install
Why?
- Save time upgrading (single WP core)
- Share plugins and themes between sub-sites
- with individual site-level toggles
- Single database (if limited by host)
Why not?
- Sharing goes both ways
- can’t not upgrade all
- can’t mix plugin versions w/o instancing
- Difficult to split apart (e.g. domain migration)
- Heavier demand on single codebase (e.g. in shared hosting)
- No security separation
- only uploads folder broken out
- users have ‘subscriber’ access to all sites
How
- (Premade option) BitNami WordPress Multisite stack
- Check for Apache mod_rewrite and wildcard DNS support at host
- Choose site structure
- subdomain (example1.domain.com)
- requires wildcard DNS or multiple VHost lines
- requires folder root
- subdirectory (domain.com/example1)
- cannot set up > 30 days of WP install (permalinks?)
- less SEO friendly
- domain mapping
- network of networks
- Edit wp-config.php
- define (‘WPALLOWMULTISITE’, true);
- Run Dashboard > Tools > Network Setup
- Add generated lines to wp-config.php
- Edit .htaccess
- Go to Network Dashboard to add sites
Multi-tenancy
- aka the “McCreary Method”
References
What
- Run multiple WP sites with one WP installation (core files)
- Each site retains custom wp_content & DB
Who
- WP server admins
- Multi-site developers who host
- Institutions needing more flexibility than multisite
Why?
- Get benefit of code sharing (single update) w/ more flexibility
- Symlink structure supports concurrent versions of WP between tenant sites
- Security
- Isolate core code outside site folder
- Limit site owner access to WP files (limited to wp-content)
Why not?
- Experimental = Unsupported!
- Security in mixed-user environments
- Shared code must be executed alongside tenant code
- Can’t work in suPHP environments
- File access complexity
How
- Install WP into subdirectory (e.g. /core)
- Follow Codex instructions for ‘Giving WP Its Own Directory’
- Copy wp-config.php to site root (/)
- Edit subdirectory wp-config.php to include via $SERVER[‘DOCUMENT_ROOT’]
- Move subdirectory to core path (e.g. /usr/local/wordpress/4.0)
- Symlink subdirectory to new core pathln -s /usr/local/wordpress/4.0 core
- Site now loads index.php, which looks to /core/ through symlink, which references back to originating site’s wp-config via $SERVER[‘DOCUMENT_ROOT’]
- ‘Update’ of core WordPress is now the same as ‘replace symlink with pointer to different version’
- rm core; ln -s /usr/local/wordpress/4.1 core
Github developer recipes
Multi-managed
What
- Use cross-site tools like InfiniteWP to manage without sharing code
Related
St. Louis + WordPress = Majestic
