Après chaque instance, switch_to_blog()
vous devez appeler restore_current_blog()
pour restaurer le blog actuel (en fait, précédent).
Mais si vous parcourez deux blogs ou plus et que vous appelez switch_to_blog()
chacun d'eux, y a-t-il une raison de ne pas utiliser un autre switch_to_blog()
à la fin de la boucle pour basculer vers le blog d'origine plutôt que d'appeler restore_current_blog()
à chaque passage.
Par exemple
Pourquoi pas:
$original_blog_id = get_current_blog_id();
foreach( $blog_ids as $blog_id ){
switch_to_blog( $blog_id );
//Do stuff
}
switch_to_blog( $original_blog_id );
au lieu de:
foreach( $blog_ids as $blog_id ){
switch_to_blog( $blog_id );
//Do stuff
restore_current_blog_id();
}
Réponses:
Après chaque instance,
switch_to_blog()
vous devez appeler,restore_current_blog()
sinon WP pensera qu'il est en mode "commuté" et peut potentiellement renvoyer des données incorrectes.Si vous affichez le code source pour les deux fonctions, vous verrez ces fonctions pousser / pop les données dans un global appelé
$GLOBALS['_wp_switched_stack']
. Si vous n'appelez pasrestore_current_blog()
après chaqueswitch_to_blog()
,$GLOBALS['_wp_switched_stack']
sera non vide. Si$GLOBALS['_wp_switched_stack']
est non vide, WP pense qu'il est en mode commuté, même si vous êtes revenu au blog d'origine en utilisantswitch_to_blog()
. La fonction de mode commuté estms_is_switched()
et elle affectewp_upload_dir()
. Siwp_upload_dir()
pense qu'il est en mode commuté, il peut renvoyer des données incorrectes.wp_upload_dir()
crée des URL pour le site, c'est donc une fonction très critique.C'est l'utilisation correcte:
la source
wp_upload_dir()
utilise pour générer des URL, mais je vais croire que cela entraîne effectivement un comportement buggé. Dans tous les cas, l'existence dems_is_switched()
moyens mon approche alternative a pour conséquence que la fonction ne se comporte pas comme prévu et pourrait casser les plug-ins ainsi que le noyau. Mercirestore_current_blog()
besoin d'une mise à jour, car elle indique que pour plusieurs commutateurs, il suffit d'enregistrer le courant$blog_id
et d'utiliser plusieursswitch_to_blog()
appels.Si vous souhaitez parcourir plusieurs blogs, il n'est pas nécessaire de restaurer le blog précédent à chaque fois. La seule chose qui grandit est
$GLOBALS['_wp_switched_stack']
- un tableau avec des ID de blog, rien à craindre.Mais gardez à l'esprit,
restore_current_blog()
ne fonctionnera plus (!!!) Après le deuxième changement, car il utilise le blog précédent - qui n'est pas le premier blog à ce moment-là. Alors stockez le premier ID de blog et appelez…… Au lieu de
restore_current_blog()
quand vous avez terminé. Les variables globales doivent être réinitialisées, sinon vous rencontrerez les problèmes mentionnés par @ user42826.L'impact sur les performances est énorme. J'ai effectué quelques tests sur une installation locale avec 12 sites:
Résultat:
L'utilisation
restore_current_blog()
après chaque commutateur double le temps nécessaire à la commutation.la source
restore_current_blog()
ne savais pas pourquoi ne pas simplement retrouver l'ID et l'appel du blog précédentswitch_to_blog()
- un bref aperçu de la source du code et il semble qu'il y ait un peu de duplication de code ...switch_to_blog()
est une API très limitée (cassée) de toute façon. Si WordPress résout ce problème , nous devons quand même refactoriser notre code. Et WordPress ne renoncera jamais à ses bien-aimés mondiaux.I don't think modifying the globals directly is a good idea
, ne le dites pas aux développeurs de base wp;)Merci à la réponse @toscho. Cette demande en file d'attente de WP - voir les mises à jour ici . Jusqu'à ce que cela soit corrigé dans WP, si quelqu'un veut désespérément utiliser la norme
restore_current_blog()
, alors voici une autre méthode (veuillez corriger si je me trompe):faites votre fonction, c.-à-d.
et exécutez une seule fois lorsque vous avez terminé vos commutateurs multiples. (plus: wp-includes / ms-blogs.php )
la source