Hinweis: Dies ist eine unvollständige Antwort, die schrittweise erweitert wird
Die einzig verlässliche Möglichkeit, Überschreibungsregeln in Multisite-Umgebungen zu löschen, ohne die Permalink-Struktur des primären und / oder eines anderen Blog-Kontexts zu zerstören (abhängig davon, wie und wovon Sie wechseln), besteht darin, Überschreibungsregeln in einem bestimmten Kontext wie diesem zu löschen :
global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();
Das Obige stellt sicher, dass die richtige Permalink-Struktur für den angegebenen Kontext abgerufen und festgelegt wird, bevor die Umschreiberegeln erstellt und die Änderungen in die Datenbank übernommen werden.
Dies gilt nicht für einzelne Sites, bei denen der Kontext keine Rolle spielt, da nur ein Kontext vorhanden ist.
flush_rewrite_rules()Meiner Meinung nach ist die Prämisse fehlerhaft, dass sie den korrekten Kontext annimmt, aber nicht berücksichtigt, switch_to_blogwofür unsere Verwendung den Kontext vollständig ändert und uns in gefährlichem Gebiet zurücklässt, wenn wir versuchen, möglicherweise Regeln zu löschen.
So sehen die Interna von flush_rewrite_rules()aus:
function flush_rewrite_rules( $hard = true ) {
global $wp_rewrite;
$wp_rewrite->flush_rules( $hard );
}
Ich kann mir keinen Grund vorstellen, warum es nicht so aussehen sollte:
function flush_rewrite_rules( $hard = true ) {
global $wp_rewrite;
$wp_rewrite->init(); //hello....
$wp_rewrite->flush_rules( $hard );
}
... vor allem wenn man bedenkt, dass der Konstruktor von WP_Rewritewas macht? Es macht das ...
public function __construct() {
$this->init();
}
Berühren Sie Ihren ersten Punkt der Besorgnis, um diese Linie zu fördern.
Wie würden Plugin um zuverlässig Spülung Rewrite - Regeln in gehen Multi - Site :
- Wann wird eine neue Site für die Site erstellt?
Schauen wir uns an, was der WordPress-Kern während dieses Prozesses besonders aufruft:
- zuerst
wpmu_create_blog()
- was dann ruft
install_blog()was wiederum ruftpopulate_options()
populate_options()Setzt dann die Standard-Permalink-Struktur in der Optionstabelle- nachdem
install_blog()lief, wird wp_install_defaults()dann angerufen
- Anschließend werden
wp_install_defaults()die Umschreiberegeln für die neu erstellte Site gelöscht, bevor schließlich über zum aktuellen Blog zurückgeschaltet wird restore_current_blog().
Wichtig zu beachten ist, dass wp_install_defaults()Flush-Regeln genau so sind, wie ich oben vorgeschlagen habe:
$wp_rewrite->init();
$wp_rewrite->flush_rules();
... weil nur so sichergestellt werden kann, dass die richtigen permalink_structureRegeln für den aktuellen Kontext erstellt werden.
Auch bei dem im Github-Problem aufgezeigten Problem trat der Grund, warum der Benutzer das folgende Verhalten auf:
Wenn eine neue Site erstellt wird, werden die Post-Level-Permalinks nur auf der Top-Level-Site unterbrochen - in den meisten Permalink-Konfigurationen, jedoch nicht in allen:
Diese beiden Formate funktionieren korrekt.
Standard - Funktioniert wie erwartet
Tag & Name - Funktioniert wie erwartet
... liegt daran, dass das primäre Blog bei der Erstellung /%year%/%monthnum%/%day%/%postname%/einer neuen Site /%year%/%monthnum%/%day%/%postname%/standardmäßig über eine Day & Name-Permalink-Struktur verfügt, weshalb sich kein nennenswertes Problem ergibt, wenn das Yoast-SEO-Plugin das Neuschreiben leert Regeln am shutdownHaken.