multisite – ¿Cómo eliminar de forma fiable las reglas de reescritura en varios sitios?

Pregunta:

Digamos que tiene un complemento que necesita eliminar las reglas de reescritura. Lo hace todo correctamente con el gancho de activación y agregando el rasante tarde, para que todo sea suave y compatible.

Y luego, un buen día, alguien intenta ejecutarlo en varios sitios.

En lugar de escenarios simples como:

  1. Se crea el sitio de WordPress
  2. El complemento está instalado y activado

Ahora tienes escenarios de pesadilla como:

  1. El complemento está instalado y la red está activada
  2. Se crea un nuevo sitio de WordPress (o cien) en varios sitios

En teoría, debería funcionar, ¿verdad? En la práctica, sale mal de formas espectaculares:

  • $wp_rewrite estado de $wp_rewrite puede ser del sitio incorrecto
  • switch_to_blog() tampoco rastrea el estado de reescritura
  • la parte "posterior" puede suceder en un blog diferente por completo
  • todos esos otros complementos, con los que se supone que debe jugar bien, pueden no estar habilitados constantemente en diferentes sitios

Por ejemplo, puede ver este problema de cómo intentar hacerlo bien destruye los enlaces permanentes en el sitio principal cada vez que se crea un nuevo sitio .

Entonces, ¿cómo funcionaría el complemento para eliminar de manera confiable las reglas de reescritura en varios sitios ?

  1. Cuando se crea un nuevo sitio, ¿para el sitio?
  2. Cuando el sitio existente se activa desde inactivo, ¿para el sitio?
  3. ¿Cuándo se activa el complemento de red, para cada sitio?
  4. ¿Cuándo se desactiva el complemento de red, para todos los sitios?
  5. ¿Posiblemente en otros escenarios, involucrando reescribir el contexto global cambiando?

Respuesta:

Nota: esta es una respuesta incompleta que se ampliará de forma incremental


La única forma confiable de eliminar las reglas de reescritura en varios sitios, sin destruir potencialmente la estructura de enlace permanente del contexto principal o de cualquier otro blog (dependiendo de cómo y a qué se cambia y desde) es eliminar las reglas de reescritura en un contexto dado como tal :

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 tiene fallas en la premisa de que asume el contexto correcto, pero no toma en cuenta nuestro uso de switch_to_blog por lo cual cambia completamente el contexto y nos deja en territorio peligroso si intentamos eliminar las reglas, potencialmente.

Así es como se ve el interior 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 cuando consideras que el constructor de WP_Rewrite hace ¿qué? Hace esto …

public function __construct() {
    $this->init();
}

Tocando su primer punto de preocupación para promover esta línea de pensamiento,

Entonces, ¿cómo funcionaría el complemento para eliminar de manera confiable las reglas de reescritura en varios sitios ?

  • Cuando se crea un nuevo sitio, ¿para el sitio?

Veamos lo que llamará notablemente 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()
  • luego populate_options() establece la estructura de enlace permanente predeterminada en la tabla de opciones
  • después install_blog() tiene RAN, wp_install_defaults() luego se la 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 sugerí anteriormente:

$wp_rewrite->init();
$wp_rewrite->flush_rules();

… porque esa es la única forma de estar seguro de que se crean la estructura de permalink_structure y las reglas correctas para el contexto actual.

También en el problema evidenciado dentro del tema Github , la razón por la cual el usuario experimentó el siguiente comportamiento:

Cuando se crea un nuevo sitio, se rompen los enlaces permanentes de nivel de publicación 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 y nombre: funciona como se esperaba

… es porque si el blog principal tiene una estructura de /%year%/%monthnum%/%day%/%postname%/ permanente de día y nombre /%year%/%monthnum%/%day%/%postname%/ , cuando se crea un nuevo sitio, también tiene una estructura de enlace permanente de día y nombre /%year%/%monthnum%/%day%/%postname%/ por defecto, por lo que no se presenta ningún problema notable cuando el complemento Yoast SEO elimina las reglas de reescritura en el gancho de shutdown .

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım