mu-plugins: What is it good for?

If you’ve been using WordPress seriously for a while, or Multisite for more than twenty minutes, you know about this weird thing called MU Plugins. That used to mean ‘Multi User’, as in WordPressMU, the predecessor to WordPress Multisite. The short version is that any plugin you put in there is ‘Automatically On’ for your site. On a Multisite Network, this means it’s on for all sites. On a single site, it means it’s on and you can’t turn it off. 1

So why use it?

In a theme, often people will add code snippets to a functions.php file to customize things, and that works great. It gets called via the theme and you’re happy. But what happens when you change a theme? Or if you want to apply the changes to multiple themes? Then you use mu-plugins! I use it for all my ‘non-interface’ code, that is stuff I want to set and forget.

Here’s an example of a block of code I have:

// Header Additions
add_action('wp_head', 'fansite_head');

function fansite_head() {

        echo '<link type="text/plain" rel="author" href="http://fansite.tld/humans.txt" />';
        echo '<script type="text/javascript" src="http://apis.google.com/js/plusone.js"></script>';
        echo "<script type='text/javascript'>function plusone_vote( obj ) {_gaq.push(['_trackEvent','plusone',obj.state]);}</script>";
        echo '<meta property="og:type" content="fansite"/>';
        echo '<link href="https://plus.google.com/xxxxx/" rel="publisher" />';
}

This adds in my humans.txt (yes, I have one), the Google +1 tracking, and a link for the publisher so G+ knows the site is really itself. Now this code is on every site in my network, without lifting a finger.

Now there are some things that are very theme specific. Like I have a bit of code that adds similar data like my head example, but right below the HTML tag. Since that’s using a theme-specific call, I leave it in my theme functions.php instead. I even use this on my non-Multisite installs, since it just makes it easier to separate my perma-code from my theme code. In addition, when I’m making a site for someone else, and I’m not doing their theme (it happens), I can tuck things they want all the time, on every theme, in there, and they can’t ‘accidentally’ turn them off.

I’ve gotten in the habit of naming the files things like sitename-cpts.php (which has all my Custom Post-Type data for one single-site) and sitename-functions.php (which has everything else) and even sitename-style.php (which turns on the visual editor styling to match my site, and changes the html editor font, as well as a small fix for a fixed position header that looks nasty with the admin bar when logged in).

What do you love using mu-plugins for?

About these ads
StudioPress Theme of the Month

Comments

  1. Hi Mika,

    I love using mu-plugins for all kins of nasty things!

    First of all, Domain Mapping is one of the standard plugins for all networks I set up. A functions file covers all the little things, like a custom admin footer message, user contact methods etc. I usually also have a Facebook open graph bootstrap for my custom Facebook plugins and a plugins bootstrap for easier development, providing an abstraction of the Settings API or Mark Jaquith’s awesome hook abstraction.

    I think abstraction is the main benefit of mu-plugins for me.

    • The only problem I have with putting domain mapping there is that … it doesn’t get notified of updates.

    • Right. Do you use it then as a “regular” network activated plugin?

    • I do. It doesn’t show up on my children sites, since it’s network activated, which is the same idea, same idea.

      mu-plugins for me are best for non-interactive plugins. Things I just want done and I know will rarely change.

Trackbacks

Half-Elf? Try Half OFF WordPress ebooks!