Примітка: це неповна відповідь, яка буде розгортатися поступово
Єдиний надійний спосіб очистити правила перезапису в багатосайтовий сайт, не потенційно руйнуючи структуру постійної посилання основного та будь-якого іншого контексту блогу (залежно від того, як і на що ви переходите і з якого), - це очистити правила перезапису в заданому контексті, наприклад :
global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();
Вищезазначене гарантує, що правильна структура постійної посилання для даного контексту буде отримана та встановлена перед побудовою правил перезапису та внесенням змін до бази даних.
Це не стосується одного сайту, де контекст не має значення, оскільки є лише один контекст.
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 формати працюють правильно.
За замовчуванням - працює як очікувалося
День та назва - працює як очікувалося
... це тому, що якщо основний блог має структуру постійної посилання "День та Ім'я" /%year%/%monthnum%/%day%/%postname%/, коли створюється новий сайт, він також має /%year%/%monthnum%/%day%/%postname%/за замовчуванням структуру постійної посилання "День та Ім'я", тому не помітна проблема, коли плагін Yoast SEO перезаписує правила на shutdownгачок.