Author: Ipstenu (Mika Epstein)

Edit: It’s May 2015 and this post is still relevant.

I talked about this at WordCamp SF 2013. Check out my slides or watch the video.

I love MultiSite. I think it’s awesome and very helpful when you want to make a network of sites. But more and more I see people doing things where I just tilt my head and wonder why they’re using MultiSite for that particular use-case.  People seem to think that simply because they can use MultiSite that they should use it, and this simply is not the case!

MultiSite, either by intention or effect, works best when you think of it as running your very own version of WordPress.com.  You have a network of sites that are disconnected from each other, data wise, but share the same available user base.  That means the only ‘information’ that is shared between two sites is your user ID, and even then, unless you’re explicitly granted access to the site, you’re nothing more than a subscriber.  Which is to say you can read the site, and comment.(You could get nitpicky here and point out that there are a lot more things one can do as a subscriber on a site, but you understand the gist.)  That means that while there are many perfectly valid reasons for having a MultiSite, it will never be a perfect solution for all people.

One of the best alternatives to MultiSite is Custom Post Types.  They let you make ‘subfolder’ additions to your site and format them as you want.  There is a drawback, though, in that you cannot use YYYY/MM/DD in your permalinks for them (Otto on Custom Post Types – wp-testers email list) however I would wonder why people use that anyway these days?  The only reason I use YYYY in my URLs is that I believe there’s a date on the usefulness of these posts, and if you come back in five years, you should know how old the information is.

Another alternative is good planning.  If you sit down and define your needs for your site before you build it out, and plan for the growth you desire, a lot of things become clear.  Think about how many different places you’d want to go to maintain your site.

Here are some examples of sites that should not be built out as MultiSites:

To Categorize Posts

This one comes from my girl, Andrea, who reminded me of a fellow we ran into who wanted to have one site to post from, and each post would go to a special site based on the category.  WordPress already has that built in!  It’s called, get this, ‘categories.’  Now the user in question said he didn’t want categories because your URL shows up as /category/pemalink, and that wasn’t his desire.  So I suggested Custom Post Types.  /posttype/name was much better, and he could add in tags as he wanted.

When Your Site is Homogenous

Do you want your whole network to look and feel 100% the same?  Don’t use MultiSite.  If every single subsite is going to be exactly the same, except for content, but the content is all written the same way, you don’t need MultiSite.  Replicating the theme and settings on every subsite is a pain, and you can achieve the same result with categories, tags and CPTs.  You can even use a membership plugin to control who sees, and has access to, each CPT!(Role Scoper claims to do this, in fact.)

Now someone will point out that this site fails that check!  If you notice, three (four, kind of) of the sites look very similar. Same general layout, same links and sidebars, but different headers.  This site could have all been done as categories and CPTs, and not needed the multisite until I hit on the children sites like the one for my grandmother.  But.  When I built it out, I decided to put my tech posts on their own page to separate the writing.  They are separate sites.  What I write here is vastly different from my blog, and that’s important to me.  The site has the same ‘feel’ in look alone: the context is what separates us.(And I have a plan for the photo blog.)

For One Special ‘Thing’

I’m guilty of this one.  I had a site that was a blog, and I wanted to make a ‘video’ section.  So I made a MultiSite!  Boy was that dumb.  Two admin areas, two sections for layout, and I wanted the site to still look like ‘itself.’  I caught a clue later on and converted the whole thing to Custom Post Types!  Much easier to maintain!  Now I have a smaller, faster, site.

Users Shouldn’t Know About Each Other (AKA Separate User Databases)

Andrew Norcross pointed this out.  If you need users to be on different sites, but not aware that they’re on a network, don’t use MultiSite!  Now, yes, there are ways around this, however it’s an auditing nightmare for any large company, and a security risk that you should be aware of before you start.

Curtiss Grymala points out that if you need totally separate user databases, this is a strong case against MultiSite.  Be it for security or just obscurity, if the users need to be separated  don’t do it.  There are workarounds, but you’ll spend more time on that then updating your sites.

Hosting Small Client Sites

I don’t host my Dad’s site, Woody.com, even though I maintain it.  Why?  Because, as

Cristian Antohe said, he just needs a standalone WP install.  Would it be easier for me to have one place to go to upgrade him?  Yes and no.  He’s small, he doesn’t need a lot, and he now owns his domain, his site and his email, all in one place.  It costs him $7 a month, plus the number of meals he buys me when we’re in town together, and he’s master of his own domain.  This is great for him, because if he fires me, he still has everything.  Also, if he does something weird that spikes his traffic 500% (like last month), it doesn’t affect the rest of my sites.  Factor that into your budget.  Make your client own their own data.

Users Need To Embed JS Into Posts

This is not a bug, people.  Only the Super Admin on a MultiSite install has the access to include iframes, javascript, and other non-oEmbed’d data into posts! You don’t want them to!  If you’re running a MultiSite, you’re the big dog, and you’re responsible for limiting their actions to things that won’t take down everyone because they don’t understand what an insecure iframe hack is.  Yes, there’s a plugin that will let you allow this.  No, I won’t tell you what it us, because unless you’re using a 100% locked down, you approve users you know and trust with your car, site, you do not want to open this door.

If you can’t give them they access they need via shortcodes, then they need to host themselves, or you host them separately.  Protect everyone on your network, and don’t give them unregulated access.

Users Need To Install Themes/Plugins

Curtiss again reminded me that MultiSite doesn’t let you let your users install themes and plugins as they want.  You can, via the use of clever themes that save settings per site (like TwentyEleven) and plugins that allow you to tweak CSS (like WordPress.com Custom CSS) give them more customization, but you cannot give them access to install plugins and themes.  Why?  Because those things will be available to everyone on the whole Network.(There are plugins to manage plugins more granularly, and only permit some sites to use certain plugins, but again, this isn’t something everyone on your network should have access to do.)  Remember, we’re sharing here!

Same Post, Every Site

I keep running into this one.  “I want to have the same post pushed to every single site on my network!”  I understand why people do this, I just think they’re doing it wrong.  It’s not just that MultiSite is meant to be separate (aka individual) sites, it’s that you’re diluting your content.  The more different places someone can go to in order to get the information you’re providing, they less impact you have because you’ve given them too many options.  Decisions.  Make one. Also, as Andrea reminded me, identical content in multiple places is something spammers do. Google will downgrade your site ranking if you do this.(This doesn’t impact categories, tags and archives because of the use of canonical links.)

Now, one user said he needed to do this as a business decision, because each of his (mapped) domains was a separate brand.  But the separate brands had shared data.  So … they’re not actually separate, but children.  Me?  I’d have everything link the shared data back to the master brand.  McDonalds may sub-brand out happymeal.com (they did!) and make a whole separate site, but if you click on their ‘Privacy’ link, you go back to macdonalds.com!  Why?  Because the parent brand is where that stuff belongs.

BuddyPress Separation

This comes from Andrea again.  If you need to have totally separate BuddyPress installs, use separate installs entirely.  Just … y’know, you can do it other ways, but it’s not worth it.

What else?

This list could go on and on, so jump in and tell me your reasons why you’d never use MultiSite!