WordPress Multisite versus “Minisite”

I work a decent amount with Multisite. Not a ton, but maybe on about 10% of the websites I build. There’s sometimes confusion at work as to what’s a good use for Multisite and what is not. I also see this in the greater WordPress community. Let’s discuss what some common issues are, and how we can determine whether Multisite is the right fit.

What Multisite is best for

There is a subtle but important concept to understand when getting started with WordPress Multisite.

Multisite is intended to allow for different websites to utilize one WordPress install. Those websites can share themes, plugins, and users, but inherently, each one is meant to be different. Users in the network can be assigned to specific blogs and have various permissions on each. And plugins can be either network activated if they are intended to be used across all sites, or enabled and configured on a per-site basis.

WordPress.com is the most famous example of Multisite in action.

What people often squeeze Multisite into

However, many of us want to share much more than that. On any given project, we may want to share widgets, nav menus, forms, permissions, or even items in the posts table like posts, media, or pages.

Often times, I, and perhaps you, basically want “minisites” within a WordPress install that may vary in their level of separation from one another, but all in all, they are not wholly different websites as Multisite naturally wants to be.

For example, a blog network may want to maintain the global header, footer, and widgets, but enable community authors to start their own blogs. A corporate website may want to utilize an intranet that shares some of the primary style and functionality elements of the main website. A large law firm may want to enable each attorney to have their own section within the website.

The list can go on with examples of good use cases for minisites.

The problem is, with the current setup of Multisite, WordPress isn’t necessarily well-prepared to handle minisites out of the box.

Pitfalls for Multisite in minisite situations

There are a number of potential pitfalls people could run into when trying to sqeeze Multisite as a solution for minisites.

Child themes

Many consultants work with base parent themes, using a typical Parent -> Child theme relationship. However, when Multisite is needed on a project, child themes that handle a large percentage of the presentation layer can sometimes present issues.

For instance, I may want a custom page template to be available for one site in my install, but not another. If I create the template within a child theme that is shared between the two sites, I cannot prevent one site from having that template.

Another problem area with child themes and Multisite is stylesheets. Under a scenario where the main site presentation is in a child theme, but I have another site in the install with a very similar look, I then either have to duplicate most of the styles between child themes or go about an atypical way of sharing the base stylesheet from a plugin or something.

Therefore, at my work, when we utilize Multisite for this “Minisite” style functionality – where many items are shared across sites, we find it more valuable to make the parent theme house the shared elements across all sites. In this setup, the parent theme is essentially a shared style guide for each sub-site. Then, I can make more custom presentation layers per-site for the child themes.

Single point of updates for menus

The most common issue with minisites we run into at Infomedia is our desire to share menus and widget areas between all sites on the network. Most of the time we try to squeeze Multisite where it sometimes shouldn’t go, we’re essentially attempting to departmentalize a website from a user permissions perspective, while still maintaining almost all network-wide functionality.

Well, for menus and widgets this quickly becomes a problem. Multisite wants to treat these as independent for each site. So when a user comes back later on and wants to change a menu, they may not realize that they need to change the menu in each site in the network. The way to get around that is with menu caching.

Ron Rennick wrote a simple and effective menu caching plugin quite a long time ago, called Network Wide Menu, that we have forked and made our own a variety of ways for different projects. The plugin essentially lets you define a menu location as a global menu, and it caches the menu on the main site. And on each call to menus of subsites, it calls the cached menu from the main site in the network instead. So now users can update their menus from one location.

Global plugin settings

Plugins can be another pitfall for Multisite. When you use multisite, each site in the network gains ability to enable and disable any plugins that aren’t network enabled. If this power isn’t acceptable for the admins of a given site, then Multisite could be more trouble than it’s worth.

edit: Nacin tells me enabling plugins at a per-site level is actually a network setting!

Also, if you want to change all configuration settings globally across a network for a plugin, it has to be done programmatically, since there isn’t a way to bulk-edit plugin settings across all sites in a network.

Do you need Multisite?

Whenever you start having a discussion within your company or with your client about whether you need Multisite, I highly recommend you check out this post from Mika Epstein.

As she notes in the post, there are some times where Multisite just might not be the right option for you.

You may find after really thinking about it and reading that post that you have some alternatives to Multisite to accomplish what you want

Alternatives to Multisite for minisite functionality

If you are wanting to make sections of your websites permissible to certain people, you could consider using custom post types and taxonomies to do so, with custom capabilities set. You may also consider a plugin like Groups for this, plus you can use it to manage users and their permissions on a per-post basis.

For giving authors their own “blogs” you may want to consider just customizing the author archive template and using the built in archives for each author. You may want to create a custom role with a plugin like Members if you need to specially manage their permissions under this setup.

Where I’d really like better minisite support

There are times where I’d really like some level of minisite support within WordPress. One is when I want to limit access within a content type to certain types of users, without regard to taxonomy. For instance, I may want a group of 5 users to be able to edit the “about” page and its sub-page content. Such a hiearchical method for segregating users isn’t very easy in WordPress as far as I know.

Also, what if I have modular functionality under that particular section? I may have FAQs, or a testimonials custom post type within a section of a hierarchy. This all becomes a challenge, because the content type isn’t the same, but it’s in the same hiearchy as those areas I want a particular user to edit.

User taxonomies may be able to help under these scenarios – I’m not sure. User taxonomies make my brain hurt sometimes.

Is there a future for “minisite” support in WordPress?

The point remains that utilizing a packaged “minisite” functionality the way you can utilize packaged Multisite functionality doesn’t exist in WordPress. And as far as I know, there aren’t any big core initiatives to create built-in minisite functionality. Therefore, I think it could be ripe territory for a bbPress-level plugin.

I know that some folks have been working on this topic for some time. Mike Schinkel has talked about Sunrise for just this sort of thing for years, but I’m not sure what the status of it is these days.

I’d love to see your solutions for handling minisite setups, and of course I want to know where I sound like an idiot in this post too. After all, Multisite is only a part of what I do, and I struggle often times when the subject comes up to weigh pros and cons for how to setup sites that aren’t totally perfect for Multisite, but could use some of the Multisite goodness.

*image source