Je sais que la requête principale est rapide, car elle récupère les données après l'analyse de l'URL et après l'instanciation de WP_Query
. Nous sommes en OO PHP.
Mais query_posts
est-il vraiment plus lent qu'une requête secondaire se produisant dans un modèle, par exemple avec get_posts
, ou natif avec lequel vous appelez
// WP_Query arguments
$args = array (
);
// The Query
$query = new WP_Query( $args );
Tu demandes:
query_posts est-il vraiment plus lent qu'une requête secondaire ...
Le fait est que si vous appelez query_posts()
depuis un thème, alors , il s'agit déjà d'une requête secondaire . WordPress a déjà interrogé la base de données une fois pour obtenir une certaine page, puis frappe votre fonction query_posts()
et interroge à nouveau la base de données , créant une seconde requête et écrasant la demande originale/données.
Du point de vue de la vitesse, vous ne remarquerez aucune différence. Les fonctions query_posts()
utilisent WP_Query()
et prennent quelques microsecondes pour écraser certaines variables globales. La plus grosse surcharge viendra du fait que vous aurez à normaliser vos données et à compenser tout problème de niche lié à la pagination.
En termes simples, tout est inefficace. Donc, même s’il n’ya peut-être pas de "gros bouton rouge" indiquant "N'appuie pas ici!" c'est à peu près implicite qu'il ne faut pas appuyer dessus. Ce n'est pas grand et rouge mais Le Codex stipule spécifiquement :
Remarque: Cette fonction n'est pas destinée à être utilisée par des plugins ou des thèmes.
Si vous voulez être efficace et devez remplacer la requête principale - utilisez pre_get_posts
pour modifier les paramètres de la requête avant de l'appeler de la base de données, ce qui enregistre un appel de base de données entier (en ce sens nous n’avons pas besoin d’une requête secondaire).
En général,
la requête effectuée sur la page d'accueil,
query_posts( 'posts_per_page=get_option( 'posts_per_page' )
et
$q = new WP_Query( 'posts_per_page=get_option( 'posts_per_page' )
devrait avoir exactement les mêmes performances avec très peu, voire aucune, de différence entre elles, car toutes les réponses ci-dessus sont exactement les mêmes par défaut (, c’est-à-dire qu’elles ont les mêmes arguments de requête par défaut ). En effet, toutes ces requêtes utilisent la classe WP_Query
pour exécuter les requêtes de construction, puis les requêtes de base de données afin de renvoyer les publications interrogées. get_posts()
est un peu plus rapide bien qu'il utilise également WP_Query
. La grande différence est que get_posts
passe no_found_rows=true
à WP_Query
qui rompt légalement la pagination.
Ce qui est vrai, la requête principale ( principale ) s'exécute à chaque chargement de page en fonction de la page en cours de chargement. Supprimer la boucle principale et la remplacer par une requête secondaire ( soit query_posts()
, WP_Query
ou get_posts()
) est ce que l'on appelle ralentir la page. C'est parce que vous faites le même travail deux fois. Comme je l’ai dit, la requête principale s’exécute malgré tout. Vous avez donc déjà interrogé la base de données pour trouver des publications et remplacé la boucle principale par une requête secondaire.
Mis à part les problèmes créés avec la pagination et d’autres problèmes, c'est pourquoi on devrait ne jamais remplacer la boucle principale de la requête principale par une secondaire. J'ai fait un article complet sur ce que vous pouvez lire ici . Pour modifier la requête principale, utilisez toujours pre_get_posts
car il modifie les vars de la requête avant que la classe WP_Query
ne construise et n'exécute la requête SQL. Il existe également d'autres filtres ( filtres de post-clause ) disponibles dans WP_Query
que vous pouvez utiliser pour modifier directement la requête SQL.
Ce qui rend query_posts
incorrect, c’est qu’il modifie l’objet de requête principal sur lequel de nombreuses fonctions reposent, car query_posts
procède comme suit:
$wp_query = new WP_Query()
et il modifie également les balises conditionnelles. Pour une explication complète, vous pouvez lire ma réponse ici . Un WP_Query
normal ne fait pas cela