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

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.