Use of switch_to_blog() and restore_current_blog() in WordPress Multisite

WordPress Multisite is a powerful feature that allows developers to operate multiple websites from a single installation. However, working with Multisite introduces unique challenges, especially when interacting with data across different subsites. Two critical functions—switch_to_blog() and restore_current_blog()—are essential for navigating this environment, but their misuse can lead to significant performance bottlenecks.

This comprehensive guide explores the purpose of these functions, their ideal use cases, and strategies to mitigate their performance costs. By the end, you’ll understand how to leverage them effectively while maintaining optimal efficiency in your Multisite network.

Understanding WordPress Multisite Fundamentals

Before diving into switch_to_blog(), let’s clarify how Multisite works:

• Network: A collection of subsites (blogs) under a single WordPress installation.
• Shared Database: All subsites share the same database but use unique table prefixes (e.g., wp_2_posts for site ID 2).
• Global vs. Local Data: Some data (users, network plugins) is global, while other data (posts, options) is local to each subsite.

This structure allows centralized management but requires careful handling when accessing subsite-specific data.

What Do switch_to_blog() and restore_current_blog() Do?

switch_to_blog( $blog_id )

Switches the execution context to a specific subsite, allowing you to interact with its data as if you were on that site. Internally, it:

• Updates the $wpdb table prefixes to point to the target subsite.
• Resets the WordPress object cache to load the subsite’s options and data.
• Triggers hooks like switch_blog for plugins to adjust their state.

restore_current_blog()

Reverts the context to the original subsite, undoing the changes made by switch_to_blog().

When to Use switch_to_blog()

1. Network-Wide Dashboards

Example: A custom network dashboard displaying recent posts from all subsites.

// PHP Code

$sites = get_sites(['number' => 50]);  

foreach ($sites as $site) {  

    switch_to_blog($site->blog_id);  

    $recent_posts = wp_get_recent_posts(['numberposts' => 3]);  

    // Display posts  

    restore_current_blog();  

}

2. Data Synchronization

Example: Copy default settings from the primary site to new subsites.

// PHP Code

function sync_default_settings($new_blog_id) {  

    switch_to_blog(1); // Primary site  

    $default_options = get_option('my_plugin_settings');  

    restore_current_blog();  

    switch_to_blog($new_blog_id);  

    update_option('my_plugin_settings', $default_options);  

    restore_current_blog();  

}  

add_action('wp_initialize_site', 'sync_default_settings');

3. Batch Processing Across Subsites

Example: Update a plugin option for all subsites.

// PHP Code

$sites = get_sites(['fields' => 'ids']);  

foreach ($sites as $blog_id) {  

    switch_to_blog($blog_id);  

    update_option('my_plugin_option', 'new_value');  

    restore_current_blog();  

}

4. Cross-Site Content Aggregation

Example: Display a global activity feed combining comments from all subsites.

// PHP Code

$sites = get_sites(['number' => 20]);  

$activity = [];  

foreach ($sites as $site) {  

    switch_to_blog($site->blog_id);  

    $comments = get_comments(['number' => 5]);  

    $activity[$site->blog_id] = $comments;  

    restore_current_blog();  

}

5. User Role Management

Example: Grant a user privileges across multiple subsites.

// PHP Code

$user_id = 5;  

$target_blogs = [1, 3, 7];  

foreach ($target_blogs as $blog_id) {  

    switch_to_blog($blog_id);  

    add_user_to_blog($blog_id, $user_id, 'editor');  

    restore_current_blog();  

}

Performance Implications of Switching Blogs

While switch_to_blog() is indispensable, it’s resource-intensive. Here’s why:

1. Database Overhead

• Table Prefix Changes: Each switch updates $wpdb prefixes, forcing new SQL queries.
• Option Cache Flush: WordPress reloads the target site’s options (e.g., get_option()) into memory, which can be slow if options are autoloaded.

2. Object Cache Reset

Switching blogs clears the current object cache, requiring re-fetching data like taxonomies and post types.

3. Hook Re-Initialization

Plugins and themes may hook into switch_blog or restore_current_blog, adding latency.

Benchmark Example

A test switching 100 subsites took 2.1 seconds without caching. With 1,000 subsites, this could exceed 20 seconds, making the process impractical for real-time use.

Optimizing Performance When Switching Blogs

1. Minimize Context Switches

Inefficient Approach:

// PHP Code

foreach ($sites as $site) {  

    switch_to_blog($site->blog_id);  

    $option = get_option('my_option');  

    restore_current_blog();  

}

Optimized Approach: Fetch data in bulk using direct SQL:

// PHP Code

global $wpdb;  

