WordPress Hidden Boot Layers: The Parts Nobody Explains

Most developers think they understand how WordPress boots. In reality, what’s usually explained is only the surface. Beneath it lies a set of hidden execution layers that run before, during, and around the normal loading process.

This article explores the deeper internals of WordPress, focusing on parts rarely covered in detail but heavily used in performance tuning, enterprise setups, and advanced customization.

Most articles explain how WordPress boots like this:

index.php → 
      wp-blog-header.php → 
      wp-load.php → 
      wp-config.php → 
      wp-settings.php

There are hidden execution layers that run before, during, and around this flow. These layers are where performance optimizations, enterprise customizations, and advanced routing actually happen.

This guide goes deeper than typical tutorials by covering:

• advanced-cache.php (pre-bootstrap interception)
• Must-Use (MU) plugins
• sunrise.php (multisite routing override)
• wp-settings.php (internal execution engine)

Real WordPress Boot Flow (Expanded)

index.php
└── wp-blog-header.php
    └── wp-load.php
        └── wp-config.php
            ├── advanced-cache.php (if WP_CACHE)
            └── wp-settings.php
                ├── mu-plugins
                ├── sunrise.php (multisite only)
                ├── plugins
                ├── theme
                └── request execution

advanced-cache.php — Intercept Requests Before WordPress Loads

This happens extremely early in the boot process.

This file is conditionally loaded when caching is enabled:

<?php
define('WP_CACHE', true);

wp-content/advanced-cache.php

What Makes It Special?

• Runs before plugins
• Runs before themes
• Minimal WordPress environment
• Perfect for early exits

At this stage:

• No plugins are loaded
• No themes are loaded
• Minimal core is available

This makes it ideal for ultra-fast caching and early request filtering.

Example: Full Page Cache with Early Exit

<?php

$uri = $_SERVER['REQUEST_URI'];
$key = md5($uri);
$file = __DIR__ . "/cache/$key.html";

if (file_exists($file)) {
    header("X-Cache: HIT");
    readfile($file);
    exit;
}

// fallback to WordPress

Less Known Use Cases

• Bot filtering before PHP-heavy logic runs
• Geo-based redirects without booting WP
• Feature flags at infrastructure level

Important: You must keep logic lightweight—no reliance on WordPress APIs.

MU Plugins — The Always-On Execution Layer

MU plugins are commonly used for:

• Security enforcement
• Hosting-level overrides
• Always-on integrations

Unlike regular plugins, they cannot be disabled from the admin UI.

MU plugins live in:

wp-content/mu-plugins/

They are automatically loaded—no activation required.

Execution Order Insight

MU plugins are loaded inside wp-settings.php, but before normal plugins:

<?php
// simplified order
\load_mu_plugins();
\do_action( 'muplugins_loaded' );

\load_plugins();
\do_action( 'plugins_loaded ');

Example: Force Disable XML-RPC Globally

<?php
// wp-content/mu-plugins/security.php

\add_filter( 'xmlrpc_enabled', '__return_false' );

Advanced Pattern: Environment-Level Config

<?php

if ($_SERVER['HTTP_HOST'] === 'staging.example.com') {
    define( 'WP_DEBUG', true );
}

Why MU Plugins Matter

• Cannot be disabled via admin UI
• Ideal for hosting providers
• Guarantees execution order

They act as a control layer above plugins.

sunrise.php — Multisite Boot Hijacking

This file is rarely discussed but extremely powerful.

Enable it via:

<?php
define( 'SUNRISE', true );

Critical Insight

At this stage, WordPress has not yet resolved:

• current_blog
• current_site

You can override both.

Example: Custom Domain Mapping Logic

<?php

$host = $_SERVER['HTTP_HOST'];

$map = [
    'client1.com' => 2,
    'client2.com' => 3
];

if ( isset( $map[$host] ) ) {
    $current_blog = (object) [
        'blog_id' => $map[$host],
        'domain' => $host,
        'path' => '/'
    ];
}

This allows developers to override how WordPress resolves sites in a network.

Undocumented Edge Case

If you set incorrect values here, WordPress may silently fallback or break routing entirely. Debugging this layer is notoriously difficult because logging is limited.

wp-settings.php — The Core Engine

This is where WordPress truly initializes.

What Happens Inside

• Core files are loaded
• Global objects are initialized
• Plugins are loaded
• Themes are initialized
• Hooks begin firing

Hook Execution Timeline

muplugins_loaded
plugins_loaded
setup_theme
after_setup_theme
init
wp_loaded

Example: Hook Timing

<?php

\add_action( 'init', function() {
    error_log( 'Init fired' );
});

Understanding this file gives you full control over execution timing.

Example: Tracking Boot Phases

<?php

foreach ([
    'muplugins_loaded',
    'plugins_loaded',
    'init',
    'wp_loaded'
] as $hook) {
    \add_action( $hook, function() use ( $hook ) {
        error_log( "Hook fired: $hook" );
    });
}

Deep Insight Most Guides Skip

wp-settings.php is not just loading files—it is defining execution order guarantees. Misplacing logic (e.g. using init instead of plugins_loaded) can introduce subtle bugs and performance issues.

Putting It All Together

The full system behaves like a layered pipeline:

• advanced-cache.php → intercept request early
• MU plugins → enforce global behavior
• sunrise.php → control multisite routing
• wp-settings.php → initialize full system

This architecture allows WordPress to be:

• Highly extensible
• Performance-optimized
• Customizable at multiple layers

Mastering these layers allows you to:

• Improve performance dramatically
• Implement advanced routing
• Debug complex issues
• Control execution order precisely

FAQ