注：これは不完全な回答であり、段階的に拡張されます
プライマリおよび/または他のブログコンテキストのパーマリンク構造を破壊することなく、マルチサイトで書き換えルールをフラッシュする唯一の信頼できる方法（切り替え方法と切り替え方法によって異なります）は、特定のコンテキストで書き換えルールをフラッシュすることです：
global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();
上記により、書き換えルールを構築し、データベースに変更をコミットする前に、特定のコンテキストの正しいパーマリンク構造が取得および設定されます。
コンテキストは1つしかないため、これはコンテキストが重要でない単一サイトには適用されません。
flush_rewrite_rules()私の意見では、正しいコンテキストを想定しているという前提で欠陥がありますが、switch_to_blogルールをフラッシュしようとすると、コンテキストを完全に変更し、危険な領域に私たちを残すことを考慮していません。
これは内部のflush_rewrite_rules()外観です：
function flush_rewrite_rules( $hard = true ) {
global $wp_rewrite;
$wp_rewrite->flush_rules( $hard );
}
このように見えるべきではない理由を考えることはできません。
function flush_rewrite_rules( $hard = true ) {
global $wp_rewrite;
$wp_rewrite->init(); //hello....
$wp_rewrite->flush_rules( $hard );
}
...特にあなたがのコンストラクタWP_Rewriteが何をするかを考えるとき？これは...
public function __construct() {
$this->init();
}
最初の懸念事項に触れてこの行をさらに進めて、
したがって、プラグインは、マルチサイトで書き換えルールを確実にフラッシュする方法について説明します。
このプロセスでWordPressコアが特に呼び出すものを見てみましょう。
- 最初
wpmu_create_blog()
- それは次に呼び出し
install_blog()、順番に呼び出しますpopulate_options()
- 次に
populate_options()、オプション表にデフォルトのパーマリンク構造を設定します
- 実行した後
install_blog()、wp_install_defaults()呼び出されます
- その後
wp_install_defaults()、最終的にを介して現在のブログに戻る前に、新しく作成されたサイトの書き換えルールをフラッシュしrestore_current_blog()ます。
重要なのは、wp_install_defaults()上記で提案したとおりにルールをフラッシュすることです。
$wp_rewrite->init();
$wp_rewrite->flush_rules();
...これがpermalink_structure現在のコンテキストに合わせて正しいルールを構築するための唯一の方法だからです。
また、Githubの問題で明らかになった問題で、ユーザーが次の動作を経験した理由：
新しいサイトが作成されると、トップレベルのサイトでのみポストレベルのパーマリンクが破損します-ほとんどのパーマリンク構成ではすべてではありません：
これら2つの形式は正しく機能します。
デフォルト-期待どおりに動作します
曜日と名前-期待どおりに動作します
...プライマリブログにDay＆Nameパーマリンク構造/%year%/%monthnum%/%day%/%postname%/がある場合、新しいサイトが作成されると、/%year%/%monthnum%/%day%/%postname%/デフォルトのDay＆Nameパーマリンク構造にもなるため、Yoast SEOプラグインが書き換えをフラッシュするときに顕著な問題は発生しません。shutdownフックのルール。