The Kingdom of Lochac provides space for groups and officers to maintain a web site using the WordPress content management system. This is a Good Thing, because WordPress is easier to use and more secure than the other alternatives. However, when it was first installed, nobody in what is now the Masonry Team knew much about WordPress MultiSite, and a few mistakes were made. The worst of these, from the point of view of the web ministers who now use the system, was that nearly all the plugins were Network Enabled. This page describes what this means, why it’s bad, and how to fix it.
Definition: WordPress MultiSite
There is really only one version of WordPress, but it has a variant that gives it a major new feature. When you set up a copy of WordPress on your shiny new web server, you get a complete copy of the source code and one website to use it on. That’s fine for most purposes, but no use if you want to have multiple sites without maintaining multiple copies of the source code. In order to remain secure, WordPress has to be updated regularly, which means a lot of work if you’re maintaining many independent copies.
Enter WordPress MultiSite. MultiSite is nothing more than an extra source file inserted in a specific place in the installation, plus a couple of extra settings. It allows the one copy of the source code to deliver up many websites. They all appear independent, usually running from different domain names or subdomains, but they operate off a single copy of the source. This means that updates are as easy as they would be if you only had one site. This is a Good Thing.
Unfortunately, WordPress MultiSite has a couple of gotchas. The one that is of relevance to us is the decision about whether or not to Network Enable your plugins.
WordPress by itself can’t do very much. You can create posts and pages and add pictures and comments to them; that’s about it. When you want to add functionality, you do so with plugins. A plugin is a collection of source code that implements one feature — sometimes a very large feature, but usually just a simple one. For example, on this website, I’ve added a plugin called Lana Facebook Share. It’s responsible for sticking the Like and Share buttons at the bottom of every page. After I installed it, it added an item to my Settings menu that let me configure how the plugin works, and since then it’s operated entirely behind the scenes without any further input from me. To the right you can see the Administration Page for this plugin; it’s relatively simple.
Some plugins are more complicated. They can add multiple administration pages, popup reminders, entire new menu items and all sorts of complications to the Dashboard, the WordPress administration interface. When you’re using only one or two plugins, carefully chosen, this sort of clutter is acceptable. The problem arises when the one or two becomes twenty or thirty, and when you didn’t in fact choose the plugins in the first place.
Definition: Network Enabled Plugins
A WordPress MultiSite installation gives you the option to make a plugin available to every site at once. This is called Network Enabling. This is essential in at least one case: the plugin that handles the different domain names for each site, including aliases, has to be Network Enabled or else the MultiSite system won’t work at all. It’s also useful, for example, with comment spam preventers and light-weight plugins that make life easier without causing excessive clutter. It becomes a problem when too many plugins are Network Enabled.
Consider this screenshot of the dashboard of a WordPress installation with hardly any plugins enabled at all. (Click to see it at full size.) It has the usual dashboard features: Pages, Posts, Comments and so on. It has one plugin that I enabled, Facebook Auto Publish. (Incidentally, I don’t recommend that plugin. It seems to be pretty buggy. This is my WP test installation; I use it to try out plugins before I send them live on my real system.)
Here’s a view of the Tools menu of the same installation. The menu is, as you can see, not particularly cluttered: it has three items, all of them as provided by the basic WordPress installation. This is perhaps a little too simple, but it’s certainly not a bad goal to aim for.
Now consider this view of the dashboard of the Lochac WP system, and the Settings and Tools menus that go with it. It’s far more cluttered. I consider myself a WordPress expert and I have no idea what most of these things do — there are too many plugins in the world for anyone to keep them all in mind. This level of clutter makes the formerly simple WordPress interface confusing and hard to use.
I assert that the vast majority, probably all, of the web ministers using this system do not know, use or care about the vast majority of the plugins currently Network Enabled on the Lochac system. They do, however, care about the confusion and clutter that these plugins cause.
Unfortunately, while the confusion is probably unanimous, the specific set of wanted plugins is not. One site may be using a Facebook Share plugin, another may be using some page widgets. Completely removing either of these would make someone unhappy, and the same applies to, probably, all the plugins in the system.
Fortunately, it is possible to make plugins available to those who want them without imposing them on those who don’t. If the MultiSite administrators sets a plugin so that it’s not Network Enabled, an individual site webmin can still enable it just for their site.
We can solve this problem by reducing to zero, or nearly zero, the number of Network Enabled plugins on the system, and allowing webmins to enable just the plugins they need. The clutter will be reduced for everyone. Once that’s done, we can then take a look at the plugins that nobody is using and remove them completely.
Some plugins will deserve to remain Network Enabled. The Disable Comments plugin, for example, makes it easy for a webmin to switch off comments on an entire site — a feature that WordPress really should have built in. The MultiSite domain name plugin is another obvious one to leave enabled. But most of them can be turned off, left to individual webmins to reactivate if they want them.
Problems With The Solution
It is, of course, not as easy as that. If the WP Administrator set all the plugins to be not Network Enabled, every site that uses those plugins would break. It’s frustratingly impossible to see which plugin is being used on which site when they’re Network Enabled, so the only way to go is to poke it and see.
This means there would need to be coordination. All the webmins would need to be available, simultaneously, to check their sites and enable the plugins they’re actually using. This would be a big job, probably requiring Google Hangouts or Facebook Messenger group chat. We would need to find a day when everyone could be available. That’s a huge ask, but I believe it would be worth it.
WordPress is a simple, intuitive system, when it’s allowed to be. We have a lot of trouble finding webmins because they consider our installation to be the opposite of that. If we reduced the confusion, we would increase the ability of the groups and officers in the Kingdom to communicate with the populace. That seems worth an afternoon of fiddling, surely!
Useful Notes: Lochac Sites
Here’s the list of Lochac sites we’d need to coordinate.
Officers and Guilds
Archers • Arts and Sciences • Brewers • Chirurgeon • Chronicles • Cockatrice • Constable • Cooks • Equestrian • Festival Team • Fibre • Herald • History • Hospitaller • Lists • Marshal • Masonry • Rondel • Roses • Royal • Seneschal • Tailors • Worshipful Company of Broiderers • Youth
Abertridwr • Adora • Agaricus • Bordescros • Burnfield • Cairnfell • Dismal Fogs • Dragon’s Bay • Innilgard • Krae Glas • Lightwood • Mordenvale • Politarchopolis • Radburne • River Haven • Rowany • Saint Aldhelm • Saint Andronicus • Stegby • Saint Florian • Saint Malachy • Saint Monica • Stowe • Saint Ursula • Torlyon • Ynys Fawr