Devemos confiar nos pós-globais?

@toscho deixou um comentário nessa resposta que me fez pensar novamente. Quanta confiança devemos ter no escopo global, especialmente em relação aos pós-globais $post?

E daí? A variável global pode ser substituída por todos antes de sua verificação ser executada. Esse é o ponto das variáveis ​​globais: acesso global.

$postpor exemplo, é certamente um dos globais que é modificado principalmente no próprio tema ou por plugins. No entanto, também é o global mais comumente usado em outros aplicativos em um determinado modelo, por exemplo, para configurar postagens relacionadas.

Ao responder (e comentar) várias postagens com problemas específicos causados ​​pelo uso de consultas personalizadas , destaca-se que a maioria dos problemas é causada devido ao fato de as consultas personalizadas não serem redefinidas (consultas personalizadas alteram os globais definidos pela consulta principal).

A partir disso, é evidente que $postnão é confiável. Qualquer pedaço de código mal escrito que faça uso de uma consulta personalizada pode alterar o $postglobal, que por sua vez irá quebrar algo (como postagens relacionadas).

Apenas um punhado de desenvolvedores do WordPress tem conhecimento suficiente do funcionamento interno do núcleo e sabe o que evitar e o que não. A maior população de usuários não tem idéia de como o núcleo do WordPress opera.

Eles simplesmente fazem o download de um tema e instalam plug-ins para fazer o que é necessário ou até mesmo copiar o código de um tutorial. Digamos que instalem um plug-in mal escrito que quebra as postagens relacionadas em uma única postagem, como eles saberão o que causou isso? Eles serão capazes de resolver isso sozinhos ou serão a centésima pessoa escrevendo um email para o autor do tema sobre esse problema ou postando uma pergunta neste site?

Minha pergunta: como você pode se proteger contra esses problemas causados ​​por outro código importado quando um global $posté tão confiável? Deveríamos estar usando um tipo global $post? Quais são as alternativas?

Apenas para compartilhar minha mente aqui antes de concluir: eu pensei (e vi em alguns temas e plugins também) usando wp_reset_postdata()ou wp_reset_query()antes de usá-lo $post, para garantir que o global esteja sendo redefinido para a consulta principal $post. Mas por que eu deveria inflar meu código no meu tema porque outra pessoa não codificou corretamente seu plug-in? E se alguém redefiniu corretamente sua consulta personalizada, essa operação é executada uma segunda vez desnecessária, o que não é bom.

O segundo método em que pensei é usar o método $wp_querye, em seguida, usar seus métodos, algo assim $wp_query->post.

Quaisquer pensamentos sobre isso serão apreciados.

Há uma triste verdade: você nunca pode ter certeza de que algum código não vai quebrar o seu código, e não há nada que você pode fazer para evitar isso. Especialmente no WordPress, onde tudo é global.

Dito isto, sim, global $posté um dos var global mais utilizado, portanto, usando especial cuidado para ele pode ser uma boa idéia.

No meu código, raramente acesso diretamente global $post.

Quando no concurso singular , eu uso get_queried_object()e costumo verificar se $posté uma WP_Postinstância válida :

$post = get_queried_object();

if ( ! $post instanceof \WP_Post ) {
   die( 'What the f**k?!' );
}

Faço essa verificação também nos casos raros que acesso $postdiretamente.

Considere que get_queried_object()retorna um valor inesperado se algum código usar query_posts, mas, ei, se alguém usa código em que se baseia query_posts, ele merece se seu site quebrar :)

Além disso, se espero algumas condições, verifico-as, por exemplo, tipos específicos de postagens ou status específico.

Se eu precisar de mais verificações e em mais locais, crio uma função para executá-las:

function get_global_post() {
    global $post;
    if ( 
        ! $post instanceof \WP_Post
        || ! $post->post_type === 'mycpt'
        || ! in_array( $post->post_status, array( 'publish', 'private' ), true ) 
    ) {
        return false;
    }
    return $post;
}

$mypost = get_global_post();

if ( ! $mypost ) {
      die( 'What the f**k?!' );
}

Quando dentro de uma consulta personalizada, durante o loop, a chamada the_post()redefine o objeto de postagem, portanto tudo deve estar bem. Então, é minha responsabilidade ligar wp_reset_postdata()após uma consulta personalizada, e eu faço isso, é claro :)