Using an autoloader in mu-plugins to banish includes in your themes

Have you ever found yourself copying and pasting the same PHP class between themes on a WordPress Multisite install? Maybe you wrote one to pull and parse a feed. Perhaps you don’t even use a class, just a snippet of code from the functions.php that gets copied and pasted. If the answer is yes, you might be interested in this…

Mu-plugins is a directory that sits under /wp-content in WordPress Multisite installations, the “mu” part stands for “Must Use” and anything that you put in there is automatically run like any other WordPress plugin automatically, it doesn’t appear in the usual WordPress plugin interface and they cannot be disabled. If you want to read more, then head over to and read their article on Must Use Plugins.

Now, this Must Use plugin directory can be very useful if you’re running a large Multisite install (or small, for that matter), as the plugins can’t be disabled from the dashboard, they provide a very robust method of extending WordPress functionality across your network. It’s this fact that lead me to develop an autoloader which allows you to create a central repository for all of your classes and helper functions, eliminating the need for multiple include statements in your themes. If you’re interested in how I accomplished this, read on.

The first thing I did was create a file that would sit in the root of the mu-plugins directory. Note that WordPress will not recurse into sub-directories inside of mu-plugins, so if you’ve got a large collection of files you want to run inside of this directory, you’ll either have to include them in a PHP file in the root or build some sort of autoloader. A big chunk of includes is pretty messy, so I chose the autoloader route.

The way I wanted to do this was to create a directory of “modules” which the autoloader would parse and load, then, whenever I created a new instance of a class in a theme, the autoloader would automatically search for this module and if it existed, it would include that file for me. So, for example, if I wrote the following in the functions.php in a theme:

I want the autoloader to look for /wp-content/mu-plugins/modules/FeedManager/FeedManager.class.php, and if it existed, then include it. To get this to work, I created a file called autoloader.php with the following code in /wp-content/mu-plugins:

Then, all I needed to do was create the directory /wp-content/mu-plugins/FeedManager/FeedManager.class.php, and we’re done!

I could now go into any theme and use:

This is a very simple example, but I think it’s much better than manually including all of your files and it’s just one little step in an effort to keep everything tidy – something which becomes priority on larger networks.

By the way; there’s no reason why you can’t use mu-plugins in a similar fashion to create your own network-wide theme functions file, I’ll write a post up on that shortly.

The first post

Well, here it is, my first blog post.

I’ve been meaning to get around to doing this for quite some time, well, over two years if I’m honest. During that time I have developed three different themes which all made it to that infamous “almost there” stage before I started again from scratch, reasons include me looking at it and thinking “it’s too corporate”, “the code in here sucks” or simply because I wanted a fresh start.

But now, with this first post, I am going for it! I am finally going to start doing what I said I’d do all those years ago, so wish me luck!