WCSEA 2015: Taylor McCaslin — Multisite Network Do’s and Don’ts — Experience from an Enterprise Solution

I’m at WordCamp Seattle today and will be post­ing notes from ses­sions through­out the day. These are posted right after the session, and could be a little rough.

This is a talk from Taylor McCaslin, Product Manager for WP Engine. Find Taylor at @taylor4844 on Twitter and find WP Engine on the web at wpengine.com (affiliate link). The WordCamp.org session description is here.

I missed the first few minutes of the talk, unfortunately, so these are less comprehensive notes than I would like.

Clarifying What is Multisite

Multisite is Dr. Jekyll & Mr. Hyde. Your best friend and your worst enemy. People generally don’t actually know what it is, or what’s different about it.

A multisite network is a collection of sub-sites that all share the same single WP installation.

What is Multisite Not?

It is not a network that can be moved to separate hosts. It’s 1 host, 1 install, many sites.

It is not a group of sites that can be easily separated into their own separate installs later. You can do this, but you don’t want to have to. (Modifying serialized data is not fun.) When people think they want to go there, talk really hard about why.

Multisite is not a set of sites with different IP addresses. They all have the same IP addresses. This can ruin a multisite: One bad actor can blacklist all sites on the network. The shared IP address is a single point of failure for every site on the ntwork.

Configuring Multisite

Different Multiste Modes: Open, or closed?

Two options. This terminology is hard, because the words mean different things in different contexts. Here’s the current consensus terminology among the core cdeveloper community:

Public Network / Untrusted

Aanyone can signup and create a site (sometimes paid). e.g. WordPress.com, Happytables.com, university student blogs (which are great for giving your faculty and students the power of .edu to easily rank highly in search results.)

Concerns: file types / uploads, scripts / embeds, copyright. Your users can harm you and each other.

Private Network / Trusted

Limited sites and user creation. WordCamp.org is an example. Company intranets for different departments, etc.

Concerns:

  • Too many cooks. “Just make me a superadmin”. Uh, no! Just, no.
  • Do you have someone to manage all of this? One WP site on its own is a lot to manage. Updating a plugin that breaks on the network breaks everywhere.
  • Code changes affect all sites!

Sub folders vs Sub domains

[I missed some notes here, but I feel this is fairly well documented elsewhere.]

Domain Mapping

Plugin for this: wordpress-mu-domain-mapping

Use CNAMES! Not wildcards. Allows you to manage the whole thing with a single DNS when you need to migrate [I think that is what he said.]

wpmudev.org has premium plugins for selling domains to users. Taylor recommends these.

Benefits of Multisite

Super Admin Role

Many WP capabilities that regular administrator role users can’t do. Includes unfiltered_html. Basically, the super admin role is super dangerous for this reason. DO NOT give people access to it. They will ask for it, but just don’t.

Shared Users

  • All blogs have entral user management. This is one of the biggest reasons to use Multisite.
  • This can have weird consequences. e.g. to New York Times’ blogs which are hosted on wordpress.com’s VIP network, you see the WP.com toolbar. This is a bit weird for NYT’s branding. This also makes privacy a bit harder.
  • Doesn’t play well with alternative login plugins for 2 factor auth (Duo2, 2FA, Google Authenticator). You’re logged in everywhere (perhaps not the intention if you’re using 2FA), but you still need to 2FA into each site individually (probably not expected if you’re using MS).
  • User profiles are the same for all sites.

Shared Themes

  • Add a theme
    • Network enable (all sites)
    • Restrict themes available to use per site (Site -> Edit Site menu
  • Remember to add Child Themes.
    • If users have file editor access, their changes to themes are network wide. (Whoa.)
  • If you network enable the theme, activate it on a site, and then network disable the theme, it is not deactivated on the site that has activated it.

Shared Plugins

  • Install plugins on the network
    1. Activate per site
    2. Network Activate
    • note that this is distinct from how themes work. This is probably a better system than how it works with themes.
  • Must use plugins
    • Are enabled and active network-wide
    • Can’t be deactivated through the admin
  • Some plugins have their own network settings
    • Not all plugins do this the same way or the recommended way.

Structural Differences

File structure:

[My markdown rendering doesn’t handle indentation for file structure diagrams very well, so please bear with me using code blocks to preserve indentation for these.]

* /
    *   wp-config.php — has extra lines
    *  .htaccess — has extra lines
    *  wp-content — has extra subfolders, including site-specific folders
        *  Rely on the host to allow you to grant your site admins access to specific site directories — and only those for their own sites.

Uploads folders:

* wp-contents/
    * uploads/
        * 2015/ — this is for your primary (first) site on the network
        * 2014/ — this is for your primary (first) site on the network
        * /sites/
            * 2/ — site ID
                * 2015/

Multisite databases have at least 17 tables, instead of the standard 11. The 6 extras are:

  • wp_blogs
  • wp_blogs_versions
  • wp_sitemeta
  • wp_site
  • wp_signups
  • wp_registration_log

Here’s the kicker: there are 9 prefixed tables per every new site!!!

  • wp_6_posts — prefixed with site id
  • wp_posts — first site (not prefixed)

Formula for number of tables in the databse: 8 + ( 9 * n ), where n is the number of sites.

Recommendations

Use a managed host. Multisite is already hard enough as it is, and doesn’t perform on shared hosting.

  • Ask for automatic backups with 1 click restore (ability to download backup)
  • built in staging sites (that magically work with the networked sites)
  • granular deploy to production controls (deploy only specific sites)
  • look for extra security features (automatic ip blacklisting, whitelisting, etc.)
    • Jetpack includes some new shiny of leveraging wp.com’s blacklist data for bad actors.

Recommended wp-config.php additions:

define( 'DISALLOW_FILE_MODS`, true ); // disable the Admin File Editor
define ( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true ); // prevent upgrade functions from doing expensive database queries
// [I missed one here.]

Do not ever do this anywhere in your code base: current_user_can( 'unfiltered)html' ); You will regret this.

Don’t loop through your network sites. Unless you know what you’re doing, you’ll cripple your site performance, if not crashing your site altogether.

Note Regarding Q & A

I didn’t capture Taylor’s use cases for Multisite during Q & A, with thumbs-ups and thumbs-downs on using multisite for various reasons. This is probably worth catching the wordpress.tv talk when it is available.

This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.

Add your thoughts