Comment effacer de manière fiable les règles de réécriture sur un site multisite?

19

Disons que vous avez un plugin qui doit effacer les règles de réécriture. Tout se fait correctement avec le crochet d’activation et l’ajout de la couleur plus tard, pour que tout soit lisse et compatible.

Et puis un beau jour, quelqu'un essaie de l'exécuter sur plusieurs sites.

Au lieu de scénarios simples tels que:

  1. le site WordPress est créé
  2. Le plugin est installé et activé

Vous avez maintenant des scénarios de cauchemar tels que:

  1. Le plugin est installé et activé par le réseau
  2. Un nouveau site WordPress (ou une centaine) multisite est créé

En théorie, ça devrait marcher, non? En pratique, cela se passe mal de manière spectaculaire:

  • $wp_rewrite state peut provenir du mauvais site
  • switch_to_blog() ne suit pas non plus l'état de réécriture
  • la partie "ultérieure" pourrait se produire entièrement dans un blog différent
  • tous ces autres plug-ins, avec lesquels vous êtes censé bien jouer, risquent de ne pas être activés de manière cohérente sur différents sites

Par exemple, vous pouvez comprendre ce problème: comment essayer de le faire correctement efface les liens permanents sur le site principal à chaque fois qu'un nouveau site s'affiche est créé .

Alors, comment le plug-in fonctionnerait-il de manière fiable en effaçant les règles de réécriture dans un site multisite :

  1. Quand un nouveau site est créé, pour le site?
  2. Lorsque le site existant est activé depuis inactif, pour le site?
  3. Quand le plugin est activé sur le réseau, pour chaque site?
  4. Quand le plugin est désactivé sur le réseau, pour chaque site?
  5. Peut-être dans d'autres scénarios, impliquant la modification du contexte global de réécriture?
posée Rarst 08.05.2015 - 17:23

1 réponse

11

Remarque: il s'agit d'une réponse incomplète qui sera développée par incréments

.

Le seul moyen fiable de supprimer les règles de réécriture dans un site multisite, sans détruire potentiellement la structure de liens permanents du contexte principal du blog ou de tout autre contexte de blog (en fonction du mode et des critères de basculement), consiste à supprimer les règles de réécriture dans un contexte donné. contexte comme celui-ci:

global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();

Ce qui précède garantit que la structure de permalien correcte pour le contexte donné est récupérée et définie avant la construction des règles de réécriture et la validation des modifications dans la base de données.

Ceci ne s'applique pas aux sites uniques où le contexte n'a pas d'importance, car il n'y a qu'un seul contexte.

flush_rewrite_rules() à mon avis est erroné dans le principe qu'il suppose le bon contexte, mais ne prend pas en compte notre utilisation de switch_to_blog pour laquelle le contexte change complètement et nous laisse dans un territoire dangereux si nous essayons de vider règles, potentiellement.

Voici à quoi ressemble le contenu interne de flush_rewrite_rules() :

function flush_rewrite_rules( $hard = true ) {
    global $wp_rewrite;
    $wp_rewrite->flush_rules( $hard );
}

Je ne vois pas pourquoi il ne devrait pas ressembler à ceci:

function flush_rewrite_rules( $hard = true ) {
    global $wp_rewrite;
    $wp_rewrite->init(); //hello....
    $wp_rewrite->flush_rules( $hard );
}

... surtout quand on considère que le constructeur de WP_Rewrite fait quoi? Ça fait ça ...

public function __construct() {
    $this->init();
}

En ce qui concerne votre premier point de préoccupation pour approfondir cette ligne,

  

Alors, comment le plug-in supprimerait-il de manière fiable les règles de réécriture dans multisite :

     
  • Quand un nouveau site est créé, pour le site?
  •   

Regardons ce que le noyau WordPress appellera notamment durant ce processus:

  • premier wpmu_create_blog()
  • qui appelle ensuite install_blog() qui appelle à son tour populate_options()
  • then populate_options() définit la structure de lien permanent par défaut dans la table d'options
  • après que install_blog() ait été exécuté, wp_install_defaults() est appelé
  • then wp_install_defaults() efface les règles de réécriture du site nouvellement créé avant de revenir au blog actuel via restore_current_blog() .

Il est important de noter que les wp_install_defaults() règles exactement comme je l'ai suggéré ci-dessus:

$wp_rewrite->init();
$wp_rewrite->flush_rules();

... car c'est le seul moyen de vérifier que les règles et les règles correctes sont définies pour le contexte actuel.

Également dans le problème mis en évidence dans le numéro de Github , la raison pour laquelle l'utilisateur a eu le comportement suivant:

  

Lorsqu'un nouveau site est créé, les permaliens de niveau publication ne sont dissociés que sur le site de niveau supérieur - dans la plupart des configurations de permalien mais pas toutes:

     

Ces 2 formats fonctionnent correctement.

     

Par défaut - Fonctionne comme prévu

     

Day & Nom - Fonctionne comme prévu

... est parce que si le blog principal a un jour & Nom permalien structure permalink_structure , quand un nouveau site est créé, il a aussi un jour & Nom permalien structure /%year%/%monthnum%/%day%/%postname%/ par défaut, c’est pourquoi aucun problème notable ne se pose lorsque le plug-in Yoast SEO supprime les règles de réécriture du crochet /%year%/%monthnum%/%day%/%postname%/ .

    
réponse donnée userabuser 11.05.2015 - 15:42

Lire d'autres questions sur les étiquettes