1. Defina a consulta antes da execução do WP_Query
Isso parece ser o mais importante a ser lembrado ao tentar manter as consultas ao banco de dados no mínimo, já que a única oportunidade de alterar a consulta é, é claro, antes de ser executada no banco de dados SQL.
Consultas normais
Para uma consulta normal, o WordPress usa a wp()função, que por sua vez chama $wp->main( $query_vars ). As "variáveis is_" das tags condicionais são definidas antes de passá-las para WP_Query->get_posts(), o que a converte em uma consulta ao banco de dados MySQL e finalmente as armazena no objeto $ wp_query. É possível filtrar a consulta antes que ela seja realmente executada no banco de dados SQL .
A pre_get_postsação se conecta a esse processo, permitindo que você altere a consulta antes de ser passada para WP_Query->get_posts().
Por exemplo, se você deseja filtrar a consulta por postagens na categoria "em destaque", use add_action( 'pre_get_posts', 'your_function_name' );e inclua a in_categorytag condicional your_function_name.
function your_function_name( $query ) {
if ( $query->in_category( 'featured' ) && $query->is_main_query() ) {
// Replace 123 with the category ID of the featured category.
$query->set( 'cat', '123' );
}
}
add_action( 'pre_get_posts', 'your_function_name' );
Veja API Plugin / Referência de Ação / pre get posts «WordPress Codex
Solicitações
de página Quanto aos modelos de página, como a página de arquivo da categoria "em destaque", as tags condicionais não funcionarão no pre_get_postsfiltro. Por exemplo, você não pode usar is_categorya verificação da página de arquivamento porque o WP_Query não foi executado.
Em vez disso, você teria que alterar a consulta principal para solicitações de página com uma new WP_Queryque seria algo parecido $query = new WP_Query( 'cat=123' );. Isso executa a consulta com o argumento apropriado definido desde o início.
Consulte Referência da classe / consulta WP «WordPress Codex
2. Salvando no banco de dados
Você pode usar o filtro, wp_insert_post_datagarantindo que apenas os dados $ relevantes ao seu tipo de postagem personalizado sejam retornados wp_insert_post. Certifique-se de incluir uma declaração condicional para verificar seu tipo de postagem personalizado.
API de plug-in / referência de filtro / wp insert data post «WordPress Codex
Esse gancho é chamado pela wp_insert_postfunção, chamada wp_update_post quando você atualiza seu tipo de postagem personalizado, geralmente salvando um rascunho ou publicando a postagem.
Você terá que compará-lo você mesmo, já que eu não posso falar pessoalmente sobre o significado da otimização de reduzir os dados atualizados no banco de dados.
3. Os tipos de postagem personalizados afetam o desempenho?
Na minha experiência, os tipos de postagem personalizados são uma ferramenta poderosa para gerenciar conteúdo. Não conheço outra maneira de gerenciar postagens de todas as maneiras que isso permitir, de maneira a usar menos recursos. Eu pessoalmente focaria em encontrar maneiras de reduzir o número de consultas feitas sempre que possível.
Costumava haver um problema de desempenho relacionado à estrutura do link permanente, causando um acerto quando começava com texto em vez de um número. 3 Isso foi particularmente problemático para sites que hospedam um grande número de páginas, mas foi resolvido desde a versão 3.3 do WordPress.
Estou apenas trazendo permalinks aqui porque a lesma geralmente é a primeira parte da estrutura do permalink que pode ou não ter afetado o desempenho antes da versão 3.3. Além disso, não conheço nenhum problema de desempenho resultante do uso de tipos de postagem personalizados.
Outras opções de desempenho
Transientes
Não é um substituto para manter as consultas no mínimo no seu código, mas você pode usar set_transient para armazenar as consultas por algum tempo, para que novas consultas não sejam necessárias. Aqui está o exemplo usado na postagem de Dave Clements . Além disso, observe que ele recomenda adicionar uma save_postação para excluir o transitório sempre que um determinado tipo de postagem for atualizado.
<?php // IN THE SPOTLIGHT QUERY
if( false === ( $its_query = get_transient( 'its_query' ) ) ) {
$pttimestamp = time() + get_option('gmt_offset') * 60*60;
$its_query = new WP_Query( array(
'post_type' => 'spotlight',
'posts_per_page' => 1,
'post__not_in' => $do_not_duplicate,
'meta_query' => array(
array(
'key' => '_hpc_spotlight_end_time',
'value' => $pttimestamp,
'compare' => '>'
)
)
) );
set_transient( 'its_query', $its_query, 60*60*4 );
}
if( have_posts() ) { // HIDE SECTION IF NO CURRENT ITS FEATURE ?>
// LOOP GOES HERE: NOT IMPORTANT TO EXAMPLE
<?php } ?>
Mais otimização de consultas
Thomas Griffin tem algumas boas dicas em seu tutorial Optimize WordPress Queries . Aqui está uma breve lista de sugestões:
Defina 'cache_results' => falseem consultas pontuais se o servidor não estiver usando o cache persistente, como o Memcached. As consultas pontuais são descritas como "consultas usadas para mostrar pequenas quantidades de dados. Pode ser que você queira apenas exibir títulos de post vinculados relacionados à postagem atual ou exibir uma lista suspensa de postagens para selecionar para uma configuração de opção específica ".
O exemplo dele: $query = get_posts( array( 'posts_per_page' => 1,
'cache_results' => false ) );
Defina 'no_found_rows' => trueonde a paginação não é necessária. Isso "ignorará o MySQL contando os resultados para ver se precisamos de paginação ou não".
O exemplo dele: $query = new WP_Query( array( 'posts_per_page' => 1,
'no_found_rows' => true ) );
Consulta para IDs pós somente se isso é tudo que você precisa 'fields' => 'ids'
no get_posts. Isso deve reduzir significativamente a quantidade de dados retornados, o que é bastante por postagem, se você olhar para
Descrição do banco de dados «WordPress Codex
O exemplo dele: $query = get_posts( array( 'posts_per_page' => 1,
'fields' => 'ids' ) );
Além dessa última dica, o mesmo raciocínio pode ser aplicado quando você precisar apenas de um ou alguns campos de postagem usando get_post_field .
É essencial ter um sólido entendimento de como a consulta funciona. Quanto mais específico você for com suas consultas, menos trabalho exigirá do banco de dados SQL. Isso significa que há um grande número de possibilidades para gerenciar consultas ao banco de dados. Tenha cuidado com as consultas personalizadas até onde elas são executadas (é uma página de administrador?), Use a higienização adequada nas consultas diretas e tente usar as funções nativas do WordPress, onde isso permite obter o mesmo desempenho.