Nota: esta es una respuesta incompleta que se ampliará gradualmente
La única forma confiable de eliminar las reglas de reescritura en varios sitios, sin destruir potencialmente la estructura de enlace permanente del contexto primario y / o de cualquier otro contexto del blog (dependiendo de cómo y de qué se cambie), es eliminar las reglas de reescritura en un contexto dado. :
global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();
Lo anterior garantiza que se recupere y establezca la estructura de enlace permanente correcta para el contexto dado antes de construir las reglas de reescritura y confirmar los cambios en la base de datos.
Esto no se aplica a un solo sitio donde el contexto no importa, porque solo hay un contexto.
flush_rewrite_rules()En mi opinión, es erróneo en la premisa de que asume el contexto correcto, pero no tiene en cuenta nuestro uso de lo switch_to_blogque cambia completamente el contexto y nos deja en un territorio peligroso si intentamos eliminar las reglas, potencialmente.
Así es flush_rewrite_rules()como se ve el interior de :
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 cuando consideras que el constructor de WP_Rewritehace qué? Hace esto ...
public function __construct() {
$this->init();
}
Sin embargo, tocando tu primer punto de preocupación para avanzar en esta línea,
Entonces, ¿cómo funcionaría el plugin para enjuagar de manera confiable las reglas de reescritura en múltiples sitios :
- Cuando se crea un nuevo sitio, ¿para el sitio?
Veamos qué llamará el núcleo de WordPress durante este proceso:
- primero
wpmu_create_blog()
- que luego llama
install_blog()que a su vez llamapopulate_options()
- luego
populate_options()establece la estructura de enlace permanente predeterminada en la tabla de opciones
- después de
install_blog()haber corrido, wp_install_defaults()luego se llama
- luego
wp_install_defaults()elimina las reglas de reescritura para el sitio recién creado antes de finalmente volver al blog actual a través de restore_current_blog().
Es importante tener en cuenta que wp_install_defaults()elimina las reglas exactamente como he sugerido anteriormente:
$wp_rewrite->init();
$wp_rewrite->flush_rules();
... porque esa es la única manera de asegurarse de que las permalink_structurereglas y reglas correctas se construyan para el contexto actual.
También en el problema evidenciado dentro del problema de Github , la razón por la cual el usuario experimentó el siguiente comportamiento:
Cuando se crea un nuevo sitio, rompe los enlaces permanentes de nivel de publicación solo en el sitio de nivel superior, en la mayoría de las configuraciones de enlace permanente, pero no en todas:
Estos 2 formatos funcionan correctamente.
Predeterminado: funciona como se esperaba
Día y nombre: funciona como se esperaba
... es porque si el blog principal tiene una estructura de enlace permanente Day & Name /%year%/%monthnum%/%day%/%postname%/, cuando se crea un nuevo sitio, también tiene una estructura de enlace permanente Day & Name /%year%/%monthnum%/%day%/%postname%/por defecto, razón por la cual no se presenta ningún problema notable cuando el plugin Yoast SEO va a reescribir reglas en el shutdownanzuelo.