Nota: esta é uma resposta incompleta que será expandida gradualmente
A única maneira confiável de liberar regras de reescrita em vários sites, sem destruir potencialmente a estrutura de links permanentes do contexto primário e / ou qualquer outro contexto de blog (dependendo de como e para o que você está mudando) é liberar regras de reescrita em um determinado contexto como esse :
global $wp_rewrite;
$wp_rewrite->init(); //important...
$wp_rewrite->flush_rules();
O procedimento acima garante que a estrutura correta do link permanente para o contexto fornecido seja recuperada e definida antes da construção das regras de reescrita e do comprometimento das alterações no banco de dados.
Isso não se aplica ao site único em que o contexto não importa, porque existe apenas um contexto.
flush_rewrite_rules()na minha opinião, é defeituoso na premissa de que ele assume o contexto correto, mas não leva em conta nosso uso switch_to_blogpara o qual muda completamente o contexto e nos deixa em território perigoso se tentarmos liberar regras, potencialmente.
É assim que são os elementos internos flush_rewrite_rules():
function flush_rewrite_rules( $hard = true ) {
global $wp_rewrite;
$wp_rewrite->flush_rules( $hard );
}
Não consigo pensar em uma razão pela qual não deveria ser assim:
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_Rewritefaz o quê? Faz isso ...
public function __construct() {
$this->init();
}
Tocando em seu primeiro ponto de preocupação para aprofundar essa linha,
Então, como o plugin executaria a descarga confiável de regras de reescrita em vários sites :
- Quando um novo site é criado, para o site?
Vejamos o que o núcleo do WordPress chamará notavelmente durante esse processo:
- primeiro
wpmu_create_blog()
- que então chama
install_blog()que por sua vez chamapopulate_options()
- depois
populate_options()define a estrutura permalink padrão na tabela de opções
- depois da
install_blog()execução, wp_install_defaults()é chamado
- depois,
wp_install_defaults()libera as regras de reescrita para o site recém-criado antes de finalmente voltar para o blog atual via restore_current_blog().
É importante notar que as wp_install_defaults()regras de descarga são exatamente como sugeri acima:
$wp_rewrite->init();
$wp_rewrite->flush_rules();
... porque essa é a única maneira de garantir que as permalink_structureregras e corretas sejam criadas para o contexto atual.
Também no problema evidenciado no problema do Github , o motivo pelo qual o usuário experimentou o seguinte comportamento:
Quando um novo site é criado, ele quebra os links permanentes de nível de postagem apenas no site de nível superior - na maioria das configurações de link permanente, mas não em todos:
Esses 2 formatos funcionam corretamente.
Padrão - funciona como esperado
Dia e nome - funciona conforme o esperado
... é porque, se o blog principal tiver uma estrutura de link permanente Day & Name /%year%/%monthnum%/%day%/%postname%/, quando um novo site for criado, ele também /%year%/%monthnum%/%day%/%postname%/terá uma estrutura de link permanente Day & Name por padrão, e é por isso que nenhum problema notável se apresentará quando o plugin Yoast SEO liberar a reescrita regras no shutdowngancho.