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.