Vamos simplificar
Se eu entendi bem o OP, seu problema é que os URLs contendo um til são correspondidos.
Todas as outras respostas se concentram no fato de que a higienização para a consulta retira alguns caracteres antes de executar a consulta, no entanto, um deve ser capaz de impedir que uma regra de reconfiguração não corresponda em algumas circunstâncias.
E é factível, não é muito fácil, mas factível.
Por que combina, em primeiro lugar?
A razão pela qual dois URLs como example.com/postname
e example.com/postname~
correspondem à mesma regra de reescrita é porque a regra de reescrever WP para postagens usa a tag de reescrita %postname%
que é substituído pelo regex ([^/]+)
quando regras de reescrita são criadas.
O problema é que regex ([^/]+)
também corresponde ao nome do post postname~
e, devido à sanitização, o nome consultado será postname
terminando em um resultado válido.
Isso significa que, se pudermos alterar a regex de ([^/]+)
para ([^~/]+)
tilde, a correspondência não será mais compatível, por isso, impediremos que os URLs contendo o til no nome do post sejam correspondidos.
Como nenhuma regra vai corresponder, o URL será um 404, que deve ser o comportamento esperado, eu acho.
Evitar correspondência
add_rewrite_tag
é uma função que, apesar de seu nome, pode ser usada para atualizar uma tag de reescrita existente como %postname%
.
Então, se usarmos o código:
add_action('init', function() {
add_rewrite_tag( '%postname%', '([^~/]+)', 'name=' );
});
atingiremos nossa meta e example.com/postname~
não corresponderá à regra de example.com/postname
.
Então, sim, as três linhas acima são o único código que você precisará .
No entanto, antes de funcionar, você precisará liberar as regras de reescrita visitando a página de configurações de permalink no back-end.
Observe que regex ([^~/]+)
impede que um til esteja em qualquer lugar no nome do post, não apenas como caractere final, mas como os nomes dos posts não podem conter til por causa da limpeza, isso não deve ser um problema.