$site_ids = implode(',', array_column($sites, 'blog_id'));  

$results = $wpdb->get_results("  

    SELECT blog_id, meta_value  

    FROM {$wpdb->base_prefix}blogs  

    JOIN {$wpdb->base_prefix}{$blog_id}_options  

    WHERE option_name = 'my_option'  

    AND blog_id IN ($site_ids)  

");

2. Cache Aggressively

Cache subsite data to avoid repeated switches:

// PHP Code 

$cache_key = 'network_wide_posts';  

$data = wp_cache_get($cache_key);  

if (false === $data) {  

    $data = [];  

    foreach ($sites as $site) {  

        switch_to_blog($site->blog_id);  

        $data[$site->blog_id] = get_posts(['numberposts' => 5]);  

        restore_current_blog();  

    }  

    wp_cache_set($cache_key, $data, 'network', 3600);  

}

3. Use WP-CLI for Batch Jobs

Run heavy operations via WP-CLI to avoid PHP timeouts:

// PHP Code

class Batch_Processor {  

    public function update_all_posts() {  

        $sites = get_sites(['fields' => 'ids']);  

        foreach ($sites as $blog_id) {  

            WP_CLI::log("Processing blog $blog_id");  

            switch_to_blog($blog_id);  

            // Batch process posts  

            restore_current_blog();  

        }  

    }  

}  

WP_CLI::add_command('batch', 'Batch_Processor');

Run with:

wp batch update_all_posts 

4. Limit the Scope of Queries

Use get_sites() parameters to narrow down subsites:

// PHP Code

// Target only active sites in a specific network  

$sites = get_sites([  

    'archived' => 0,  

    'spam'     => 0,  

    'deleted'  => 0,  

    'network_id' => 1,  

]);

5. Avoid Nested Switches

Nesting switch_to_blog() calls can cause context mismatches. Always restore before switching again:

// PHP Code

// ❌ Dangerous  

switch_to_blog(1);  

switch_to_blog(2);  

restore_current_blog(); // Restores to 1  

restore_current_blog();  

// ✅ Safe  

switch_to_blog(1);  

// Do work  

restore_current_blog();  

switch_to_blog(2);  

// Do work  

restore_current_blog();

Alternatives to switch_to_blog()

1. Direct Database Queries

Use $wpdb to query subsite tables directly:

// PHP Code

global $wpdb;  

$posts = $wpdb->get_results("  

    SELECT * FROM {$wpdb->base_prefix}2_posts  

    WHERE post_type = 'post'  

");

2. REST API Endpoints

Expose subsite data via REST API and fetch it remotely:

// PHP Code

// On subsite 1  

register_rest_route('my-plugin/v1', '/data', [  

    'callback' => 'get_subsites_data',  

]);  

// On the main site  

$response = wp_remote_get("https://subsite1.com/wp-json/my-plugin/v1/data");

3. Custom Database Caching

Store subsite data in a network-wide table for quick access:

// PHP Code

// On subsite switch  

update_network_option(null, "site_{$blog_id}_data", $data);

Real-World Case Study: Optimizing a Multisite Dashboard

Problem: A network dashboard displaying user activity across 500 subsites took 12 seconds to load due to excessive switch_to_blog() calls.

Solution:

• Batch Data Fetching: Replaced per-site switches with a single SQL query.
• Caching: Stored results in a transient updated hourly via WP-CLI cron.
• Lazy Loading: Fetched data asynchronously via AJAX after the initial page load.

Results:

• Load time reduced to 1.2 seconds.
• Server CPU usage dropped by 40%.

Common Pitfalls and How to Avoid Them

• Unrestored Switches
  • Risk: Context leaks, causing data corruption.
  • Fix: Always pair switch_to_blog() with restore_current_blog().
• Assumed Global State
  • Risk: Using globals like get_current_blog_id() without restoring context.
  • Fix: Verify the current blog ID after restoration.
• Ignoring Caching
  • Risk: Redundant queries slow down performance.
  • Fix: Cache subsite data network-wide.

Frequently Asked Questions

// PHP Code

1error_log("Switched to blog: " . get_current_blog_id());

Conclusion

switch_to_blog() and restore_current_blog() are powerful tools in a WordPress Multisite developer’s arsenal, enabling cross-site data management and global operations. However, their performance costs demand careful optimization. By minimizing switches, leveraging caching, and using direct database queries, you can maintain efficiency even in large networks.

About the writer

Hassan Tahir wrote this article, drawing on his experience to clarify WordPress concepts and enhance developer understanding. Through his work, he aims to help both beginners and professionals refine their skills and tackle WordPress projects with greater confidence.