Creo que ahora entiendo lo que estás tratando de hacer. Cuando ejecuta una consulta personalizada con WP_Query
y establece el límite para obtener solo 5 publicaciones por página, la consulta solo recuperará 5 publicaciones y esa consulta solo contendrá 5 publicaciones, PERO para la En aras de la paginación, WP_Query
aún se ejecuta en toda la base de datos y cuenta todas las publicaciones que coinciden con los criterios de la consulta.
Esto se puede ver cuando observa las propiedades $found_posts
y $max_num_pages
de la consulta. Tomemos un ejemplo:
Tienes 20 publicaciones que pertenecen al tipo de publicación predeterminado post
. Solo necesitas las últimas 5 publicaciones sin paginación. Tu consulta se ve así:
$q = new WP_Query( 'posts_per_page=5' );
-
var_dump( $q->posts )
te dará las últimas 5 publicaciones como se esperaba
-
echo $q->found_posts
te dará 20
-
echo $q->max_num_pages
te dará 4
El impacto de este trabajo adicional es mínimo en los sitios con solo unas pocas publicaciones, pero esto puede resultar caro si está ejecutando un sitio con cientos o miles de publicaciones. Esto es un desperdicio de recursos si solo vas a necesitar las 5 últimas publicaciones
Hay un parámetro no documentado llamado no_found_rows
que usa valores booleanos que puede usar para hacer que su consulta salga de la cuenta después de encontrar las 5 publicaciones que necesita. Esto obligará a WP_Query
a no buscar más publicaciones que cumplan los criterios una vez que haya recuperado la cantidad de publicaciones consultadas. Este parámetro ya está integrado en get_posts
, por eso get_posts
es un poco más rápido que WP_Query
, aunque get_posts
usa WP_Query
En conclusión, si no va a utilizar la paginación en una consulta, siempre es aconsejable 'no_found_rows=true'
en su consulta para acelerar el proceso y ahorrar en recursos de desperdicio.