Como liberar regras de reescrita em multisite de forma confiável?

19

Digamos que você tenha um plug-in que precise liberar as regras de reescrita. Você faz tudo corretamente com o gancho de ativação e adiciona flush tarde, então tudo é suave e compatível.

E então, um belo dia, alguém tenta executá-lo em vários sites.

Em vez de cenários simples como:

  1. o site do WordPress é criado
  2. O plug-in está instalado e ativado

Você agora tem cenários de pesadelo como:

  1. O plug-in está instalado e ativado pela rede
  2. Novo site do WordPress (ou cem) em multisite é criado

Em teoria, deveria funcionar, certo? Na prática, dá errado de maneiras espetaculares:

  • $wp_rewrite state pode estar no site errado
  • switch_to_blog() não rastreia o estado de reescrita
  • a parte "posterior" pode acontecer em um blog totalmente diferente
  • todos esses outros plugins, com os quais você deve jogar bem, podem não estar habilitados de forma consistente em sites diferentes

Por exemplo, você pode ver esse problema como tentar fazer isso corretamente afunila os permalinks no site principal toda vez que um novo site é criado .

Então, como o plug-in processa de forma confiável as regras de regravação em multisite :

  1. Quando um novo site é criado, para o site?
  2. Quando um site existente é ativado de inativo, para o site?
  3. Quando o plug-in é ativado pela rede, para todos os sites?
  4. Quando o plugin é desativado em rede, para todos os sites?
  5. Possivelmente em outros cenários, envolvendo o contexto global de reescrita, sendo alterado?
por Rarst 08.05.2015 / 17:23

1 resposta

11

Nota: esta é uma resposta incompleta que será expandida gradualmente

A única forma confiável de liberar as regras de reescrita em vários sites, sem potencialmente destruir a estrutura do permalink do contexto primário e / ou de qualquer outro blog (dependendo de como e do que você está alternando) é liberar regras de reescrita em um dado contexto assim:

global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();

O acima assegura que a estrutura correta do permalink para o contexto dado seja recuperada e configurada antes de construir as regras de reescrita e confirmar as alterações no banco de dados.

Isso não se aplica a um único site em que o contexto não importa, porque existe apenas um contexto.

flush_rewrite_rules() na minha opinião é falho na premissa de que ele assume o contexto correto, mas não leva em conta o uso de switch_to_blog para o qual altera completamente o contexto e nos deixa em território perigoso se tentarmos liberar regras, potencialmente.

É assim que os componentes internos do flush_rewrite_rules() se parecem:

function flush_rewrite_rules( $hard = true ) {
    global $wp_rewrite;
    $wp_rewrite->flush_rules( $hard );
}

Não consigo pensar em um motivo pelo qual não deva ter esta aparência:

function flush_rewrite_rules( $hard = true ) {
    global $wp_rewrite;
    $wp_rewrite->init(); //hello....
    $wp_rewrite->flush_rules( $hard );
}

... especialmente quando você considera que o construtor de WP_Rewrite faz o quê? Isso faz isso ...

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

Tocando em seu primeiro ponto de preocupação para aprofundar essa linha,

  

Então, como o plugin funciona para liberar regras de reescrita em multisite :

     
  • Quando um novo site é criado, para o site?
  •   

Vamos ver o que o núcleo do WordPress chamaria notavelmente durante esse processo:

  • primeiro wpmu_create_blog()
  • que chama install_blog() , que por sua vez chama populate_options()
  • , em seguida, populate_options() define a estrutura de permalink padrão na tabela de opções
  • após a execução de install_blog() , wp_install_defaults() é chamado
  • , em seguida, wp_install_defaults() libera as regras de reconfiguração do site recém-criado antes de finalmente voltar para o blog atual por meio de restore_current_blog() .

É importante notar que wp_install_defaults() libera regras exatamente como sugeri acima:

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

... porque essa é a única maneira de garantir que as permalink_structure e as regras corretas sejam criadas para o contexto atual.

Também no problema evidenciado na questão do Github , a razão pela qual o usuário experimentou o seguinte comportamento:

  

Quando um novo site é criado, ele quebra os permalinks de nível de postagem apenas no site de nível superior - na maioria das configurações de permalink, mas não em todas:

     

Esses dois formatos funcionam corretamente.

     

Padrão - Funciona como esperado

     

Dia e amp; Nome - Funciona como esperado

... porque se o blog principal tiver um dia & Nome permalink structure /%year%/%monthnum%/%day%/%postname%/ , quando um novo site é criado, ele também tem um Day & Nome permalink estrutura /%year%/%monthnum%/%day%/%postname%/ por padrão, razão pela qual nenhum problema notável se apresenta quando o plugin Yoast SEO libera reescrever as regras no shutdown hook.

    
por userabuser 11.05.2015 / 15:42