WordPress Multisite Network Functions: switch_to_blog & More

If you have ever managed more than a few WordPress websites, you know the drill: log in here, update a plugin there, check the spam folder on another site, and repeat. It gets exhausting. WordPress came up with a brilliant solution for this called WordPress Multisite. It allows you to run a whole network of websites from a single WordPress installation.

But here is the thing: having a Multisite network is only half the battle. The real magic happens when you learn how to control it programmatically. That is exactly where Multisite Network Functions come into play.

In this article, we will look at what they are, why they matter, and how you can use them to manage your network like a seasoned developer. No overly technical jargon —just a practical breakdown of how to make Multisite work for you.

The Big Picture: How a Multisite Network Actually Works

Before we start throwing function names around, let’s get our mental model straight. Imagine a traditional WordPress site as a single-family home. It has its own front door, its own plumbing, and its own electrical system.

A WordPress Multisite is more like an apartment complex. All the apartments (your individual websites) share the same foundation, the same main water line, and the same underlying architecture. However, each apartment has its own locked door, its own interior design, and its own tenants.

To manage this apartment complex, you need a master key and an intercom system. In WordPress, the master dashboard (Network Admin) is your intercom, but the Multisite Network Functions are your master keys. They allow your code to walk into any apartment, check the plumbing, change a lightbulb, or even build a new apartment from scratch.

Here is a visual representation of how this architecture looks under the hood:

Note: You might notice that in the WordPress core code, individual sites within a network are often referred to as “blogs.” Don’t let this confuse you. A “blog” in the coding world of Multisite just means an individual site. A school website and a separate teacher blog are both technically “blogs” in the database table wp_blogs.

Category 1: Gathering Intelligence (The “Who Am I?” Functions)

When you are writing code in a normal WordPress environment, functions like get_the_ID() or home_url() work perfectly because there is only one site. But in a Multisite environment, your code could be executing anywhere. Before you do anything, you need to know exactly where you are.

1. get_current_blog_id()

This is the most basic, yet most crucial function. It simply returns the numeric ID of the site the user is currently viewing.

• Why it matters: If you want to show a special banner only on Site ID #3, you need this function to figure out if you are on Site ID #3.

2. get_blog_details( $blog_id )

While the previous function just gives you a number, this function gives you the whole profile. If you feed it a Site ID, it hands back an object packed with information.

• What it returns: The site’s domain, path, registered date, last updated date, whether it’s public or archived, and more.
• Real-world example: Let’s say you are building a central dashboard widget for the Super Admin. You want to list all the sites in your network and show when they were last updated. You would loop through your sites and use get_blog_details() to grab that last_updated date.

3. get_network()

Sometimes you need information about the entire network itself, not just a single site. This function returns an object containing the network’s ID, domain, path, and the site ID of the main site.

Category 2: Traveling Between Sites (The “Jump” Functions)

This is where Multisite development gets really fun, and slightly dangerous if you aren’t careful. In a standard WordPress setup, the database is entirely focused on one site. In Multisite, every site has its own set of database tables (e.g., wp_2_posts, wp_2_options).

If you are on Site 1 and you want to query the posts of Site 2, standard WP_Query won’t work out of the box. You have to physically “jump” your code over to Site 2.

1. switch_to_blog( $blog_id )

Think of this function as a teleportation device. When you call switch_to_blog( 5 ), WordPress essentially changes the global variables in the background to point to Site 5. Now, get_option() pulls data from Site 5’s options table, and WP_Query pulls posts from Site 5’s posts table.

2. restore_current_blog()

This is the most important rule of Multisite development: Every time you jump, you MUST jump back. If you use switch_to_blog() and forget to use restore_current_blog(), the rest of your page will think it is still on the switched site. Things will break. Menus will display wrong. Styles might disappear. Always pair these two functions together.

Here is exactly how that jump process looks in the code’s memory:

A Quick Coding Example

Let’s say you want to display the title of the latest post from Site ID #4 on your current site. Here is how you do it safely:

// Save the current blog ID just in case
$current_id = get_current_blog_id();

// Jump to Site 4
switch_to_blog( 4 );

// Run a standard WordPress query
$args = array( 'posts_per_page' => 1, 'orderby' => 'date' );
$latest_posts = new WP_Query( $args );

