How to manage a multisite: create sites and share users in WordPress

Contents

Introduction and overview

This article is a complete, in-depth tutorial for WordPress Multisite administration focused on: enabling multisite, creating sites, and sharing users across sites. It covers configuration, UI steps, programmatic methods (PHP WP-CLI), database concepts, cookie and DNS/server requirements, domain mapping, troubleshooting, security and best practices. Code examples are included for every relevant operation and appear in language-labeled code blocks as requested.

Concepts you must understand before you begin

  • Network (Multisite) — A single WordPress installation that hosts multiple sites (subsites). A Network Admin (Super Admin) manages the entire network and can create new sites, manage themes/plugins network-wide, and control network-wide settings.
  • Subdomain vs Subdirectory — Two multisite modes:
    • Subdomains: site1.example.com, site2.example.com
    • Subdirectories: example.com/site1, example.com/site2
  • Users and site membership — In Multisite, wp_users and wp_usermeta are shared across the network. A user exists globally once, but they must be assigned to each site where they need a role (administrator/editor/author/etc.).
  • Super Admin (Network Admin) — A user with network-level privileges that bypass per-site role restrictions. Super Admins can manage plugins and themes across the network and can access all site dashboards.
  • Domain mapping — Mapping custom domains to subsites. This requires DNS and server configuration and is handled via plugins or native techniques depending on needs.

Prerequisites

  • Working WordPress installation (single-site) with file system and database access.
  • Ability to edit wp-config.php and .htaccess (or Nginx vhost) on the server.
  • For subdomains: wildcard DNS (A record .example.com) and webserver configured to accept any subdomain.
  • For production: backups, testing environment, and plan for plugin compatibility.

Step 1 — Enable Multisite (convert single site to network)

  1. Backup your entire site (files database).
  2. Open wp-config.php and add the following line above / Thats all, stop editing! Happy publishing. /:
lt?php
define(WP_ALLOW_MULTISITE, true)
?gt

After adding that, log in to WordPress and go to Tools → Network Setup. WordPress will ask whether you want subdomains or subdirectories (subdomains require wildcard DNS). Follow on-screen instructions.

  1. WordPress will show code snippets for wp-config.php and .htaccess. Copy those instructions exactly into your files. Example snippets below (typical):

wp-config.php additions

lt?php
define(WP_ALLOW_MULTISITE, true)
/ After installing the network, add these lines as shown by WP /
define(MULTISITE, true)
define(SUBDOMAIN_INSTALL, true) // true = subdomains, false = subdirectories
define(DOMAIN_CURRENT_SITE, example.com)
define(PATH_CURRENT_SITE, /)
define(SITE_ID_CURRENT_SITE, 1)
define(BLOG_ID_CURRENT_SITE, 1)
?gt

.htaccess (Apache) typical multisite rules

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php - [L]

# uploaded files
RewriteRule ^files/(. ) wp-includes/ms-files.php?file=1 [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]
# END WordPress

If you use Nginx, youll configure rewrites in the server block instead of .htaccess. A sample Nginx config is shown later.

Step 2 — Basic Network Admin UI tasks

  • Access Network Admin: My Sites → Network Admin → Dashboard. This is the central hub for multisite management.
  • Create a new site (UI): Network Admin → Sites → Add New:
    • Site Address (subdomain or path)
    • Site Title
    • Admin Email (an existing user or new user will be created)
  • Manage plugins themes: Install plugins as network-enabled or enable per-site. Activate themes for use by sites (Network Admin → Themes).
  • Users: Network Admin → Users to see all users across the network. Manage super admins here.

Understanding how users are stored and how membership works

Important database concepts:

  • wp_users — Global user table containing user credentials for the entire network.
  • wp_usermeta — Stores per-user metadata across the network. Site membership and capabilities are stored here using keys named like wp_#_capabilities, wp_#_user_level (where # is the blog ID or table prefix variant).
  • When you add a user to a subsite through the site dashboard, WordPress writes or updates entries in wp_usermeta to give that user capabilities on that site. The user row in wp_users remains unique.

How to add users and share users across sites — UI and programmatic

UI methods

  • To add an existing user to a specific site: Go to that sites Dashboard → Users → Add New, enter the existing users email or username and assign a role. This action writes the capability meta in wp_usermeta.
  • To add an existing user network-wide: Use Network Admin → Users → Add Existing User and then assign site memberships as needed.
  • To make a user a Super Admin: Network Admin → Users → Edit → Grant Super Admin (or use the Super Admin link in the Network Admin users list).

Programmatic methods (PHP)

Use WordPress functions in plugin or mu-plugin code. Examples:

Create a new user and give them to a site

// Create a user and add them to a site with a role
email   = joe@example.com
username= joe
password= wp_generate_password( 12, false )
user_id = wp_create_user( username, password, email )

if ( is_wp_error( user_id ) ) {
    // handle error
} else {
    // blog_id is the sites ID (1 = main)
    blog_id = 2
    role = editor
    add_user_to_blog( blog_id, user_id, role )
}

