Améliorations de la lisibilité de WP_Query (pour la maintenance)
Travailler avec WP_Query, en particulier lorsque vous effectuez un travail personnalisé en dehors de l’habituel "obtenir des messages et les afficher sur un modèle" peut être puissant. Cela est particulièrement vrai pour certains des arguments avancés (comme utiliser WP_Meta_Query, par exemple) .
C’est aussi plutôt bien que la mise en place du processus ait une manière standard de faire les choses. À savoir:
- Définir les arguments,
- Instanciez WP_Query,
- Vérifiez s’il y a des messages,
- Faites une boucle à travers eux,
- Terminez -les .
Mais si vous arrivez là où vous effectuez un travail avancé, comme travailler avec un type de publication personnalisé à partir d’une solution tierce, devoir charger des médias, déterminer si quelque chose existe avant de travailler avec, alors cela peut être un un peu plus compliqué à travailler, n’est-ce pas ?
J’ai trouvé que, comme avec n’importe quoi dans la programmation, le décomposer en modules beaucoup plus lisibles (ou fonctions ou pièces ou tout ce que vous voudriez les appeler) peut rendre le travail beaucoup plus facile.
Voici donc une façon dont je travaille pour améliorer la lisibilité de WP_Query dans une variété de choses que j’ai faites récemment.
Améliorations de la lisibilité de WP_Query
Avant de parcourir un exemple, il convient de souligner qu’il y a certaines choses que la façon dont WP_Query est configuré que nous ne pouvons pas faire.
Par exemple, une fois la requête instanciée, nous ne pourrons peut-être pas faire des choses beaucoup plus avancées avec (je veux dire, mettre en place des tests unitaires qui ne nécessitent pas le cœur de WordPress va être impossible).
C’est le visage de celui qui ne peut pas suivre votre code.
Cela dit, voici un exemple de ce à quoi cela peut ressembler lorsque vous démarrez, puis comment il peut être refactorisé pour avoir des fonctions plus petites, chacune étant plus intentionnelle qu’une longue méthode.
Un exemple
Pour cet article, disons que j’ai besoin d’interroger la base de données pour tous les articles et articles publiés et que je souhaite les ordonner par ID.
Ensuite, je veux déterminer si un outil tiers lui a attribué des métadonnées qui correspondent à un modèle que je peux ensuite attribuer par programme en fonction d’un thème que j’ai.
Peut-être que la version initiale du code pourrait ressembler à ceci :
C’est beaucoup de code pour faire pas mal de travail pour une fonction. À tout le moins, il expose tout ce qui doit arriver, n’est-ce pas ?
Avant d’aller plus loin, notez que le tableau de mappage n’est qu’un exemple, mais les clés représentent la clé méta pour le mapper, et cela nous aide à mapper la définition de la valeur _wp_page_template quand vient le temps de le mapper aux fichiers de modèle WordPress réels.
Alors, comment cela peut-il être décomposé?
1 Coup d’envoi
La première chose que nous voulons faire est de créer une fonction qui met le tout en mouvement. Vous pouvez choisir de le faire de plusieurs manières.
Voici comment j’ai choisi de le faire :
En termes simples, il utilisera quelques fonctions d’assistance – que je documenterai toutes ci-dessous – puis attribuera les modèles que nous avons dans le tableau de mappage défini ci-dessus.
2 Charger les publications et les pages
Naturellement, la première chose que nous voulons faire est de configurer une fonction à appeler qui renverra les résultats de la requête :
Cela renvoie les résultats de la requête. De cette façon, nous pouvons déterminer si nous devons effectuer des travaux supplémentaires que nous disons dans l’essentiel à l’étape précédente :
Si ce n’est pas le cas, nous avons terminé. Sinon, évidemment, on continue.
3 Récupérer l’ID de modèle tiers
Ensuite, l’idée d’attribuer des modèles – comme indiqué dans le code ci-dessus – semble assez simple, mais il y a quelques choses que nous devons faire en premier :
- parcourir les messages,
- récupérez l’ID tiers du modèle,
- récupérez le nom du modèle tiers,
- assignez le modèle à partir de la constante de mappage définie précédemment dans la classe.
L’itération initiale de la fonction peut ressembler à ceci :
Mais comme vous pouvez le voir, il existe encore des fonctions d’assistance qui ont besoin de définitions. Des choses comme la possibilité d’obtenir l’ID du modèle, le nom du modèle et, finalement, d’attribuer le modèle.
Notez cependant que si l’une des fonctions d’assistance ne renvoie pas de valeur utile, nous continuons la boucle. Ceci est nécessaire si ce n’est pour une autre raison que de s’assurer que nous n’essayons pas de mapper des modèles qui n’existent pas (mais je trouve que cela facilite également la lecture).
4 Trouver le fichier auquel l’ID de modèle correspond
Ensuite, une petite fonction peut être utilisée pour examiner l’ID de modèle tiers et déterminer si nous pouvons mapper cette valeur sur les pages qui existent dans notre base de données.
Si ce n’est pas le cas, nous pouvons renvoyer une chaîne vide, puis demander à la fonction qui a invoqué cette vérification particulière de voir si cela vaut la peine de continuer avec la boucle que nous avons définie.
5 Saisissez le nom du modèle
En supposant que nous ayons un ID de publication valide, nous devons maintenant récupérer le nom du modèle à partir du tableau de mappage défini plus tôt dans la publication :
Voici le truc : soit nous allons renvoyer le nom du modèle, soit nous allons renvoyer une valeur nulle. Encore une fois, c’est pour que nous puissions déterminer si nous devons continuer avec la boucle d’attribution de modèles ou non.
6 Affectez le modèle
Enfin, nous pouvons récupérer l’ID du modèle fourni par le tiers et l’utiliser pour le mapper au fichier que nous avons inclus avec notre travail, comme indiqué précédemment dans l’article :
Et c’est finalement ainsi que vous pouvez créer un code et des fonctions beaucoup plus petits, plus faciles à lire et à utiliser lorsque vous travaillez avec des requêtes légèrement plus compliquées.
Et donc, des améliorations de lisibilité
Pour ceux qui ont l’habitude d’écrire, de lire de longues méthodes ou de faire des choses comme la plupart des tutoriels sur le Web montrent comment faire les choses dans WordPress, cela peut ressembler à beaucoup de code inutile.
Mais considérez ceci :
- Les méthodes plus longues sont plus difficiles à lire,
- Ils peuvent être plus difficiles à déboguer,
- Et ils ne décomposent pas le problème en éléments plus gérables.
Bien sûr, j’aimerais diviser cela en encore plus de classes avec leurs responsabilités, et je pense que cela peut être fait, mais étant donné la nature de WP_Query, cela nécessiterait un peu plus de travail.
J’ai donc essayé de trouver le plus de terrain d’entente possible.
Si vous travaillez avec des utilisations même légèrement plus avancées de WP_Query, je vous recommande au moins d’envisager de le décomposer en plus petits morceaux.
Cela aide à prendre soin de la lisibilité, potentiellement de toute maintenabilité, et à écrire un code plus propre plutôt qu’une longue méthode avec trop de conditions et s’appuyant sur une variété d’autres données.