If you’ve ever worked on a complex WordPress project for a client, you’ve probably heard of WordPress “must use” plugins. If not, you should check out the codex and learn about them! I find that must use plugins are a great way to include required, site-specific functionality without building it directly into a theme. Using the must use plugin directory ensures that your plugin won’t accidentally get deactivated which helps avoid unnecessary support requests and other problems.
So, Why Bother Making a Plugin at All?
Building a lot of custom functionality into a WordPress theme is generally considered bad practice. There are a number of arguments against doing it, but the one that resonates with me has to do with portability and future-friendliness. If a site owner decides to change the theme on their website, they will lose any custom functionality built into their current theme. This includes custom post types, custom taxonomies, and everything else that has been built into that theme.
Building a bunch of functionality into a theme forces a site owner to either continue using their current theme, or pay someone to port the functionality over to a new theme or (if they’re lucky) a plugin. That’s not cool.
Some people argue that building functionality into a theme is ideal because it’s usually faster and it means more money for you. Since your client has come back to you again and again for changes and updates, you’re basically guaranteed repeat business! Sounds great, right? Maybe… but what happens when your client learns about the difference between a plugin and a theme? What happens when they realize that you’ve basically been holding them hostage? Is that really a situation you want to find yourself in? Is the extra business worth your reputation?
Here’s an Idea: Just Do a Good Job!
If you do quality work, your clients will come back to you and they will pay you well. If you care about your business, I think you should always try to do your best. To me, doing your best includes making it easy for other developers to continue where you left off. Besides, when your client comes back to you for more of your awesome WordPress development, it’ll be much easier to make changes and additions to your own work. A little extra work in the beginning can save you countless hours down the road.
Alright, enough of this soap box crap. You’re probably here to find out how to get the URL of a WordPress MU Plugin’s directory, so I’ll explain how I like to do it. This code should also work in a standard plugin.
How to Define the MU-Plugins Directory URL
While MU Plugins are great, they also have a few issues. One problem I’ve run into is that there isn’t a very straight-forward way to get the plugin URL inside of your plugin files. In order to simplify things, I like to define some reusable URL constants and use them throughout my plugin.
I typically define my URLs in the main plugin file using a WordPress function called plugins_url. You can learn more about how to use plugins_url correctly in the codex.
Here’s an example:
Once you’ve defined the plugin URLs, you can then use them throughout your plugin. For instance, you could use your defined URLs to include a JavaScript file in your must-use plugin.
Here’s an example:
That’s pretty much it! Because of the way mu-plugins work, you’ll also need to place a file directly in the mu-plugins directory in order to load your main plugin file.
Here’s an example of how to do that:
The codex has a good rundown of the other issues with the mu-plugins directory. It’s also worth nothing that any plugin in the mu-plugins folder will run on your entire network if your are using WordPress Multisite. Thanks to Andrea R from WordPress eBooks for reminding me to mention this.
If you have any questions or suggestions for how to improve my code or my explanation, please leave them in the comments.