Add an existing user to many sites and set roles

// Add existing user to a list of sites
user_id = 123 // existing WP user ID
sites   = array( 2, 3, 4 ) // blog IDs
foreach ( sites as blog_id ) {
    if ( ! is_user_member_of_blog( user_id, blog_id ) ) {
        add_user_to_blog( blog_id, user_id, author )
    }
}

Grant and revoke Super Admin programmatically

// grant
grant_super_admin( user_id )

// revoke
revoke_super_admin( user_id )

Switch to another blog while running code

// When performing multiple operations on another blog
switch_to_blog( blog_id )
// perform site-specific functions: update options, create pages, etc.
restore_current_blog()

Programmatic site creation

Two common approaches: wpmu_create_blog() (older and widely used) and wp_insert_site() (newer API check your WP version). Examples:

// Using wpmu_create_blog (works on many WP versions)
domain = site1.example.com
path   = /
title  = Site 1
user_id = 1 // admin to own the site
site_id = wpmu_create_blog( domain, path, title, user_id )

// Using wp_insert_site (WP 4.6  and later)
args = array(
  domain => site2.example.com,
  path   => /,
  title  => Site 2,
  network_id => 1,
)
new_site_id = wp_insert_site( args )

WP-CLI examples

# Create a new site (subdirectory or subdomain depends on network)
wp site create --slug=site3 --title=Site 3 --email=admin@example.com

# Create a user
wp user create joe joe@example.com --user_pass=secret

# Add an existing user to a site with a role
wp user add-role joe author --url=https://site3.example.com

# Make a user super-admin
wp super-admin add joe

Sharing users: deep dive into usermeta keys and programmatic details

When a user is added to a particular site, wp_usermeta receives entries keyed to that site such as:

  • wp_2_capabilities — serialized array of capabilities for that site (administrator/editor/etc.).
  • wp_2_user_level — legacy numeric user level.
  • Other plugins may create keys namespaced similarly for per-site settings.

Instead of writing usermeta directly, always use WordPress API functions:

  • add_user_to_blog(blog_id, user_id, role)
  • is_user_member_of_blog(user_id, blog_id)
  • get_blogs_of_user(user_id)

Single sign-on and cookie behaviour across subdomains

Login cookies in multisite can behave differently depending on subdomain vs subdirectory and on cookie domain constants. Typical adjustments:

// Example: in wp-config.php you can try disabling cookie domain to avoid cross-subdomain issues
define( COOKIE_DOMAIN, false )

// If you experience admin redirects or login loop issues, check these permutations carefully:
// define(ADMIN_COOKIE_PATH, /)
// define(COOKIEPATH, /)
// define(SITECOOKIEPATH, /)

For subdomain installs, ensure your server and browser accept cookies for the main domain. For cookie problems, try clearing cookies, testing with a private window, and verifying the cookie domain returned by responses.

Domain mapping (assigning custom domains to subsites)

Domain mapping allows you to make site1.example.com use domain1.com. Key things to address:

  • DNS: The mapped domain must point to your server (A record or CNAME).
  • Web server: vhost must accept requests for the mapped domain and route them to the same WordPress installation. Wildcard vhosts or explicit vhost entries per domain are common solutions.
  • WordPress: Historically domain-mapping plugins (WordPress MU Domain Mapping) were common. Modern multisite can handle domain replacements by updating the sites domain setting (Network Admin → Sites → Edit → Site Address) or via code.
  • Use a tested plugin (e.g. Mercator or maintained domain mapping plugins) if you need a friendly UI or complex mapping rules. Always test redirect and HTTPS handling.

When mapping, set the sites domain to the mapped domain in the network sites settings and check that siteurl and home reflect the desired domain for that blog id.

Nginx example configuration for multisite (subdomain)

# This is an Nginx server block snippet
server {
    listen 80
    server_name .example.com  # note leading dot for wildcard
    root /var/www/html        # path to WP install

    index index.php

    location / {
        try_files uri uri/ /index.php?args
    }

    location ~ .php {
        fastcgi_pass unix:/var/run/php-fpm.sock
        fastcgi_index index.php
        include fastcgi_params
        fastcgi_param SCRIPT_FILENAME document_rootfastcgi_script_name
    }

    # upload rules and caching as needed
}

Plugins and tools that help manage users and multisite

  • User Role Editor (works network-activated) — to manage roles and capabilities per site
  • Multisite User Management plugins — tools exist to bulk-add users to many sites or replicate roles across sites
  • WP-CLI — essential for scripted operations (site creation, user provisioning, data imports)
  • Domain mapping plugins — Mercator, WordPress MU Domain Mapping fork (verify compatibility)
  • Object cache (Redis/Memcached) — recommended for large networks with many users/sites