if ( $latest_posts->have_posts() ) {
    while ( $latest_posts->have_posts() ) {
        $latest_posts->the_post();
        echo '<h2>' . get_the_title() . '</h2>';
    }
}
// Reset the post data (good practice)
wp_reset_postdata();

// JUMP BACK! Do not skip this step.
restore_current_blog();

// Save the current blog ID just in case
$current_id = get_current_blog_id();

// Jump to Site 4
switch_to_blog( 4 );

// Run a standard WordPress query
$args = array( 'posts_per_page' => 1, 'orderby' => 'date' );
$latest_posts = new WP_Query( $args );

if ( $latest_posts->have_posts() ) {
    while ( $latest_posts->have_posts() ) {
        $latest_posts->the_post();
        echo '<h2>' . get_the_title() . '</h2>';
    }
}
// Reset the post data (good practice)
wp_reset_postdata();

// JUMP BACK! Do not skip this step.
restore_current_blog();

Category 3: Managing Sites (The “Create, Read, Update, Delete” Functions)

As a Super Admin, you can create and delete sites from the Network Admin UI. But what if you are building an onboarding system where users fill out a form, pay a fee, and a site is automatically generated for them? You need CRUD (Create, Read, Update, Delete) functions.

1. wp_insert_site( $args )

This function creates a new site in the network. You pass it an array of arguments, and it handles the heavy lifting of creating the database tables and adding the entry to the global wp_blogs table.

• What you need to pass: At a minimum, you need a domain, a path (like /newsite/), and a network_id.
• Gotcha: This function does not automatically populate the new site with default themes, widgets, or pages. It just creates the empty shell. You usually have to hook into the wp_initialize_site action to set those up.

2. wp_update_site( $site_id, $args )

Need to change a site from public to private? Want to change its domain name? This function lets you update the metadata of an existing site.

3. wp_delete_site( $site_id )

This is the nuclear option. It completely removes a site from the network and drops all of its database tables.

• Warning: There is no “Are you sure?” prompt in code. Once you call this, the data is gone forever. Use it with extreme caution, and usually, you want to check user capabilities (like current_user_can('delete_sites')) before running it.

Category 4: Handling Users Across the Network (The “Bouncer” Functions)

User management in Multisite is wildly different than in a standard setup. In standard WordPress, a user exists in that one site. In Multisite, a user has a Global Account (stored in the main wp_users table), but their role (Admin, Editor, Subscriber) is specific to each individual site.

You can be an Administrator on Site A, but just a Subscriber on Site B. To manage this complex dance, we use specific user functions.

1. add_user_to_blog( $blog_id, $user_id, $role )

This function takes an existing global user and assigns them a specific role on a specific site.

• Example: If you have a university Multisite, and a student signs up for a new class (which is a separate site), you would use this function to add their user ID to the class site with the ‘student’ role.

2. remove_user_from_blog( $user_id, $blog_id )

The exact opposite. It strips the user’s role and access from a specific site.

• Important note: This does not delete the user’s global account. It just kicks them out of that specific “apartment.” If they are only a member of that one site, they become a global user with zero site access (which is fine, they can still log in to edit their global profile if allowed).

3. is_user_member_of_blog( $user_id, $blog_id )

A simple true/false check. You ask it, “Does Bob have access to Site 3?” and it replies with a boolean. This is incredibly useful for conditional logic. For example, you might write a function that says: If the user is a member of the main blog, show them the company-wide announcement banner; otherwise, hide it.

Here is how the user architecture breaks down visually:

Category 5: Network-Wide Settings (The “Boss Level” Options)

In regular WordPress, you use get_option() and update_option() to save things like site title or background color. In Multisite, you have two levels of settings: Site Options (local to one apartment) and Network Options (apply to the whole apartment complex).

For network-wide settings, we use a completely different set of functions.

1. get_network_option( $network_id, $option_name, $default )

This retrieves a setting that applies to the entire network.

• Examples of Network Options: “Are new site registrations allowed?” “Should uploaded files be organized by month and year?” “What is the default theme for new sites?” (For example, the setting site_admins is a network option that stores an array of users who have Super Admin rights).

2. update_network_option( $network_id, $option_name, $value )

This saves or updates a network-wide setting.

