Chapitre 11.5 — Multisite

⏱️ TL;DR — Le multisite transforme une installation WordPress en réseau de sites partageant le même cœur, les mêmes plugins/thèmes et la même base (avec des tables préfixées par site). Un rôle nouveau apparaît : le Super Admin (gère le réseau : sites, plugins réseau, utilisateurs globaux). Idéal pour un portefeuille de sites (franchises, universités, multilingue par site). Pour le développeur, quelques spécificités : switch_to_blog(), activation réseau vs par site, fonctions *_site_option(), et des pièges (chemins, uploads, requêtes cross-site).

🎯 Objectifs

• Comprendre ce qu’est un multisite et quand l’utiliser.
• Distinguer réseau/site, Super Admin/Admin.
• Connaître les fonctions clés du dev multisite (switch_to_blog, options réseau).
• Éviter les pièges spécifiques.

1. Un réseau de sites

Un multisite (activable via wp-config + .htaccess) fait tourner plusieurs sites sur une installation :

• sous-domaines (site1.exemple.com) ou sous-répertoires (exemple.com/site1) ;
• cœur, plugins, thèmes partagés (un seul jeu de fichiers) ;
• base partagée : des tables globales (wp_users, wp_usermeta, wp_blogs, wp_site) + un jeu de tables par site préfixé (wp_2_posts, wp_2_options…).

Quand l’utiliser : un portefeuille de sites similaires à administrer d’un point central (franchises, campus, agences, un site par langue…). Quand l’éviter : des sites sans rapport (préférez des installations séparées — plus simples à isoler/sauvegarder).

2. Super Admin et rôles

• Super Admin : le rôle réseau — gère les sites, les plugins/thèmes du réseau, les utilisateurs globaux, les réglages réseau. Seuls les Super Admins peuvent installer plugins/thèmes.
• Admin de site : administre son site, mais ne peut pas installer de plugins/thèmes (décision réseau) ni gérer le réseau.
• Les utilisateurs sont globaux (un compte peut être membre de plusieurs sites avec des rôles différents).

3. Activation réseau vs par site

Un plugin peut être activé pour tout le réseau (network-activated) ou par site :

• Réseau : actif partout, géré par le Super Admin — pour des fonctionnalités transverses.
• Par site : chaque admin de site (si autorisé) l’active — pour des besoins locaux.

// Détecter le contexte
if ( is_multisite() ) { /* … */ }
if ( is_network_admin() ) { /* écran d'admin réseau */ }
 
// À l'activation, gérer le réseau (créer des tables pour chaque site, etc.)
register_activation_hook( __FILE__, function ( $network_wide ) {
    if ( is_multisite() && $network_wide ) {
        foreach ( get_sites( array( 'fields' => 'ids' ) ) as $blog_id ) {
            switch_to_blog( $blog_id );
            wpr_creer_tables(); // par site
            restore_current_blog();
        }
    } else {
        wpr_creer_tables();
    }
} );

⚠️ Piège n°1 — activation réseau non gérée. Un plugin qui crée une table à l’activation (ch. 5.6) doit, en réseau, le faire pour chaque site (boucle switch_to_blog) et pour les nouveaux sites créés ensuite (hook wp_initialize_site). Sinon, certains sites n’ont pas la table → erreurs.

4. Fonctions clés du dev multisite

• switch_to_blog( $id ) / restore_current_blog() : exécuter du code dans le contexte d’un autre site (lire ses posts, options), puis revenir. Toujours restaurer.
• Options réseau : get_site_option() / update_site_option() (options globales au réseau) vs get_option() (option du site courant).
• get_sites(), get_current_blog_id(), get_blog_details() : introspection du réseau.
• Meta de site : get_site_meta() (métadonnées d’un site du réseau).

⚠️ Piège n°2 — oublier restore_current_blog(). Après switch_to_blog, toujours restore_current_blog() (comme wp_reset_postdata, ch. 5.3) — sinon le reste de la requête tourne dans le mauvais contexte de site (données mélangées). Encadrez chaque switch.

5. Autres spécificités et pièges

• Uploads : chaque site a son espace (uploads/sites/{id}/) — attention aux chemins en dur.
• Domaines/chemins : la config (sous-domaines vs sous-répertoires) impacte URLs et cookies.
• Requêtes cross-site : coûteuses (boucles switch_to_blog) — mettre en cache, éviter à grande échelle.
• Sauvegarde/migration : un multisite est plus complexe à migrer (tables par site, mapping de domaines) — outils dédiés.
• Performance : un réseau à nombreux sites demande une infra adaptée (object cache, etc.).

💡 Pour un dev React — Le multisite est une forme de multi-tenant : un même code, une base partagée, des données isolées par tenant (site). switch_to_blog = « exécuter dans le contexte du tenant X » (comme changer de schéma/DB par tenant), les options réseau = la config globale vs par-tenant. Si vous avez fait du SaaS multi-tenant, l’intuition est là — avec les pièges classiques (isolation, requêtes cross-tenant coûteuses, restauration de contexte).

✏️ Exercices

1. Quand un multisite est-il pertinent, et quand vaut-il mieux des installs séparées ?
2. Votre plugin crée une table à l’activation. Que devez-vous gérer en plus en réseau ?
3. Après switch_to_blog(3), que devez-vous impérativement faire, et pourquoi ?

🧠 Quiz de révision

Chapitre suivant : Migrations & déploiement.