Rob Howard shook things up by advocating for the elimination of WordPress multisite in the most recent issue of the MasterWP newsletter, which was published the previous week. He contended that “the brave and noble add-on is no longer essential or helpful to developers” because of this argument. The responses that were sent via Twitter came back quickly and were divided.
Before the release of WordPress 3.0, the multisite functionality was handled by a completely separate platform known as WPMU (WordPress MultiUser). Setting it up was a nightmare, so having it incorporated into the core of WordPress was undoubtedly one of the best things that could have happened to it. It is now so easy to set up that virtually anyone can have a network up and running in a matter of minutes, elevating its status within the WordPress community to that of a first-class citizen.
Throughout my time working with WordPress, I have not made extensive use of the multisite feature. My primary use case has been to set up demonstrations of different themes and plugins. These are websites that, after they have been initially set up, I do not intend to make many changes to. The ability to easily manage updates to themes and plugins across all of your sites is one of the many benefits of using Multisite.
Howard argued that in today’s modern society, there is no longer a need for this:
Likewise, it does not appear that developers or end users will gain from the sharing of plugins and themes between different websites. Since we are able to deploy a parent theme from a Git repository to an unlimited number of sites hosted anywhere in the world with just the click of a button, the question arises as to what the true value of having a theme on the Multisite network is.
Even though there is a vast array of tools available for deploying such things via Git, there are times when I choose to avoid making things more complicated. Even though I am capable of working in the command line, having that single spot where I can manage all of my sites in one place makes things much simpler. The argument does not take into account another group of users, namely those who operate multisite yet are completely unfamiliar with Git. There are situations when the user tool is multisite.
My work with a university was the most challenging multisite arrangement I have ever been a part of. A number of years ago, I was hired by a different WordPress organization to perform some programming work under contract. Extending the user role and permissions system was a primary area of attention for me.
The network featured individual websites for each educational institution, administrative division, and numerous other initiatives. When all of this was set up on multisite, the permanent development team had the ability to establish new sites on an as-needed basis rather than spinning up a complete new installation of WordPress. Everyone also got user access using the email address and password associated with their university account. It is feasible to share a user database across numerous single-site installations; however, doing so introduces an additional layer of complexity that is absent in multisite installations.
It seems inconceivable to me that the agency would do this across a hundred separate installations. Although I am certain that there are other technologies that would make this process simpler, a solution is currently available in WordPress.
My experience managing many sites is minimal. On the other hand, I have frequently collaborated with other developers and provided assistance to them when we were actively working on networks that had thousands of sites in the business and educational sectors. It can pretty well be assumed that they are utilizing multisite for each and every assignment.
Mike Little, one of the co-founders of WordPress, recently explained on Twitter why multisite is frequently required for his work:
Of course, I also handle a hundred different single instances; a few of them are 3-6-site multisites, but the most majority are different single installations (and should remain so). One of my customers, on the other hand, has one of his multisites that contains close to 450 sub-sites. It is impossible to handle these as independent sites at the same time.
Approximately one thousand visitors visit each subsite, up to one hundred and more pages of content are produced each day during an event, etc. In addition to that, it is consistently undergoing development.
It would be impossible to handle the process of rolling out code changes on a fortnightly basis to more than 400 single sites, not to mention the more than a dozen other instances, each of which has up to 50 sub sites. Because this is not a for-profit organization, its financial resources are limited.
Since Wednesday of last week, I’ve been sitting on this article. I was prepared to throw myself into the line of fire and defend multisite at the time. On the other hand, once the responses to the MasterWP piece started coming in via Twitter, I became discouraged by a couple of the responses that came from the WordPress community. I did not want to feel like I was heaping on.
The realm of social media has made knee-jerk reactions all too common, making them uninviting to people who are not part of the inner circle of WordPress users. Because there is so much pressure to avoid saying the “wrong” thing, very few people really wind up expressing anything that is useful, if they say anything at all. Thankfully, there is still some meaningful dialogue taking place, such as the rebuttal piece written by Maciek Palmowski on WP Owls and the comments made by others on Twitter.
It’s possible that all Howard was trying to do was write a clickbait article. On the other hand, considering that he has only recently taken over as the new proprietor of the MasterWP newsletter, I felt as though I owed it to him to think that he was making an honest effort to spark dialogue. It’s possible that his conclusion, which consisted of deprecating a feature that was critical for many people, was incorrect, but it’s important to have the dialogue about the issues with multisite.
Regardless of the validity of Howard’s argument, it did give rise to a concept that might be interesting enough to warrant further investigation. A tweet from Alain Schlesser read:
Instead, I think it would be better if single-site were deprecated so that there wouldn’t be any more room for random distinction. Everyone merely possesses a network, however some of them include simply a single website on them. Would make everything much easier if…
If there were only one way to install multisite WordPress, it could make the process much easier, but I do not know what such a WordPress would look like. However, I do know that it could simplify the process. If there were only one flavor of WordPress, perhaps there would be fewer edge situations, plugin difficulties, and creases that developers need to work out.