Migrating users between networks or to/from single-site

  1. Export users (WP-CLI, plugins, or SQL). When migrating between multisite installs, remember:
    • wp_users is global — merging requires care to avoid duplicate email/username conflicts.
    • wp_usermeta contains per-site entries you may need to update meta keys to match new blog IDs (search replace for prefix wp_#_capabilities).
  2. When migrating domain-mapped sites, update site URLs and mapped domain entries post-import.
  3. Test logins and role assignments on a staging server before switching DNS for production.

Troubleshooting common problems

  • White screen after enabling multisite: Check wp-config.php edits. Restore backup if necessary. Enable WP_DEBUG to gather errors.
  • 403/404 for subdomain sites: Check DNS and server vhost ensure wildcard DNS and server_name configuration.
  • Users cant access a site: Verify the user has the correct wp_{blogid}_capabilities key in wp_usermeta, or use add_user_to_blog() to add membership.
  • Login loops: Cookie domain mismatch try define(COOKIE_DOMAIN, false) in wp-config.php and test.
  • Plugins behave inconsistently per site: Check whether the plugin is network-activated vs activated per site and plugin compatibility with multisite.

Security recommendations

  • Limit the number of super admins to the minimum required.
  • Use strong passwords and consider two-factor authentication for site admins.
  • Keep plugins and themes updated network-wide prefer network activation for security-critical plugins if all sites need them.
  • Use least-privilege roles: give editors/authors only the capabilities needed.
  • Audit user activity and regularly review which users are members of which sites.

Performance and scaling considerations

  • Large networks with tens of thousands of users or sites should employ object caching (Redis/Memcached), an opcode cache, and a strong DB server.
  • Database grows fast: monitor wp_usermeta size and consider splitting logs, sessions, or analytics out of core tables if necessary.
  • Use a CDN for static assets and consider network-wide optimizations for uploads and media offloading.

Advanced programmatic examples

Bulk add users from CSV to multiple sites

// Simplified example: insert users and add them to one or more sites
csv = /path/to/users.csv // CSV columns: email,username,password,site_ids(comma-separated)
if ( ( handle = fopen( csv, r ) ) !== false ) {
    while ( ( data = fgetcsv( handle ) ) !== false ) {
        list( email, username, password, site_csv ) = data
        user_id = email_exists( email ) ? email_exists( email ) : wp_create_user( username, password, email )
        site_ids = array_filter( array_map( intval, explode( ,, site_csv ) ) )
        foreach ( site_ids as blog_id ) {
            if ( ! is_user_member_of_blog( user_id, blog_id ) ) {
                add_user_to_blog( blog_id, user_id, subscriber )
            }
        }
    }
    fclose( handle )
}

Programmatically copy a roles capabilities from one site to another

function copy_role_capabilities_between_blogs( from_blog_id, to_blog_id, role_name ) {
    switch_to_blog( from_blog_id )
    role = get_role( role_name )
    caps = role ? role->capabilities : array()
    restore_current_blog()

    switch_to_blog( to_blog_id )
    // remove old role and re-create with same caps
    if ( get_role( role_name ) ) {
        remove_role( role_name )
    }
    add_role( role_name, ucfirst( role_name ), caps )
    restore_current_blog()
}

Checklist before going live with multisite

  • Full site backup
  • Test users and site creation flows
  • DNS and server vhost tested for all domain/subdomain scenarios
  • Plugin compatibility audit for multisite
  • Performance tuning (object cache, DB tuning)
  • Security review (super admins, MFA, roles)
  • Monitoring and backup processes in place

Summary (quick reference)

  • Enable Multisite: add WP_ALLOW_MULTISITE to wp-config.php, run the Network Setup and apply the snippets WordPress gives you.
  • Sites: create via Network Admin UI, programmatically with wpmu_create_blog/wp_insert_site, or WP-CLI.
  • Users: stored globally add users to specific sites with add_user_to_blog() or via UI. Super Admins are network-wide.
  • Domain mapping: requires DNS and server configuration use maintained plugins or site settings carefully.
  • Always test on staging, backup before changes, and follow security and performance best practices.

Appendix — Useful functions commands (cheat sheet)

Function / Command Purpose
add_user_to_blog(blog_id, user_id, role) Adds existing user to a site and assigns role
wpmu_create_blog(domain, path, title, user_id, meta, network_id) Create a new site programmatically
wp_insert_site(args) Newer API to create a site programmatically
wp_create_user / wp_insert_user Create users programmatically
switch_to_blog(blog_id) / restore_current_blog() Run code in the context of another site
wp user create / wp site create / wp user add-role WP-CLI commands to create users, sites and manage roles

Final notes

Implementing and managing WordPress Multisite requires attention to DNS/server configuration, careful handling of users and capabilities, and thorough plugin compatibility testing. Use the functions and commands provided in this article to automate and streamline site creation and user management. Maintain backups, monitor performance, and restrict super admin access to trustworthy administrators.



Acepto donaciones de BAT's mediante el navegador Brave 🙂



Leave a Reply

Your email address will not be published. Required fields are marked *