The WordPress Loading Process: A Senior Dev’s Guide

I got a call about a membership site that was, for lack of a better term, freaking out. Logged-in users were seeing the public, logged-out content. Intermittently. The client was losing their mind because paying members were complaining, and rightfully so. They had another developer install a “high-performance” caching plugin, and ever since then, it’s been a total mess. That was the smoking gun.

This is a classic plugin conflict, and it almost always comes down to not understanding the WordPress loading process. One plugin is doing its job before another has had a chance to even wake up. In this case, the caching plugin was grabbing and storing a static version of the page before the membership plugin could even run its checks to see if the current user was logged in. Nightmare.

Why Changing Hooks Wasn’t Enough

My first thought, the “obvious” fix, was to just make the membership plugin’s functions fire earlier. Maybe move its main action from the init hook to plugins_loaded. That hook, as the name implies, fires right after all active plugins are loaded. And yeah, in a simple world, that might have worked. But it did absolutely nothing. Trust me on this, it’s frustrating when the logical fix fails.

Here’s the kicker: the caching plugin was installed as a “must-use” plugin (an mu-plugin). WordPress loads anything in the mu-plugins folder before it loads any of the regular plugins from the plugins folder. It doesn’t matter what hook you use. An mu-plugin always gets to the front of the line. The previous dev thought he was being clever, but he created a race condition that was impossible to win without understanding the load order.

Forcing Your Plugin to Load First

You can’t just tell WordPress to load your regular plugin before an mu-plugin. But you *can* control the load order of regular plugins. This is essential if your plugin needs to be the first one to act, like for a security tool or, in this case, to beat another plugin to the punch. You do it by filtering the active_plugins option in the database.

/**
 * Ensures that this plugin is always the first one to be loaded.
 *
 * @param array $active_plugins
 *
 * @return array
 */
public function ensure_loaded_first(array $active_plugins)
{
    $basename = plugin_basename(__FILE__);
    $key = array_search($basename, $active_plugins);

    if (false !== $key) {
        array_splice($active_plugins, $key, 1);
        array_unshift($active_plugins, $basename);
    }

    return $active_plugins;
}
add_filter('pre_update_option_active_plugins', 'ensure_loaded_first');
add_filter('pre_update_site_option_active_sitewide_plugins', 'ensure_loaded_first');

This code manipulates the array of active plugins right before WordPress saves it. It finds our plugin, pulls it out of the array, and sticks it right at the beginning. This guarantees it loads first among all *regular* plugins. It’s a clean way to solve a messy problem. For a much deeper technical dive, Carl Alexander wrote a fantastic breakdown of the entire loading process over on his blog.

So, What’s the Real Point?

The point is that the WordPress loading process isn’t just academic. It’s the foundation. Knowing the sequence—from wp-config.php to mu-plugins, then regular plugins, and finally the theme’s functions.php—is the difference between building a solid, reliable site and creating a ticking time bomb of conflicts. You can’t just throw hooks at a problem and hope one sticks. You have to know when they fire and in what context.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.