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 chamapopulate_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 derestore_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.