Nota: esta es una respuesta incompleta que se ampliará de forma incremental
La única forma confiable de vaciar las reglas de reescritura en múltiples sitios, sin destruir potencialmente la estructura de enlace permanente del principal y / o cualquier otro contexto del blog (dependiendo de cómo y qué es lo que está cambiando hacia y desde) es vaciar las reglas de reescritura en un determinado contexto así:
global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();
Lo anterior garantiza que la estructura de enlace permanente correcta para el contexto dado se recupere y establezca antes de construir las reglas de reescritura y cometer los cambios en la base de datos.
Esto no se aplica a un sitio único donde el contexto no importa, porque solo hay un contexto.
En mi opinión,
flush_rewrite_rules() está viciado en la premisa de que asume el contexto correcto, pero no toma en cuenta nuestro uso de switch_to_blog , que cambia completamente el contexto y nos deja en un territorio peligroso si intentamos vaciar reglas, potencialmente.
Esto es el aspecto interno de flush_rewrite_rules() :
function flush_rewrite_rules( $hard = true ) {
global $wp_rewrite;
$wp_rewrite->flush_rules( $hard );
}
No puedo pensar en una razón por la que no debería verse así:
function flush_rewrite_rules( $hard = true ) {
global $wp_rewrite;
$wp_rewrite->init(); //hello....
$wp_rewrite->flush_rules( $hard );
}
... especialmente si consideras que el constructor de WP_Rewrite hace qué? Hace esto ...
public function __construct() {
$this->init();
}
Sin embargo, al tocar tu primer punto de preocupación para avanzar en esta línea,
Entonces, ¿cómo iría el plugin para limpiar de manera confiable las reglas de reescritura en multisitio :
- Cuando se crea un sitio nuevo, para el sitio?
Veamos a lo que llamará especialmente el núcleo de WordPress durante este proceso:
- primer
wpmu_create_blog()
- que luego llama a
install_blog() que a su vez llama a populate_options()
- entonces
populate_options() establece la estructura de enlace permanente predeterminada en la tabla de opciones
- después de que se haya ejecutado
install_blog() , se llama a wp_install_defaults()
- luego
wp_install_defaults() borra las reglas de reescritura para el sitio recién creado antes de volver finalmente al blog actual a través de restore_current_blog() .
Es importante destacar que wp_install_defaults() se vacía gobierna exactamente como lo he sugerido arriba:
$wp_rewrite->init();
$wp_rewrite->flush_rules();
... porque esa es la única manera de asegurarse de que permalink_structure y las reglas correctas se crean para el contexto actual.
También en el problema evidenciado en el problema de Github , la razón por la cual el usuario Experimentó el siguiente comportamiento:
Cuando se crea un sitio nuevo, rompe los enlaces permanentes de nivel posterior solo en el sitio de nivel superior, en la mayoría de las configuraciones de enlaces permanentes, pero no en todas:
Estos 2 formatos funcionan correctamente.
Predeterminado - Funciona como se esperaba
Día & Nombre - Funciona como se esperaba
... es porque si el blog principal tiene un Día & Nombre permalink structure /%year%/%monthnum%/%day%/%postname%/ , cuando se crea un sitio nuevo, también tiene un Día & Nombre de la estructura permalink /%year%/%monthnum%/%day%/%postname%/ de manera predeterminada, por lo que no se presenta ningún problema notable cuando el complemento de Yoast SEO vacía las reglas de reescritura en el gancho shutdown .