Have you ever written plugin code in WordPress that was dependent on another plugin to run? If your code tries to execute before the plugin you require has loaded, obviously, it won’t work.
There are plugins available to modify the load order of plugins, but that really isn’t necessary. There’s a very simple way to make sure that you plugin doesn’t run until it’s ready.
How WordPress Loads Plugins
First, let’s look at how WordPress loads plugins.
Within the wp-content folder, you’ll sometimes see a “mu-plugins” folder. The “mu” in this case stands for “must use,” and plugins in this folder get loaded first. The mu-plugins folder is optional, so it may not always be there (and often when I’ve seen it, it was empty).
If your site is a WordPress multisite network, any network-activated plugins will get loaded next.
Finally, the remaining active plugins are loaded alphabetically.
Using mu-plugins
It might seem like a good idea to just move the plugin that your plugin requires to the mu-plugins folder, but this has its drawbacks. Plugins in the mu-plugins folder won’t show in the list of plugins and don’t get the benefit of dashboard notifications for available updates. Also, WordPress doesn’t look for PHP files in subfolders of mu-plugins, meaning it’s really only great for single-file plugins (unless you create a proxy loader).
Using the plugins_loaded hook
A better way to make sure that your plugin code runs after other plugins (specifically those upon which your plugin depends) is to use the plugins_loaded hook.
In WordPress, a hook is a point at which you can attach your code to specific WordPress actions. By specifying that your plugin code shouldn’t attempt to run until other plugins have loaded, you’ll know that your plugin’s dependent code will be there.
At my company, Webinology, we’re very fond of using the WordPress Plugin Boilerplate for our projects. Here’s an example of how we can employ the plugins_loaded hook in boilerplate code.
In the plugin’s main file, scroll to the bottom and you should see something like this:
/**
* Begins execution of the plugin.
*
* Since everything within the plugin is registered via hooks,
* then kicking off the plugin from this point in the file does
* not affect the page life cycle.
*
* @since 1.0.0
*/
function run_my_awesome_plugin() {
$plugin = new My_Awesome_Plugin();
$plugin->run();
}
run_my_awesome_plugin();
Let’s make a simple modification to this section of the code:
function run_my_awesome_plugin() {
$plugin = new My_Awesome_Plugin();
$plugin->run();
}
add_action('plugins_loaded', 'run_my_awesome_plugin');
With the add_action function, we’re passing WordPress a hook (“plugins_loaded”) and telling it what to do when that section of their code executes — in this case, kick off our plugin. (Note that we removed the “run_my_awesome_plugin()” statement that normally fires off the plugin.) While our plugin will still load in its normal order, it won’t run until we’re certain that all is ready.
Problem solved!
P.S.
It’s also best practice to check to make sure that any plugins upon which your code is dependent are actually installed, not just loaded. One way to do this is to check to see if a class or function from the plugin you require exists. In the case of Boilerplate, it would make sense to include such a check in the same run_* function shown above.