web-dev-qa-db-fra.com

Existe-t-il des scénarios dans lesquels query_posts peut être utilisé?

Je sens qu’un bouton rouge indique "Ne pas appuyer" en dessous de query_posts(). Pour être honnête, j'essaie de démystifier ce phénomène avec un très faible succès depuis quelque temps.

Par exemple, la raison principale de ne pas utiliser cette fonction est probablement une pagination interrompue. Deuxièmement, cela a-t-il pu être lent (lire: appeler deux fois), ou il y a de meilleures façons (pre_get_posts). Il peut y avoir plus de raisons.

Pour ceux qui peuvent noter cette question instinctivement, j’appellerais, au moins, pendant environ une semaine. Il y a toujours une deuxième chance de le faire. J'attends à peine de voir au moins quelques réponses, avant une pression d'équipe.

Pour ceux qui ne lisent pas cette publication, je dirais que cette fonction n’est ni dépréciée, ni marquée _doing_it_wrong, ni qu’il n’existe de plans. Même le ticket pour le rendre obsolète a été fermé récemment.

Certains peuvent dire qu'ils lisent cette fonction ne doit pas être utilisé dans WordPress. Je fournis ici la fonction complète.

File: /wp-includes/query.php
79: /**
80:  * Set up The Loop with query parameters.
81:  *
82:  * This will override the current WordPress Loop and shouldn't be used more than
83:  * once. This must not be used within the WordPress Loop.
84:  *
85:  * @since 1.5.0
86:  *
87:  * @global WP_Query $wp_query Global WP_Query instance.
88:  *
89:  * @param string $query
90:  * @return array List of posts
91:  */
92: function query_posts($query) {
93:     $GLOBALS['wp_query'] = new WP_Query();
94:     return $GLOBALS['wp_query']->query($query);
95: }

Vous pouvez voir This must not be used within the WordPress Loop., ce qui signifie pas dans la boucle WordPress, ce qui implique qu'avant la boucle WordPress peut ne pas être interdite.

J'ai noté de ce post que cette fonction n'est pas plus lente que toute requête secondaire (ayant les mêmes arguments).

Bottomline, parler de la pagination query_posts est une bien meilleure solution pour la pagination que le get_posts car get_posts désactive en fait le SQL_CALC_FOUND_ROWS.

Quelques bonnes idées sur le query_posts peuvent être:

  • les arguments de la requête ne sont pas limités, vous pouvez définir ce que vous voulez.
  • vous pouvez même définir les arguments pour utiliser la pagination, si vous n'envisagez pas d'utiliser les fonctions de base de la pagination; super facile, vous pouvez créer votre propre pagination
  • dans un blog typique, seule une petite partie des pages peut utiliser la pagination. La plupart des pages, dans la majorité des cas simples normaux, n'utilisent même pas la pagination; il est donc pratique de faire quelque chose de rapide et de réutiliser les modèles de requête principaux (boucle de lecture) query_posts.

Ce ne sont là que quelques-unes des réflexions; je suis sûr qu’il en reste plus, mais certainement, si vous savez ce que vous voulez, vous ne pouvez pas vous tromper.

Do no

loopqueryquery-posts
3
prosti

En face des idées reçues, query_posts est inoffensif si vous savez vous en servir. J'ai essayé ici de fournir plus d'arguments.

Ici, je vais ajouter un schéma simple sur lequel vous ne devriez jamais compter: $GLOBALS['wp_query'].

Vous devriez vous fier à $GLOBALS['wp_the_query'] qui devrait être gelé. Si vous souhaitez réinitialiser le $GLOBALS['wp_query'], utilisez simplement wp_reset_query.

Cas d'utilisation

enter image description here

Par exemple, si vous avez besoin de cela sur une page d'accueil, après la boucle principale, vous pouvez à nouveau appeler query_posts pour cpt1 et plus tard query_posts pour cpt2.

0
prosti

query_posts() est utile dans les cas où il n'y a aucune requête principale : appels à wp-admin/admin-ajax.php, wp-admin/admin-post.php ou wp-login.php par exemple.

Oui, vous pouvez obtenir les mêmes résultats sans query_posts() et un code légèrement moins compact à la place. Mais si vous n'avez pas à vous soucier des effets secondaires, utiliser query_posts() est acceptable.

5
fuxia

Chaque fois que la requête principale est disponible, c'est-à-dire pour chaque chargement de page front-end, quelle que soit la page/l'archive chargée, vous devez utiliser pre_get_posts pour modifier les vars de la requête de la requête principale avant la création et l'exécution de la requête SQL. Cela vaut pour chaque page où vous devez modifier la requête principale. C'est le moyen RECOMMANDÉ de modifier la requête principale. En procédant de cette manière, aucune requête supplémentaire en matière de base de données ne sera effectuée, point à la ligne. Pour les pages vraies et les pages de garde statiques, vous pouvez toujours utiliser ma PreGetPostsForPages classe ou même la méthode pre_get_posts décrite par @ birgire ici .

Vous ne devez jamais jamais remplacer la requête principale par une requête personnalisée, sans utiliser query_posts, une nouvelle instance de WP_Query ou get_posts. Cela ajoute des appels de base de données supplémentaires par chargement de page, car la requête principale est exécutée indépendamment. Si vous remplacez la requête principale par une requête personnalisée, vous exécutez deux fois plus d'appels de base de données, ce qui augmente également le temps de chargement des pages. Pas seulement cela, la pagination devient un cauchemar. Vous devriez prendre votre temps et lire cette réponse que j'ai faite sur la pagination .

Vous devez uniquement exécuter des requêtes personnalisées pour des éléments tels que les curseurs, les widgets, les publications associées et les menus de navigation, sans jamais remplacer ou modifier la requête principale.

query_posts reste un moyen très problématique d'exécuter des requêtes personnalisées car il modifie l'objet de requête principal stocké dans $wp_query ( $ GLOBALS ['wp_query'] ) car de nombreuses fonctions et plugins reposent sur le principal. objet de requête pour exécuter des choses comme la pagination et les messages connexes et chapelure

Comme @toscho l'a déjà mentionné, utilisez uniquement query_posts lorsqu'il n'y a pas de requête principale, ce qui concerne les appels ajax, et certaines pages du côté de l'administrateur. En dehors de cela, vous devriez vraiment éviter de l'utiliser, accepte quand vous avez vraiment besoin de casser quelque chose sur le front-end.

Comme je l'ai dit, il n'est absolument pas nécessaire d'exécuter un type de requête personnalisée à la place de la requête principale pour modifier ou modifier le résultat de la page. Si vous avez vraiment besoin de meilleures performances et de temps de chargement plus courts, utilisez pre_get_posts pour modifier la requête principale et ne la remplacez jamais pour une raison quelconque. Les requêtes personnalisées sont conçues pour créer des éléments supplémentaires tels que des widgets, des publications connexes et des curseurs.

MODIFIER

En guise de note finale et de preuve, téléchargez et installez le plug-in Query Monitor. De cette façon, vous pouvez constater l’augmentation considérable du temps de chargement des pages et des appels à la base de données lorsque vous remplacez la requête principale par une requête personnalisée, sans aucune différence lors de l’utilisation de pre_get_posts.

3
Pieter Goosen