• Why not just use update_option? If you use update_option on a Multisite network, it saves that setting to the current site’s options table. If you switch to another site, that setting won’t be there. update_network_option writes directly to the wp_sitemeta table, making it globally accessible.

3. delete_network_option( $network_id, $option_name )

Exactly what it sounds like. It permanently removes a network-wide setting from the database.

To make this crystal clear, let’s compare the two side-by-side:

(Note: Passing null as the $network_id in network functions automatically targets the current network, which is what you want 99% of the time).

Putting It All Together: A Real-World Scenario

Let’s imagine you are building a plugin for a franchise business. The franchise has 50 locations, each with its own site in your Multisite network. The CEO comes to you and says: “I need a button on my Super Admin dashboard that, when clicked, turns on ‘Maintenance Mode’ across ALL 50 sites at the exact same time.”

How would you use the functions we just talked about to achieve this? Here is the mental process and the code:

1. First, you need to get a list of all the sites in the network. You can do this using get_sites().
2. Then, you need to loop through each site.
3. For each site, you need to switch_to_blog().
4. While inside that site, you use update_option() to set a local site option called maintenance_mode to true.
5. Finally, you restore_current_blog() before moving to the next site in the loop.

Here is what that looks like in code:

function activate_global_maintenance_mode() {
    // Ensure only a Super Admin can run this
    if ( ! is_super_admin() ) {
        return;
    }

    // Get an array of all sites in the network
    $all_sites = get_sites();

    // Loop through every site
    foreach ( $all_sites as $site ) {
        // Jump to the specific site
        switch_to_blog( $site->blog_id );

        // Turn on maintenance mode for this specific site
        update_option( 'maintenance_mode_active', '1' );

        // Jump back to the original site
        restore_current_blog();
    }
}

function activate_global_maintenance_mode() {
    // Ensure only a Super Admin can run this
    if ( ! is_super_admin() ) {
        return;
    }

    // Get an array of all sites in the network
    $all_sites = get_sites();

    // Loop through every site
    foreach ( $all_sites as $site ) {
        // Jump to the specific site
        switch_to_blog( $site->blog_id );

        // Turn on maintenance mode for this specific site
        update_option( 'maintenance_mode_active', '1' );

        // Jump back to the original site
        restore_current_blog();
    }
}

This small snippet perfectly demonstrates the power of Multisite functions. Without get_sites(), switch_to_blog(), update_option(), and restore_current_blog(), you would have to manually log into 50 different dashboards and click a checkbox 50 times.

The Pitfalls: What Can Go Wrong?

As awesome as these functions are, Multisite development comes with a few traps that catch beginners off guard. Let me save you some headaches.

The Memory Leak Trap

Every time you call switch_to_blog(), WordPress has to load new data into memory—new options, new taxonomies, new rewrite rules. If you put switch_to_blog() inside a foreach loop of 500 sites, and you forget to call restore_current_blog(), your server will run out of memory and crash. Always, always, always restore the blog.

The “Global” Plugin Trap

If you activate a plugin on the Network Admin level (Network Activate), its code runs on every single site. If your plugin uses a standard WP_Query without checking the current context, it might accidentally mix up posts from different sites if another plugin on the same page is using switch_to_blog(). Always scope your queries carefully.

Caching Complexities

Multisite caching is a beast. If you use a persistent object cache like Redis or Memcached, the keys for get_option() are usually namespaced by site ID. However, get_network_option() keys are namespaced by network ID. If you write custom caching logic, mixing up these namespaces will serve Site A’s cached data to Site B.

WrapUP

Managing a WordPress Multisite network manually is perfectly fine if you have three sites and a lot of free time. But if you are running a serious network—be it a university, a newspaper, or a franchise—relying on the UI alone will eventually bottleneck your growth.

Understanding Multisite Network Functions flips the script. It turns you from someone who maintains a network into someone who architects it. By mastering how to gather site details, safely jump between databases with switch_to_blog, manage global user roles, and separate site options from network options, you unlock the true power of what WordPress Multisite was designed to do.

Take these functions, play with them in a safe testing environment, and start automating your network. You’ll wonder how you ever lived without them.

References

1. WordPress Developer Handbook: Multisite Functions
2. WordPress Developer Handbook: switch_to_blog()
3. WordPress Developer Handbook: get_network_option()

FAQs