@toscho a laissé un commentaire à cette réponse qui m'a fait réfléchir. Quelle confiance devrions-nous avoir dans la portée mondiale, en particulier en ce qui concerne les post-mondiaux comme $post
?
Et alors? La variable globale peut être remplacée par tout le monde avant l'exécution de votre vérification. C'est le point des variables globales: l'accès global.
$post
par exemple, est certainement l'un des globaux qui est principalement modifié soit dans le thème lui-même, soit par des plugins. Pourtant, il est également le global le plus couramment utilisé dans d'autres applications au sein d'un modèle donné, par exemple, pour configurer des publications liées.
En répondant à (et en commentant) plusieurs messages avec des problèmes spécifiques causés par l'utilisation de requêtes personnalisées , il ressort vraiment que la plupart des problèmes sont dus au fait que les requêtes personnalisées ne sont pas réinitialisées (les requêtes personnalisées modifient les globales définies par la requête principale).
De cela, il apparaît que ce $post
n'est pas fiable. Tout morceau de code mal écrit qui utilise une requête personnalisée peut altérer le $post
global, ce qui à son tour cassera quelque chose (comme les articles associés).
Seule une poignée de développeurs WordPress sont réellement suffisamment informés dans le fonctionnement interne du noyau et savent quoi éviter et quoi ne pas. La plus grande population d'utilisateurs n'a aucune idée du fonctionnement du noyau WordPress.
Ils téléchargent simplement un thème et installent des plugins pour faire ce qui est nécessaire ou même simplement copier le code d'un tutoriel. Supposons qu'ils installent un plugin mal écrit qui casse leurs publications connexes sur leur publication unique, comment sauront-ils ce qui a causé cela? Seront-ils capables de régler cela eux-mêmes ou seront-ils la centième personne à écrire un e-mail à l'auteur du thème à propos de ce problème ou à publier une question sur ce site?
Ma question: comment pouvez-vous vous prémunir contre de tels problèmes causés par un autre code importé quand un global comme $post
n'est pas fiable? Devrions-nous utiliser un global comme $post
du tout? Quelles sont les alternatives?
Juste pour partager mon esprit ici avant de conclure: j'ai pensé (et vu dans certains thèmes et plugins aussi) à utiliser wp_reset_postdata()
ou wp_reset_query()
avant d'utiliser $post
, pour m'assurer que le global est réinitialisé aux requêtes principales $post
. Mais pourquoi devrais-je gonfler mon code dans mon thème parce que quelqu'un d'autre n'a pas correctement codé son plugin? Et si quelqu'un a correctement réinitialisé sa requête personnalisée, cette opération est exécutée une deuxième fois inutile, ce qui n'est pas bon.
La deuxième méthode à laquelle j'ai pensé consiste à utiliser le $wp_query
puis à utiliser ses méthodes, quelque chose comme $wp_query->post
.
Toute réflexion à ce sujet sera appréciée.
Réponses:
Il y a une triste vérité: vous pouvez jamais être sûr que certains code ne cassera pas votre code, et il n'y a rien que vous pouvez faire pour empêcher cela. Surtout dans WordPress, où tout est global.
Cela dit, oui, global
$post
est l'une des var globales les plus utilisées, donc faire attention à cela peut être une bonne idée.Dans mon code, j'accède rarement directement à Global
$post
.En concours singulier , j'utilise
get_queried_object()
et vérifie généralement s'il$post
s'agit d'uneWP_Post
instance valide :Je fais cette vérification également dans les rares cas auxquels j'accède
$post
directement.Considérez que
get_queried_object()
retourne une valeur inattendue si du code utilisequery_posts
, mais bon, si quelqu'un utilise du code sur lequel il s'appuiequery_posts
, il le mérite si son site casse :)De plus, si j'attends certaines conditions, je les vérifie, par exemple des types de poste spécifiques ou un statut spécifique.
Si j'ai besoin de plus de contrôles et dans plus d'endroits, je crée une fonction pour les effectuer:
Lorsque
the_post()
vous êtes dans une requête personnalisée, lors de la boucle, l'appel réinitialise l'objet post, donc ça devrait aller. Ensuite, c'est ma responsabilité d'appelerwp_reset_postdata()
après une requête personnalisée, et je le fais, bien sûr :)la source