When setting up your WordPress MU environment, it can be difficult to determine whether you want a plugin to go into the /mu-plugins or the /plugins folder. I’ve discussed the difference between the two locations in the past. At this point, I’m talking about deciding which to use based on the knowledge of how they work.
From my perspective, it makes no sense to include any more plugins than necessary across all blogs on your site. All you’re doing is front-loading the page load process and slowing the entire site down. Moreover, having to maintain code that not everyone uses makes no sense, especially if in doing so, you risk crashing your whole site with one bad upload. The best option for both efficiency and stability is to limit available plugins both as mandatory and optional plugins.
At the same time, if you’re hoping to allow users to have unique blogs that represent them, you can’t just fail to install plugins. In fact, restricting things too tightly will probably make your users go elsewhere. One compulsion is to load all plugins into the /mu-plugins folder with the intention of making them universally available in a more obvious way, thereby hopefully luring in new users.
I think that last bit is a mistake.
My recommendation is to load administrative plugins into the /mu-plugins folder and leave any formatting and presentation plugins to the /plugins folder. By administrative plugins I mean spam-blocking plugins, plugins related to URL handling or mobile web access, or others. Basically, plugins which either effect your entire site equally or require such knowledge that users cannot be expected (or should not be expected) to know how to configure them.
Presentation plugins, like the tan-tan noodles Flickr Plugin, are usually more intuitive to configure. The Flickr plugin in question is perhaps a little more involved because of all the options, but the point is, users can read the options and decide for themselves how to set it up, or if they’ll bother at all.
Two major impediments to this theory are that:
- Many plugins don’t work out-of-the-box as mu plugins
- The presentation plugins are the ones that tend to take up overhead when loading
For the first, there is nothing to do but to hack your plugin. If you do and it works, why not post it to the WPMUDEV.org site? The preferred method would be one that checks to determine it’s location and modifies calls to files accordingly, along with providing alternate Admin menu selections as needed.
As for the second challenge, you’ll have to use your own judgment and see how things go. The best option would be to start off with a relatively small choice of options and work in more plugins one at a time to see if they can handle the load.
