Using plugins in WordPress MU
February 7, 2008 — techxplorerI’ve been exploring the WordPress MU software for the past week and looking into its applicability for a project I’m working on. I was particularly interested in its ability to work with a number of “must have” plugins.
I’ve discovered that the software has two plugin directories one is the standard plugin directory /wp-content/plugins the other is specific to WordPress MU /wp-content/mu-plugins. The difference is that plugins in the standard directory can be activated on an individual blog basis. Those in the mu-plugins directory are activated for all blogs.
There is, at least on the version I am currently using (1.3.3), another distinct difference between the way the two directories behave. A plugin can be made up of many PHP files, typically when this is the case the plugin is stored in its own directory, for example /wp-content/plugins/my-plugin/. A plugin of this type will automatically be recognised and made available for activation. If you put the same plugin in the mu-plugins directory, /wp-content/mu-plugins/my-plugin, it won’t be activated.
This means that the WordPress MU system will automatically descend into sub directories looking for plugins if they’re in the standard plugins directory. It won’t if they’re in the mu-plugins directory.
One other important distinction is that the plugins in the mu-plugins directory are activated for each blog automatically. They won’t necessarily be configured for each blog. This is an important distinction. If the plugin needs to be configured after it is activated it may not work as expected until it is configured on each blog.
For this reason what I have done is differentiate my plugins into two categories. If I they’re required for every blog, and do not have to be configured, I’ve put them into the mu-plugins directory. If they do need configuration, I’ve put them into the standard directory.
So far this has worked really well. One of the plugins that requires configuration, and was a must have plugin, was the WPDirAuth plugin for LDAP authentication that I’ve written about previously. Interestingly, now that the project has changed direction slightly, I don’t need the customisations I made to the plugin.
March 5, 2008 at 5:50 am
I got the impression that mu-plugins wasn’t quite as straightforward as that?
http://mu.wordpress.org/forums/topic.php?id=3209&page&replies=61
This post has one guy making it quite clear that it’s not an automatic activation folder for each blog?
I’m trying to find my way round mu at the moment and came across this post, figured I’d say hello!
March 5, 2008 at 8:50 am
@Alex,
That is exactly my point. The plugins in the mu-plugins folder are activated for each blog. However, and this is the important part, just because they’re activated doesn’t mean that they’re going to work.
In essence the issue comes down to the fact that if the plugin is completely self contained, i.e. doesn’t require any additional configuration to work, then putting it in the mu-plugins folder will make it work for all blogs in the system.
If however the plugin requires additional configuration it is best to put it into the normal plugins folder and activate, and configure, the plugin individually.
For example in the thread you outlined in your comment it talks about the Akismet plugin. For it to work correctly it must be configured with a WordPress API key.
If it is put into the mu-plugins directory it will be active, and will run, for each blog in the system. It won’t work with each blog though because it isn’t configured correctly.
I hope this helps clarify my post.
March 25, 2008 at 8:44 pm
Thanks for explaining this, I was wondering how to enable plugins on a site by site basis.
May 5, 2008 at 10:02 am
[...] in there, but didn’t think they would actually help my results. Google brought me to the answer on blog from Australia. All I needed to do was move the miwa-editor.php file out of its own folder and into the mu-plugins [...]