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

390

Parece que la mitad de los tutoriales en Codex y alrededor de la blogósfera usan query_posts() y utilice WP_Query . ¿Cuál es el trato?

    
pregunta Dan Gayle 13.09.2010 - 17:58

8 respuestas

629
  • query_posts() es una forma excesivamente simplista y problemática de modificar la consulta principal de una página reemplazándola con Nueva instancia de la consulta. Es ineficiente (vuelve a ejecutar consultas de SQL) y fallará de forma absoluta en algunas circunstancias (especialmente cuando se trata de paginación de publicaciones). Cualquier código WP moderno debería utilizar métodos más confiables, como hacer uso de pre_get_posts hook, para este propósito. TL; DR no utilice query_posts () nunca ;

  • get_posts() es muy similar en uso y acepta los mismos argumentos (con algunos matices, como diferentes valores predeterminados ), pero devuelve una variedad de publicaciones, no modifica las variables globales y es seguro de usar en cualquier lugar;

  • WP_Query la clase funciona detrás de la escena, pero también puedes crear y trabajar con tu propio objeto. de eso Un poco más complejo, menos restricciones, también es seguro de usar en cualquier lugar.

    
respondido por el Rarst 13.09.2010 - 18:10
52

query_posts : nunca debes usar query_posts . Aparte de lo que dijo @Rarst, el problema realmente grande con query_posts es que rompe el objeto de consulta principal (almacenado en $wp_query ). Una gran cantidad de complementos y códigos personalizados se basan en el objeto de consulta principal, por lo que romper el objeto de consulta principal significa que está rompiendo las funcionalidades de los complementos y el código personalizado. Una de esas funciones es la función de paginación más importante, por lo que si rompe la consulta principal, rompe la paginación.

Para demostrar cuán malo es query_posts , en cualquier plantilla, haga lo siguiente y compare los resultados

var_dump( $wp_query );
query_posts( '&posts_per_page=-1' );
var_dump( $wp_query );

get_posts y WP_Query son la forma correcta de construir consultas secundarias ( publicaciones relacionadas, controles deslizantes, contenido destacado y contenido en páginas frontales estáticas ) con. Debe tenerse en cuenta que no debe usar ninguno de los dos a favor de la consulta principal en la página de inicio, en una sola página o en cualquier tipo de página de archivo, ya que interrumpirá la funcionalidad de la página. Si necesita modificar la consulta principal, use pre_get_posts para hacerlo, y no una consulta personalizada. ( ACTUALIZACIÓN: Para las páginas principales estáticas y las páginas verdaderas, consulte Uso de pre_get_posts en páginas verdaderas y páginas frontales estáticas *)

En esencia, WP_Query es usado por la consulta principal y también es usado por get_posts , pero aunque get_posts() usa WP_Query , hay algunas diferencias

  • get_posts son más rápidos que WP_Query . El margen depende de la cantidad de publicaciones totales del sitio. El motivo de esto es que get_posts pasa 'no_found_rows' => true por defecto a WP_Query , que omite / rompe legalmente la paginación. Con 'no_found_rows' => true , WP_Query obtiene la cantidad de mensajes consultados y luego los rescata, donde, de forma predeterminada, busca todos los mensajes que coincidan con la consulta para calcular la paginación.

    Por este motivo, get_posts() se debe usar solo para consultas no paginadas. Paginar get_posts es realmente un gran lío. WP_Query debe usarse para todas las consultas paginadas

  • get_posts() no está influenciado por los filtros posts_* , donde WP_Query se ve influenciado por estos filtros. El motivo es que get_posts , de forma predeterminada, pasa 'suppress_filters' => true a WP_Query

  • get_posts tiene un par de parámetros adicionales como include , exclude , numberposts y category . Estos parámetros se cambian en parámetros válidos para WP_Query antes de pasar a WP_Query . include se cambia en post__in , exclude en post__not_in , category en cat y numberposts en posts_per_page . Solo una nota, todos de los parámetros que se pueden pasar a WP_Query funcionan con get_posts , usted puede ignorar y no usar los parámetros predeterminados de get_posts

  • get_posts devuelve solo la propiedad $posts de WP_Query mientras que WP_Query devuelve el objeto completo. Este objeto es muy útil cuando se trata de condicionales, paginación y otra información útil que se puede utilizar dentro del bucle.

  • get_posts no usa el bucle, sino un bucle foreach para mostrar las publicaciones. Además, no hay etiquetas de plantilla disponibles de forma predeterminada. setup_postdata( $post ) debe usarse para que las etiquetas de la plantilla estén disponibles. WP_Query usa el bucle y las etiquetas de plantilla están disponibles de forma predeterminada

  • get_posts pasa 'ignore_sticky_posts' => 1 a WP_Query , por lo que get_posts ignora las publicaciones adhesivas

