Devemos confiar nos pós globals?

20

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

  

Então o que? A variável global pode ser sobregravada de todos antes que o cheque seja executado. Esse é o ponto das variáveis globais: acesso global.

$post , por exemplo, é certamente um dos globais que é modificado principalmente dentro do próprio tema ou por plugins. No entanto, é também o global mais comumente usado em outros aplicativos dentro de 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 , realmente se destaca que a maioria dos problemas é causada porque as consultas personalizadas não são redefinidas (consultas personalizadas alteram os globals definidos pela consulta principal).

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

Apenas um punhado de desenvolvedores do WordPress é realmente instruído o suficiente no 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 baixam um tema e instalam plugins para fazer o que é necessário ou até copiar o código de um tutorial. Digamos que eles instalem um plugin mal escrito que quebra seus posts relacionados em sua postagem única, 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 e-mail para o autor do tema sobre esse problema, ou publicando uma pergunta neste site?

Minha pergunta: Como você pode proteger contra esses problemas causados por outro código importado quando um global como $post é tão pouco confiável? Devemos estar usando um global como $post em tudo? Quais são as alternativas?

Só para compartilhar minha opinião 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 usar $post , para ter certeza de que o global está sendo redefinido para $post da consulta principal. Mas por que eu deveria inflar meu código no meu tema porque alguém não codificou adequadamente seu plugin? E se alguém redefinir corretamente sua consulta personalizada, essa operação será executada uma segunda vez desnecessária, o que não é bom.

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

Qualquer opinião sobre isso será apreciada.

    
por Pieter Goosen 07.11.2014 / 07:32
fonte

1 resposta

16

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

Dito isto, sim, global $post é um dos vars globais mais usados, então usar care especial para pode ser uma boa ideia.

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

No concurso singular , uso get_queried_object() e geralmente verifico se $post é uma instância válida de WP_Post :

$post = get_queried_object();

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

Faço essa verificação também nos casos raros em que acesse $post diretamente.

Considere que get_queried_object() retorna um valor inesperado se algum código usa query_posts , mas, ei, se alguém usa código que depende de query_posts , eles merecem isso se o site deles quebrar:)

Além disso, se eu esperar algumas condições, eu as verifico, por exemplo tipos de postagens específicas ou um status específico.

Se precisar de mais verificações e, em mais lugares, criar uma função para realizá-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, chamar the_post() redefine o objeto post, portanto, deve ficar bem. Então, é minha responsabilidade chamar wp_reset_postdata() após uma consulta personalizada, e eu faço isso, claro:)

    
por gmazzap 07.11.2014 / 13:37
fonte