php - por - query_posts() debe evitarse?

query_posts id

Question

Estoy leyendo que query_posts() debe evitarse a favor de wp_query() y pre_get_posts() . No estoy seguro de jugar con el Loop y no entiendo completamente el códice.

¿El siguiente código usa query_posts() ? En caso afirmativo, y dado que query_posts() debe evitarse, ¿puede sugerir un método que no use query_posts() pero que todavía logre lo mismo?

Este código en functions.php se usa para ordenar las publicaciones por azar o por precio.

function my_custom_query($query){
if ( $query->is_home() && $query->is_main_query() ) {
$sort= $_GET[''sort''];
if($sort == "pricelow"){
$query->set( ''meta_key'', ''price'' );
$query->set( ''orderby'', ''meta_value_num'' );
$query->set( ''order'', ''ASC'' );
}
if($sort == "random"){
$query->set( ''orderby'', ''rand'' );
}
}
}
add_action( ''pre_get_posts'', ''my_custom_query'' );

.
El enlace A (aleatorio) y el enlace B (precio) se publican en mi menú utilizando este código. Por lo tanto, el visitante del sitio web puede ordenar las publicaciones simplemente haciendo clic en un enlace.

<a href="http://website.com/?sort=A">Random</a>
<a href="http://website.com/?sort=B">Price</a>

Answer 1

He hecho una explicación muy detallada sobre este mismo tema en WPSE, y en aras del valor y beneficio que podría tener para los usuarios de SO, aquí está la publicación completa copiada de esa pregunta en WPSE. Por interés, aquí hay un enlace a la publicación completa en WPSE: ¿ Alguna duda sobre cómo funciona la consulta principal y la consulta personalizada en este tema personalizado?

Su pregunta real es básicamente cuándo ejecutar una consulta personalizada y cuándo hacer uso de la consulta principal. Vamos a dividirlo en tres partes.

PARTE UNO

Cuándo ejecutar una consulta personalizada (esta no es una lista definitiva)

• Para crear controles deslizantes de contenido personalizado

• Para crear un área de contenido destacado en una página

• En las plantillas de page.php si necesita mostrar publicaciones

• Si necesita contenido personalizado en una portada estática

• Mostrar publicaciones relacionadas, populares o informativas

• Cualquier otro contenido secundario o suplementario fuera del alcance de la consulta principal

Cuándo hacer uso de la consulta principal.

Para mostrar el contenido primario en

• En su página de inicio y la página configurada como una página de blog en el backend

• Todas las páginas de archivo que incluyen plantillas como archive.php, category.php, author.php, taxonomy.php, tag.php y date.php

LA SEGUNDA PARTE

Para seleccionar todas las publicaciones destacadas, uso esta línea que crea un nuevo objeto WP_Query que define una consulta con la etiqueta específica presentada:

Entonces, por lo que tengo entendido, esta no es la consulta principal de WordPres, pero es una nueva consulta creada por mí. Por lo que tengo entendido, es mejor crear una nueva consulta (como se hizo) y no usar la consulta principal cuando quiero realizar este tipo de operaciones

Correcto. Esto queda fuera del alcance de la consulta principal. Este es contenido secundario o complementario que no se puede crear con la consulta principal. SIEMPRE DEBE usar WP_Query o get_posts para crear sus consultas personalizadas.

NUNCA USE query_posts para crear consultas personalizadas, o incluso cualquier otra consulta. Mi énfasis

Nota: Esta función no debe ser utilizada por complementos o temas. Como se explica más adelante, hay opciones mejores y más eficaces para alterar la consulta principal. query_posts () es una forma excesivamente simplista y problemática de modificar la consulta principal de una página al reemplazarla con una nueva instancia de la consulta. Es ineficiente (vuelve a ejecutar consultas SQL) y fallará directamente en algunas circunstancias (especialmente a menudo cuando se trata de paginación de publicaciones).

Hacia adelante

Ok, continúo mostrando todas las publicaciones que no tienen la etiqueta destacada, para hacer esto uso este fragmento de código que, por el contrario, modifica la consulta principal:

query_posts( array( ''tag__not_in'' => array ( $term->term_id )));

Así que creo que esto es bastante horrible. ¿Es verdad?

Todo eso está mal y su afirmación es lamentablemente cierta. Como se dijo antes, NUNCA use query_posts . Ejecuta una nueva consulta completa, que es mala para el rendimiento, y en la mayoría de los casos interrumpe la paginación, que es una parte integral de la consulta principal para que la paginación funcione correctamente.

Este es su contenido principal, por lo que debería usar la consulta principal con el bucle predeterminado, que debería tener este aspecto, y esto es todo lo que necesita

<?php
if (have_posts()) :
// Start the Loop.
while (have_posts()) : the_post();
get_template_part(''content'', get_post_format());
endwhile;
else :
// If no content, include the "No posts found" template.
get_template_part(''content'', ''none'');
endif;
?>

Puede deshacerse por completo de esta parte, eliminarla, grabarla y olvidarse de ella.

<?
// get the term using the slug and the tag taxonomy
$term = get_term_by( ''slug'', ''featured'', ''post_tag'' );
// pass the term_id to tag__not_in
query_posts( array( ''tag__not_in'' => array ( $term->term_id )));
?>

OK, una vez que hayas hecho eso, verás que las publicaciones de la etiqueta de función aparecen en tu página de inicio utilizando la consulta principal y el bucle predeterminado.

La forma correcta de eliminar esta etiqueta de la página de inicio es con pre_get_posts . Esta es la forma correcta de alterar la consulta principal y el enlace que siempre debe usar para realizar cambios en su ciclo de contenido principal.

Entonces, el código con pre_get_posts es correcto y esta es la función que debe usar. Solo una cosa, siempre verifique que no esté en una página de administración porque pre_get_posts altera el back-end. Este es el código apropiado para usar en functions.php para eliminar publicaciones etiquetadas destacadas de la página de inicio

function exclude_featured_tag( $query ) {
if ( !is_admin() && $query->is_home() && $query->is_main_query() ) {
$query->set( ''tag__not_in'', ''array(ID OF THE FEATURED TAG)'' );
}
}
add_action( ''pre_get_posts'', ''exclude_featured_tag'' );

PARTE TRES

Material de lectura adicional que será útil en el futuro.

• Etiquetas condicionales

• ¿Cuándo debería usar WP_Query vs query_posts () vs get_posts ()?

• Cuándo usar WP_query (), query_posts () y pre_get_posts

• Resumen de consultas

• Orientación con The Loop para CMS

Answer 2

Crear un nuevo objeto WP_Query () siempre está bien.

$sort= $_GET[''sort''];
if($sort == "pricelow"){
$sort_args = array(''meta_key'' => ''price'', ''orderby'' => ''meta_value_num'', ''order'', ''ASC'');
$new_query = new WP_Query($sort_args);
}
blah blah blah...

No no no lo siento por eso. No vi el gancho pre_get_posts.

El código en su pregunta es bueno para enganchar consultas. Como se describe en pre_get_posts :

pre_get_posts se ejecuta antes de que WP_Query se haya configurado.

Por lo tanto, engancha el WP_Query () predeterminado donde desee (en su código, cambia WP_Query en la solicitud GET).

En sus archivos de plantilla, use el nuevo WP_Query ($ args).