En función de lo anterior, depende de usted si usar get_posts o WP_Query y qué necesita realmente de la consulta. Lo anterior debe guiarlo en su elección

    
respondido por el Pieter Goosen 18.06.2015 - 19:46
29

La diferencia básica es que query_posts() es realmente solo para modificar el Loop actual. Una vez que hayas terminado, es necesario restablecer el bucle y enviarlo de forma alegre. Este método también es un poco más fácil de entender, simplemente porque su "consulta" es básicamente una cadena de URL que pasa a la función, de esta manera:

query_posts('meta_key=color&meta_value=blue'); 

Por otra parte, WP_Query es más una herramienta de propósito general, y es más parecido a escribir directamente consultas de MySQL que query_posts() . También puedes usarlo en cualquier lugar (no solo en el Loop) y no interfiere con ninguna consulta actual en ejecución.

Tiendo a usar WP_Query más a menudo, a medida que sucede. En realidad, se reducirá a su caso específico.

    
respondido por el nickmjones 13.09.2010 - 18:09
13

Simplemente no hay necesidad de usar query_posts() . Todo lo que hace es crear una instancia de un nuevo objeto WP_Query y reasigna ese nuevo objeto a global wp_query .

Para referencia, lo siguiente es la función query_posts() real.

 function query_posts($query) {
        $GLOBALS['wp_query'] = new WP_Query();
        return $GLOBALS['wp_query']->query($query);
    }

Cree una instancia de su propio objeto WP_Query si desea crear un script de consulta personalizado en profundidad. O use get_posts() si todo lo que necesita hacer es un poco de manipulación de la luz aquí y allá.

En cualquier caso, te recomiendo que te hagas un favor y vayas a wp_includes/query.php y hagas una lectura minuciosa de la clase WP_Query .

    
respondido por el RebelPhoenix 13.07.2013 - 18:38
13

Asegúrate de usar wp_reset_query() después de usar query_posts() porque también afectará el resultado de otra consulta.

    
respondido por el Bindiya Patoliya 08.07.2013 - 06:50
9

Si recuerdo haber leído bien, esencialmente "el bucle" está haciendo WP_Query en los archivos principales, pero de una manera más fácil de entender.

    
respondido por el tw2113 23.09.2010 - 22:21
5
  • query_posts () : puede usarse en un solo caso si necesita modificar la consulta principal. Establece muchas variables globales;
  •   
  • get_posts () : es muy similar en mecánica y acepta los mismos argumentos, pero devuelve una variedad de publicaciones
  •   
  • WP_Query : puede crear y trabajar con su propio objeto. Un poco más complejo, menos restricciones, es seguro utilizarlo en cualquier lugar.
respondido por el dalveer 19.07.2017 - 16:28
-5

Yo diría que no use get_posts() en un complemento. En algunos casos, impone filtros muy restrictivos (set suppress_filters , ignore_sticky_posts , etc.) y probablemente solo debería usarse en un tema cuando quiera que se haga algo rápido.

    
respondido por el m4olivei 25.09.2013 - 18:03

Lea otras preguntas en las etiquetas