Should Theme and Plugin Developers Build For WordPress Multisite?

Being a theme or plugin developer is a tough gig. Between WordPress updates, bug fixes, PHP version incompatibilities, and customer support, you have a lot to deal with. And don’t forget about the bunches of potential users who ask, is this Multisite compatible?  It’s a pretty common question, and it may not be something every dev has considered.  So I wanted to dig a bit deeper into WordPress Multisite development, and specifically, when you should factor Multisite installations into your development process.

Why Build for Multisite?

Here’s the thing. When you’re installing WordPress and building websites, when you ask yourself should I build for WordPress Multisite?, the answer is going to be no far more than it will be yes. The situation flips, though, if you are in plugin and theme development. Maura Teal discusses some of the reasons why in her WordCamp San Diego talk called Why Good Developers Don’t Ignore Multisite. Take a guess at what point she’s trying to make.

You can check out our total overview of what Multisite is, but the basic gist of it is this:  one WordPress installation powers a network of sites. WordPress.com is actually an example of this in practice.

It’s a really cool feature, and Maura Teal is right — you shouldn’t ignore it. However, if you want your plugin or theme to work with it, you need to put in some special effort. See, Multisite installs share a database, and some tables in that database are shared between sites (for example, usermeta), while others aren’t. You may also run into be major issues with network-wide activation, table creation, plugin deactivation, and a few other speed bumps.

So…why should you actually take the time to sort through those issues?

Well, first off…

Plenty of People Ask For Multisite Compatibility

Really. It may not  be the default setting, but people use it. A lot. In an episode of WP Water Cooler, the panel discusses what you should do after launching a WordPress plugin. As part of that discussion, they talked about common support issues and feature requests.

Translation was the first one they mentioned. WordPress is mega-global, right? But after that…Multisite compatibility was the next issue to pop up. And it doesn’t just pop up in podcast episodes with developers. The question is plastered all over the WordPress.org support forums.

Yes, most WordPress installs are single-site installations. But there are plenty of WordPress Multisite users out there, and those webmasters want multisite plugins and themes that play nice with their versions of WP.

It’s Not That Hard If…

In that same WP Water Cooler talk, Jon Brown from 9Seeds talked about the biggest reason to develop for Multisite: It’s not that difficult if you code for it from the beginning.

That is, if you test on a Multisite environment, and you code with Multisite compatibility in mind, then it’s not actually that much extra work. Most of the real work that you have to do is really just following best practices. It may add a little onto your overall timeline, but it’s not going to double your development time or anything that drastic.

Adding Multisite Compatibility Later, Though…

This is where you can get into a sticky situation. Adding Multisite compatibility from the start isn’t that difficult since you can plan for it. Going back into your codebase after the fact and trying to add in Multisite compatibility is going to involve unraveling a lot of spaghetti code.

Let’s say you ignore Multisite compatibility because you want to get a plugin up and running as quickly as possible. What happens if your plugin becomes a smashing success? That’s great! Congratulations! Now the support tickets start rolling in, you’re getting lots of comments and questions regarding Multisite, and if you say no…that’s a lot of lost customers, revenue, and honestly brand loyalty. Because you either ignore those people and keep on keeping on. Or you can try to go back in and try to retrofit everything.

Neither solution is particularly appealing.

Specific Issues to Consider When Building for WordPress Multisite

So let’s say you’re convinced to start developing for Multisite. What does that actually entail, though?

While this is very much not a comprehensive list, these are some of the bigger issues to consider when planning out your development.

By the way, there can be a lot of code involved with sorting out Multisite vs single-site development, and there are people who have some fantastic examples already. You should totally check them out. These are a handful of the great resources I recommend checking out.

• ShibaShake’s Write a Plugin for WordPress Multi-Site
• WPHub’s post on Making Plugins Compatible with WordPress Multisite
• Onextrapixel’s How To Properly Code Your Plugin For A WordPress Multisite

1. Put an Extra Focus on Scalability

Obviously, you should always strive to make your code as efficient as possible. But when you’re working with typical WordPress installs, you have a bit more leeway. And I am not saying you do this, but you…can get a little lazy when it comes to performance optimization. Tidying up every single db query? Mmmm…

Those kinds of shortcuts add up when your users are managing 300 sites on their network. Your plugin or theme’s performance performance and scalability matter much more. So much more that you may lose clients and users if the code isn’t optimized well enough.

2. Use Proper Database Table Names

Because of how Multisite works with database tables, you need to avoid making calls to hard-coded table names. Eat site on the network shares a single database, but they each make their own tables. So if you if you try to execute something on wp_posts, for example, you’re going to have some issues with Multisite.

The proper way is to use the $wpdb global object to ensure you’re always getting the correct database table names for both single site and Multisite, no matter who is running your code. It’s not a hard change to make, but it’s a change nonetheless.

3. Think About Activation and Deactivation

If your plugin, say, creates a table during the activation process, you’ll need to iterate that over every single blog in a Multisite install (assuming the plugin has been activated network-wide, as many are).

What about when a new blog is added to that Multisite network after your plugin was already activated? In those kinds situations, you’ll need to make sure your code runs the activation function to create the required db table whenever a new site is added.

And of course, the same rules apply to deactivation and uninstallation. Make sure you cleanup your mess before you leave.

4. Consider Admin Options & User Permissions

Beyond specific code changes, you also need to put a little bit more thought into interface options. For example, is there a specific feature of your plugin that the Multisite Super Admin might need to turn off network wide?

Maura’s example of a wp-cron call that ran through the entire posts table is a good illustration. On one site, sure! That’s just fine…but on 300? It can sink a network just as quickly as getting a link on the front page of Reddit.

Additionally, I’ve heard about some issues with themes on Multisite where only the Super Admin can manage theme settings. That’s fine in some situations, but if the Super Admin wants each site’s users able to change their site’s appearance…again, issues. Part of coding for Multisite is considering likely possibilities and use-cases like this one.

So…Should You?

All in all, WordPress Multisite generates some strong opinions in the WP community. Some people really love it. Some people really hate it. Hate it enough to give WordCamp talks titled Don’t Use WordPress Multisite. Again, guess the point they’re trying to make. (Admittedly, that’s an older talk before there were many updates to the feature, but my point is the ideology.)

In the end, whether you plugin and theme devs should build for Multisite is a big ole maybe. If you’re developing for the general public, putting your themes and plugins on the repo, or selling them on your own, you absolutely should take the time to code your project to work with Multisite. It opens up more opportunities than the dev time takes up.

But if you’re developing websites for clients, Multisite is usually not the answer. You will have certain situations when using Multisite will make sense, but more often than not, it won’t. For many clients, the extra features Multisite installations give are more overwhelming than useful.

What are your thoughts on WordPress Multisite development?

Article featured thumbnail image by Jiw Ingka  / shutterstock.com