get_current_blog_id et switch_to_blog : la paire qu’on doit refermer par restore

Un appel à switch_to_blog() sans son restore_current_blog() correspondant, plus loin dans le script, et c’est tout le code exécuté après ce point qui continue de croire être sur le site initial — options, requêtes, chemins de fichiers compris. Sur un réseau multisite, cette discipline n’est pas optionnelle : elle conditionne la fiabilité de tout script qui doit lire ou écrire sur plusieurs sites du même réseau.

Trois fonctions natives forment un ensemble cohérent pour ce besoin : get_current_blog_id() pour connaître le site courant, switch_to_blog() pour en changer temporairement, et restore_current_blog() pour revenir en arrière proprement.

Ce que change réellement switch_to_blog

switch_to_blog( int $new_blog_id ) ne se contente pas de changer une variable : elle recharge les tables associées au site cible (options, métadonnées, taxonomies) dans le contexte global de WordPress. Toute fonction appelée après ce point — get_option(), WP_Query, get_posts() — agit alors comme si elle s’exécutait directement sur le site cible, pas sur celui d’origine.

C’est justement cette portée globale qui rend l’oubli du restore_current_blog() dangereux : contrairement à une variable locale qui disparaîtrait naturellement en sortant d’une fonction, ce changement de contexte persiste pour tout le reste de la requête en cours, y compris dans du code totalement indépendant appelé plus tard.

Checklist avant d’écrire une boucle switch_to_blog

1. Vérifier avec get_current_blog_id() quel est le site de départ, si cette information doit être réutilisée après la boucle.
2. Encadrer chaque switch_to_blog() d’un restore_current_blog() correspondant, dans la même fonction, jamais dans deux fonctions séparées.
3. Utiliser try/finally si le code entre les deux appels peut lever une exception, pour garantir que restore_current_blog() s’exécute même en cas d’erreur.
4. Ne jamais imbriquer un switch_to_blog() dans une fonction de rappel exécutée en dehors du contrôle direct du script, comme un hook déclenché ailleurs.
5. Vérifier en fin de script, avec get_current_blog_id(), que le site courant correspond bien à celui de départ.

Un exemple : recopier un réglage sur tous les sites du réseau

Une extension réseau qui doit appliquer un même réglage à chaque site pourrait s’écrire ainsi, avec la discipline de fermeture systématique :

function reseau_appliquer_reglage_a_tous_les_sites( $valeur ) {
    $sites = get_sites( array( 'fields' => 'ids' ) );

    foreach ( $sites as $blog_id ) {
        switch_to_blog( $blog_id );

        update_option( 'reglage_partage_reseau', $valeur );

        restore_current_blog();
    }
}

Remarquez que restore_current_blog() se trouve à l’intérieur de la boucle, juste après le traitement, et non regroupé une seule fois à la fin : chaque switch_to_blog() doit être refermé avant le suivant, pour ne jamais empiler des changements de contexte les uns sur les autres sans les dépiler correctement.

Le piège d’un retour anticipé

Un return placé entre switch_to_blog() et restore_current_blog() — pour sortir d’une fonction en cas de condition particulière — laisse le contexte basculé sans jamais le restaurer. C’est l’erreur la plus fréquente rencontrée en revue de code sur ce sujet : une condition d’arrêt anticipé ajoutée après coup, sans repenser l’ensemble de la structure.

• Préférer une structure qui place toute condition de sortie avant le switch_to_blog(), jamais après.
• À défaut, restaurer explicitement le contexte juste avant chaque return intermédiaire.
• WP_Site_Query et les fonctions du cœur réseau restent utilisables sans switch_to_blog() pour de simples lectures de métadonnées de site, ce qui évite parfois le problème entièrement.

Sur un script réseau qui parcourt plusieurs sites, mieux vaut structurer chaque itération autour d’un seul switch_to_blog et d’un seul restore_current_blog, sans branche de sortie intermédiaire entre les deux.

En résumé

La paire switch_to_blog() / restore_current_blog() n’a de sens que si elle est toujours complète : chaque changement de contexte doit être refermé avant que le script ne continue son exécution normale. get_current_blog_id() sert de vérification à la fois avant et après, pour confirmer que le contexte est bien celui attendu. Cette discipline coûte peu à respecter et évite des bugs particulièrement difficiles à diagnostiquer, puisqu’ils se manifestent souvent loin du code fautif.