Justin Tadlock
Rob Howard rocked the boat last week in calling for the deprecation of WordPress multisite in the latest MasterWP newsletter. He argued that “the brave and noble add-on is no longer necessary or valuable to developers.” The responses via Twitter were swift and in disagreement.
Before WordPress 3.0, multisite was an entirely separate system called WPMU (WordPress MultiUser). It was a mess to set up, and one of the best things to ever happen to it was that it was rolled into core WordPress. It became a first-class citizen in the WordPress world, and its setup is now simple enough that nearly anyone can get a network up and running in no time.
I have not used multisite much in my career in the WordPress space. My primary use case has been for setting up theme and plugin demos. These are sites that I do not intend to touch much outside of their initial setup. Multisite always makes it easy to manage theme and plugin updates from the network admin.
Howard argued that this is no longer necessary in today’s world:
Likewise, sharing themes and plugins between sites no longer seems like a benefit to developers or end-users. With one click, we can deploy a parent theme from a Git repository to an unlimited number of sites hosted anywhere in the world – so what’s the real value of having a theme on the Multisite network?
Even with the vast tools available for deploying such things via Git, sometimes I prefer to avoid complicating matters. I can work in the command line well enough, but having that central location to manage all of my sites in one place is simpler. The argument also leaves out an entire segment of users who run multisite and have never even heard of Git. Multisite is sometimes a user tool.
The most complex multisite setup I have worked on was for a university. I was contracted to do some development work for another WordPress agency a few years ago. My focus area was extending the user role and permissions system.
The network had sites for each school, department, and various other projects. Setting all of this up on multisite allowed the permanent dev team to create new sites on an as-needed basis instead of spinning up an entirely new WordPress install. Everyone also had user access via their university email and password. It is possible to share a user database via multiple single-site installs, but it adds another layer of complexity that does not exist with multisite.
I cannot imagine the agency running this through 100s of individual installs. I am sure that some systems would make this easier, but a solution already exists in WordPress.
My multisite experience is limited. However, I have routinely talked with and helped fellow developers actively working on networks with 1,000s of sites in the enterprise and education sectors. It is almost a given that they are running multisite for every job.
WordPress co-founder Mike Little explained why multisite is often necessary for his work via Twitter:
Of course, I manage a hundred single instances too, a couple of them are 3-6-site multisites, but most are single (and should remain so). But one client of mine has close to 450 sub-sites on one of his multisites. That would be impossible to manage as separate sites.
Around 1K users per subsite, up to 100+pages of content created/day during an event. etc. It’s also constantly being developed.
Rolling out fortnightly code changes to 400+ single sites (not mentioning there are more than a dozen other instances with up to 50 sub sites each) would be unmanageable. And this isn’t a for profit org, so doesn’t have unlimited funds.
I have sat on this article since last Wednesday. At the time, I was ready to leap into the fire and defend multisite. However, as the responses rolled in via Twitter to the MasterWP article, I was disheartened by a few of the responses from the WordPress community. I did not want to feel like I was piling on.
The world of social media has made knee-jerk reactions all too common and uninviting to those outside of the inner WordPress circle. There is too much pressure to not say the “wrong” thing that so few end up saying anything worthwhile — or at all. Fortunately, there is still some thoughtful discourse, such as the response article by Maciek Palmowski on WP Owls and from others on Twitter.
Perhaps Howard was really just writing a click-bait article. However, because he only recently became the new owner of the MasterWP newsletter, I felt like I owed it to him to believe he was attempting to generate sincere discussion. Maybe his conclusion of deprecating a vital feature for many was off-base, but the conversation around problems with multisite is worth having.
Regardless of the merits of Howard’s argument, it did lead to an idea that might just be worth exploring. Alain Schlesser tweeted:
I’d prefer for single-site to be deprecated instead, to not have a random differentiation anymore. Everyone just has a network, but some only have a single site on them. Would simplify everything…
I do not know what such a WordPress would look like, but I do know that it could simplify the multisite installation process if there were only one way of doing it. Perhaps there would be fewer edge cases, plugin issues, and wrinkles that developers need to iron out if there were only one flavor of WordPress.
I use and manage several multiple site installs! Getting rid of network support would be the nail in the coffin for me.
When I read this tonight, my jaw dropped and my anxiety and stress level went up a few notches. The answer is no – I run a few multi sites and work on another set of multi sites which I just did a training on for my client. How would you manage users across 100 single site instances, each with their own permissions? And, to click and deploy plugin or theme updates individually? Sure, if you had some system of checks and balances to report which sites broke. There are so many reasons to keep multisite operable for the non-development crowd. Let’s please keep multisite because the cost of taking it away and forcing everyone who uses it to restructure their workflow is enormous. How would one go about setting up and migrating 100 sub sites into single site instances and then you have to add one user to 100 sites with the same user pass and send them a list of URLs to login to! Imagine the support email from a user who forgets which site in the network they can’t login to? I don’t know…I’ve been using multisite for YEARS! If it were taken away it would be costly. I know some people even sell hosting plans off of multisite, so that would cause them a lot of pain to have to export every site and import into single site instances at their host. My WP Engine plan is $290 a month for 30 sites. What if I have 100? What do I do then? What host can I go with the same level of service who will give me 100 install? WP Engine allows multisite with one click in the CPanel. All the WP Engine customers would be SOL if multisite went away, because then they’d be in the hook for a lot of money. I don’t know if he mentions that in his proposal, but that has ti be factored, as well.
Forgive any typos. On my iPhone…hoping my blood pressure goes back down.
Thank you so much for this. When I read the original newsletter, I felt panicked: what if the idea caught on? Happened? My team is smart and we could probably find a way to make it work, but what we have now works so very well for us.
Love Alain’s idea, though!
The biggest advantage for multisite i found was the ability to update all websites at once in very little time, one login, the ability to setup demo websites in a split second, but also in a huge MU setup draw and show content from one website or domain in the other. I really liked the domain mapping ability. I needed less space on a server to host many domains. For me they must never abandon the wp multisite. I still see many advantages.
I see two valid reasons (left) for Multisite:
1) Franchisor/Franchisee setup (ie: the parent site has a ton of child sites that are run from the top down or are essetially cloned from the parent). This includes university setups in some cases.
2) Product Demonstration sites for software companies (I use it for this purpose with a custom “brew” to make it happen). The lower overhead and shared resources make this efficient (But frankly there are newer and better ways to do this by spawning clones from an original parent into single sites)
I don’t think there is a need to “kill off” Multisite, but I do find that for all other uses than those above, it is a better solution every time to clone/create a new single site and manage a bunch of them via ManageWP, MainWP or similar dashboard utilities.
Many folks still don’t realize that Multisite commits one (Forevermore…) to a shared database and other limitations discussed in the article. It’s not as frequently requested as in years past, but I do still spend a fair amount of time explaining the issues above to the uninformed.
Only Two? It looks more like a narrow viewpoint as there are many more.
to a shared database and other limitations
There are workarounds for these when needed. HyperDB supports sharding, for example. Nothing is fixed in place forever.
Nevertheless, multisite isn’t going anywhere.
This is definitely a must for my own projects and client websites. It would be great if WordPress can add more features to it. All my installations are set up as a multisite. I use a subdirectory setup to hosts clients.
I use Multisite a lot. Even for stand alone installations the super admin function alone makes it worthwhile, especially for client’s sites I take care of.
I’ve also found it realy useful for running a small network of local community oriented sites. With the type of hosting cost centres we have in SA, we often pay a noticeable extra amount for a few more databases and another GB of storage, no unlimited databases, no, unlimited storage, no unlimited anything here in sunny South Africa.
Multisite makes running such websites more affordable in SA.
Over the years I’ve seen WordPress drop quite a few good things, sometimes in favour of poorer ones. The change of Tiny MCE was a good example.
I think if Multisite was dropped, and no plugin available to replace the functionality I think I would finally abandon WordPress as a client website platform and switch to Drupal which has a solid system of managing multiple sites. All Drupal’s layout and content display flexibility, and the rock solid security of Drupal core are way ahead of WordPress in that regard, the only real problem is building a client’s ability to get to grips with the content creating tools and methods.
Just when WordPress seems to be closing the gap on things Drupal does best- content sorting and display, and the layout flexibility introduced with WordPress blocks they start talking about messing around with important stuff….. grrrr….
This whole idea of deprecating Multisite was really one person’s idea – it didn’t come from WordPress that I know of. I doubt it’s going anywhere.
Killing multisite is preposterous.
It’s green. Only one central set of php files on my server and I can run hundreds of mapped domains. That’s healthy for poor opcache. Let alone better management of sites, which is so much less work with multisite, all subsites load faster and in all consume less resources than single installations. The brouhaha about a single database is overkill. Plugins now offer migrating multisite subsite to single installation. And on nginx for mapped domains I don’t even need wildcard SSL. Just build separate server blocks for subsites, point root to multisite root and get individual working SSL certs. Fast, efficient. Kill multisite? Rather make network subsite user registration part of core and give us server and site administrators some needed relief.
A multisite setup if my prefered way to setup a multilingual site. The MultilingualPress plugin is needed to make it work but it just works and it’s fast compared to WPML.
Maybe some day multilingual support will be available in core but until then a multisite setup is the way to go.
We also do multilingual sites via multisite. Togehter with the multisite language switcher plugin it’s the best way of handling multilingual site in my experience. Content nicely separated, no bloated database, clients with bigger teams love it. If multisite would be killed it would ruin half of the sites I run.
I work with Multisite quite a bit and love what it can do. If anything, it would be great to see it receive more attention in core.
For example, a way for Super Admins to see network-wide plugin or theme usage (how many sites are running Yoast, etc.). There are a lot of possibilities to enhance Multisite.
So, no, I don’t want to see it go anywhere 😉
There’s a plugin for that. It is pretty lightweight and works.
https://wordpress.org/plugins/multisite-enhancements/
I build and maintain a multisite of 75 sites. I cannot imagine taking care of them as single entities, which would be a nightmare. I want to believe Rob was 50/50 serious about it as well as trying to create a conversation about the website.
Have to say I just love developing and demoing my themes on multisite installs, with one set of shared plugins.
I make a change to my core plugin and each dev site / theme that use it gets those changes right away. Configuring certain plugins at the network level is very convenient. Multisite is not for every use case but there certainly are many situation in which it provides convenience and even cost-savings.
Is it perfect? No. WordPress ought to have been modernized with a total rewrite before Gutenberg, with a better network mode that can scale without nightmare-level effort. But what we have now is definitely better than nothing. The idea to deprecate it is surprising.
We talked a bit about the multiple uses for multisite on The Kadence Beat podcast last week. Multisite is still a very valuable tool. However, as with all tools, how you use it matters. The original author has some good points, but misses out on some of the great benefits of a multisite installation like maintaining login state across various implementations of WordPress from commerce to forums to LMS and more.
We use multisite internally and externally. In both instances, managing multisite is much easier. The internal site is an intranet. It allows us to create team sites and assign users to each site so they have access to only that team site. The external site is for clients and is free so using multisite to handle permissions and a common theme is the best way to go.
After setting up a network for the first time to find out if I should propose going that way for a client, I’m glad I decided to look for an alternative. And found WPCS (https://wpcs.io). Looking forward to see how that adds to this thread.
I am using multisite! Getting rid of network support would be the hardest thing for me.
Multi-site WP is THE PERFECT and ONLY option that makes sense that I use in a multi-user school environment (a sub-site for each teacher/classroom) and a multi-user church environment (a sub-site for each organization with the church. The benefits include:
– Easy management of updates, adding/modifying sub-sites, etc.)
– “Fire walls” users in their own individual “Admin” environment such that they don’t see, can’t “mess with” or delete the content of others . . . priceless!
In my respectful view . . . Mr. Howard apparently has not had the opportunity to be exposed to or to fully appreciation this VERY significant use case.
WordPress: Please don’t even think about dropping multi-site!
I really like the idea of WP being just multisite regardless, the whole super-admin thing and then still allowing ‘users’ to be and admin is worth the effort alone 🙂
PW! of course I meant WP…
Corrected for future readers. I took me a minute to figure it what you were talking about (braindead moment there).
I am actually coming around to the idea of WP always being a multisite instance.
Thanks Justin, my keyboard like to mess with me sometimes, well that’s my excuse.
Yep the whole world would be simpler and perhaps the whole super-admin, admin, developer, designer, editor, contributor, subscriber access levels could be sorted at the same time! 😉 (do I ask for to much?)
WP Multisite is precious, loved by its users, provides critical features, and probably deserves to be a higher priority in the WP community.
“Everyone just has a network, but some only have a single site on them.”
Pure gold, we use this often. Has many advantages when the client requirements grow/spread beyond a single site.
Even otherwise WP Multisite is a gem, can be and, is used across so many used cases, perhaps more by those who dared to play with it, but is one rock solid solution for several use cases!
A huge shout out to many who championed the cause and got it pushed into core, things have been pretty sane since.
I’ve just recently quoted a client on moving to multisite as part of their next expansion. So many of the weird quicks we’re working around now would be solved by using this feature that’s available in core!
I have worked with a lot of different MultiSite setups – some better than others. Nonetheless I’m not using it anymore – but I still think it’s relevant – as Mike mentioned, managing 450 sub-sites separately would be impossible, and that’s when it’s good to use MultiSite.
The country I live in, developers tend to use multisite as an alternative to a language-plugin. In my opinion, that’s not the correct use of this feature.
I’m glad it’s not going anywhere though! 🙂
I saw the post (and with everyone else here felt some horror at the idea that MU is dead) but didn’t realise I could discuss it here until now… 🙂
Long and short – we use it all the time. We actually use it for mini-app building (WordPress is kind of perfect for this with out-of-the-box auth, theming, functions, etc) – multisite lets you throw up a new part of an app really easily, so /client1 /client2 – all with custom front ends.
I also run another business, https://themuseumplatform.com/, which is built entirely on top of multisite. The fact we can spin up a new instance for a client with a core set of themes, plugins and functionalities in seconds is a huge, huge boon. Yes, it’d be “easy” with WordPress single site, just not nearly as flexible or simple…
Your email address will not be published.
document.getElementById( “ak_js_1” ).setAttribute( “value”, ( new Date() ).getTime() );
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable