POO avancée pour WordPress: personnalisation des points de terminaison de l'API REST

(Cet article a été initialement publié par le magazine Torque et réimprimé avec permission.)

Ces dernières années, l'auteur a écrit de nombreux articles sur les API PHP et WordPress REST orientés objet dans le magazine Torque, qui implique également d'utiliser le compositeur pour la gestion des dépendances et le chargement automatique, ainsi que les tests unitaires. Le point central de tous les articles est: en appliquant les meilleures pratiques de développement logiciel établies au développement WordPress, nous pouvons créer de meilleurs plugins.

Il s'agit du premier d'une série d'articles qui intégreront ces concepts dans un exemple pratique et fonctionnel. Je vais expliquer comment créer un plugin WordPress pour modifier la fonctionnalité du point de terminaison de l'API WordPress REST pour mieux optimiser les recherches. Le plugin est disponible sur GitHub. Vous devrez peut-être parcourir le journal de validation pour comprendre mon processus de construction.

Dans cette série, je couvrirai comment construire des plugins et des classes à l'aide de PHP moderne axé sur les objets, et comment le rendre testable, et comment rédiger des tests automatisés pour cela. Je couvrirai les différences entre les tests unitaires, les tests d'intégration et les tests d'acceptation et vous montrer comment écrire et automatiser chaque type de test. Cet article présente d'abord comment utiliser une méthode orientée objet pour modifier l'API WordPress REST à l'aide de filtres.

Points clés

• Améliorer les points de terminaison de l'API WordPress REST avec PHP orienté objet pour de meilleures capacités de recherche et s'intégrer à des outils de recherche avancés tels que Elasticsearch.
• Modifiez les paramètres de point de terminaison de l'API REST et l'interaction WP_Query pour contourner les limites des recherches WordPress par défaut et améliorer la qualité de réponse des requêtes complexes.
• Utilisez des tests unitaires, des tests d'intégration et des tests d'acceptation pour un code robuste et facile à maintenir pour garantir que chaque composant s'exécute correctement dans l'écosystème WordPress.
• Utiliser l'injection de dépendance et les traits PHP pour gérer proprement les dépendances de classe, permettant un code de maintenance et de test plus facile.
• Personnaliser le mode de point de terminaison de l'API REST pour inclure des paramètres supplémentaires tels que post_type, permettant des capacités de recherche plus flexibles et puissantes.
• Ajustez dynamiquement les paramètres WP_Query via des demandes API REST spécifiques et utilisez des filtres pour affiner efficacement les résultats de recherche et le comportement de point de terminaison.

Amélioration de la recherche WordPress avec API REST

Utilisez généralement des plugins comme SearchWP ou pertinent, ou l'intégration avec ElasticSearch (une technologie qui utilise une pile complètement différente de WordPress) pour améliorer la recherche WordPress. Ces types de plugins fournissent de meilleurs résultats de recherche et sont souvent utilisés avec une interface de recherche multiforme, ce qui est très utile pour les applications de commerce électronique.

La recherche via l'API WordPress REST hérite de tous ces mêmes problèmes et des mêmes solutions. Dans cet article, je vais d'abord présenter le fonctionnement de la recherche et ses limites. Nous examinerons ensuite comment modifier les recherches et nous intégrer à SearchWP à l'aide de deux méthodes différentes.

La fonctionnalité de recherche intégrée de WordPress nécessite généralement une amélioration à l'aide de services externes. Bien que cet article porte sur une approche orientée objet pour modifier comment fonctionne le routage de la publication de l'API REST WordPress, l'exemple réel serait d'améliorer la recherche.

Lorsque WordPress est utilisé comme backend pour le découplage frontal (tels que les applications mobiles natives ou les applications Web, qui peuvent être construites à l'aide de Vue, React ou Angular), il est important de faire une recherche de haute qualité dans le reste API. Le code présenté dans cet article vous aidera si les utilisateurs de votre application doivent trouver la bonne variante de produit ou rechercher du contenu en fonction des algorithmes complexes basés sur plusieurs taxonomie et vous écrivez du code personnalisé au lieu d'installer simplement des plugins.

Rechercher des articles à l'aide de l'API WordPress REST

Si vous souhaitez rechercher tous les messages avec un type de «produit» sur un site, utilisez le terme de recherche «Taco Shirts» et vous ferez une demande au point final /wp/v2/product?s=Taco Shirt. Si vous souhaitez améliorer la qualité de vos résultats, les solutions énumérées ci-dessus vous aideront.

Comme mentionné ci-dessus, WP_Query (chose utilisée par le point de terminaison du post de l'API REST WordPress) n'est pas un bon outil de recherche. Plus précisément, WP_Query peut être moins susceptible que les outils de recherche dédiés qui ont tendance à être construits à l'aide de bases de données NoSQL en raison de sa dépendance à MySQL.

Tout d'abord, voyons comment contourner l'interaction de WP_Query avec la base de données WordPress lors de la création de demandes d'API de repos.

Il s'agit d'une stratégie utilisée par de nombreux plugins de recherche pour remplacer leurs propres résultats de système de recherche (qui sont générés par défaut pour WP_Query). Le système de recherche peut utiliser la même base de données. Il peut également se connecter à d'autres bases de données, peut-être via des demandes d'API, par exemple aux serveurs Elasticsearch ou Apache Solr.

Si vous regardez WordPress Core Code, vous constaterez que la filtre "Posts_pre_Query" s'exécute avant la base de données de requête WP_Query, mais après que la requête SQL soit prête. Ce filtre renvoie NULL par défaut. Si la valeur est nul, WordPress continue son comportement par défaut: interrogez la base de données WordPress et renvoyez le résultat en tant que simple tableau d'objets WP_POST.

En revanche, si la valeur de retour de ce filtre est un tableau (qui souhaite contenir un objet WP_POST), le comportement par défaut de WordPress n'est pas utilisé.

Voyons comment utiliser Posts_pre_Query pour retourner un WP_POST simulé. Cette stratégie est très utile pour les tests, mais une version plus complexe du même schéma peut être utilisée pour intégrer une base de données distincte avec votre site WordPress:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

Dans cet exemple, nous utilisons des données simulées, mais nous pouvons utiliser la classe de requête de SearchWP ou autre chose. Une autre chose à noter à propos de ce code est qu'elle s'exécutera sur n'importe quel WP_Query, pas seulement l'objet WP_Query créé par l'API WordPress REST. Modifions-le afin que nous n'utilisions pas les filtres à moins qu'il ne s'agisse d'une demande API WordPress REST:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

Modifier les paramètres de point de terminaison de l'API WordPress REST

Nous avons juste examiné comment modifier les résultats de recherche générés pour les demandes d'API WordPress REST. Cela nous permet d'optimiser la requête pour de meilleurs résultats de recherche, mais cela peut exposer le besoin de différents modèles du point final.

Par exemple, si vous souhaitez permettre les recherches de points de terminaison de produit, autorisez éventuellement les autres types de publication dans la recherche, j'ai introduit une autre solution au même problème l'année dernière.

Focus horizontale

Nous sommes sur le point de voir comment modifier les paramètres de point de terminaison autorisés et comment les utiliser pour créer des paramètres WP_Query. Ce sont deux préoccupations distinctes, et le principe de responsabilité unique indique que nous devons créer une classe pour chaque préoccupation. Mais ces deux classes auront partagé des préoccupations.

Par exemple, si nous voulons permettre la requête par différents types de messages, nous devons savoir quels sont les types de messages publics et quels sont leurs paramètres SLUG et REST_BASE. Toutes ces informations sont disponibles à partir de la fonction get_post_types.

La sortie de cette fonction n'est pas exactement ce dont nous avons besoin. Alors, concevons une classe pour formater les données en fonction des exigences que je viens de répertorier et de nous fournir un moyen d'aide d'y accéder.

Considérez-le comme une forme commune pour toutes les données de type post que nous devons utiliser dans les conteneurs disponibles:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

Notez qu'au lieu d'appeler get_post_types () dans la classe, nous l'utilisons comme dépendance, injectée via le constructeur. Par conséquent, cette classe peut être testée sans charger WordPress.

C'est pourquoi je décris ce type comme "-test unitable". Il ne dépend d'aucune autre API, et nous ne nous inquiétons pas des effets secondaires. Nous pouvons le tester comme une unité isolée séparée. Séparez la mise au point et isolez sa fonctionnalité en petites parties, et une fois que nous avons une couverture de test unitaire, nous pouvons rendre le code facile à maintenir. Je vais couvrir comment tester ce type de classe dans mon prochain post.

N'oubliez pas que cette classe dépend de wp_post_type. Mes tests unitaires ne définiront pas la classe car seuls les tests d'intégration peuvent utiliser WordPress ou toute autre dépendance externe. Cette classe est utilisée uniquement pour représenter les données, pour ne pas effectuer d'action. Par conséquent, nous pouvons dire que son utilisation n'aura aucun effet secondaire. J'aimerais donc utiliser des simulations dans les tests unitaires au lieu de réel WP_post_type.

En parlant d'injection de dépendance, des classes qui nécessitent des objets de cette nouvelle classe, nous voulons suivre le même modèle. Au lieu d'instantifier des TTYPES préparés dans la classe qui les nécessite, nous passons dans un cas. Cela signifie que les classes utilisant des TTYPES PRÉPEPTAYS et PREAKETPOSTTYPE sont maintenues isolées et peuvent être testées séparément.

Cela peut également provoquer une réutilisation du code car nous devons rendre possible l'injection de dépendance et définir une propriété pour cet objet. Nous pouvons utiliser Cut and Coller, ou nous pouvons utiliser le trait PHP, une méthode plus avancée et extensible pour la copie des méthodes et des propriétés entre les classes.

Il s'agit d'un trait qui établit un modèle pour injecter des objets préparés PostType dans d'autres classes:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

L'une de nos préoccupations est que nous devons connaître certaines informations sur le type de poste à plusieurs endroits. Par exemple, Slug de type post. Ceci est légèrement différent de la préoccupation transversale précédente. Le dernier problème que nous avons résolu implique des données dynamiques. Maintenant, nous devons simplement changer les chaînes que nous utilisons à plusieurs endroits en un seul endroit.

Une classe avec des constantes de classe a simplement résolu ce problème pour nous:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

Maintenant, nous pouvons rendre ces chaînes cohérentes tout au long du code. Cela semble être une étape inutile. Mais mon exemple de code fonctionne pour le type de post. Si vous souhaitez modifier le type de message que vous utilisez, cette classe doit être modifiée sans rien changer d'autre. Cela suit la définition préférée de Tom McFarlin du principe de responsabilité unique lorsqu'il a écrit "une classe ne devrait avoir qu'une seule raison de changer".

Modifier le mode de point de terminaison de l'API REST

Maintenant, nous devons modifier le modèle du point de terminaison de type post. Ce faisant, WordPress communiquera au point de terminaison de l'API REST que le paramètre de type post est autorisé et que les nouveaux paramètres de point de terminaison sont autorisés lors de l'analyse de la demande.

Il s'agit de notre classe pour ajouter la propriété post_type. Veuillez noter qu'il utilise le trait utilisé par chose que nous venons de discuter:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

Dans les paramètres de cette propriété, nous disons à WordPress que cette propriété est une propriété de tableau, et nous utilisons l'indice "Enum" du tableau pour spécifier les valeurs autorisées.

Dans "Enum", nous énumons les valeurs autorisées. Dans ce cas, la classe PreadalPostTypes fournit un tableau de valeurs autorisées, car il s'agit d'une préoccupation transversale précédemment résolue.

Notez que cette classe n'est couplée à aucun type de post ou même à ce cas d'utilisation spécifique. Nous reviendrons bientôt sur les crochets à utiliser pour que cette classe fonctionne pour des types de publication spécifiques.

Modifier le paramètre API REST WP_Query

La section précédente décrit comment rendre la nouvelle propriété Endpoint Post_Type disponible. Cela ne modifie pas réellement le paramètre WP_Query généré par l'API WordPress REST. Nous avons déjà tout ce dont nous avons besoin, sauf le dernier filtre.

Le type de post est un paramètre WP_Query que le code de base n'autorise spécifiquement pas les modifications de la demande API REST. Nous avons un filtre nommé dynamiquement - Record _ {$ post_type} _Query - peut remplacer tout paramètre WP_Query.

Ceci est notre classe, qui injecte nos paramètres post_type, qui n'étaient pas autorisés auparavant:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

La plupart sont simplement pour vérifier que nous devons apporter des modifications, puis utiliser la méthode get_param de wp_rest_request pour obtenir la valeur de la demande. La majeure partie est automatique car nous modifions d'abord le modèle pour correspondre.

Modifiez l'objet WP_Query demandé par API REST WordPress

J'ai déjà couvert comment procéder dans la première partie de cet article. Ceci est une classe qui implémente le même modèle:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

J'espère que vous remarquerez que ce code est étroitement lié à WordPress et n'est pas testable. Il utilise WP_POST à ​​partir de WordPress, qui vérifie les constantes pour WordPress et interagit avec l'API du plugin de WordPress. Nous pouvons simuler WP_POST, et nous pouvons nous définir des constantes. Mais l'API du plugin - c'est une fonctionnalité importante qui doit être testée. Dans mes prochains messages, je couvrirai comment refacter cette classe afin que nous puissions utiliser des tests unitaires pour tout couvrir, sauf l'effet de la suppression de ce filtre et d'utiliser des tests d'intégration pour vérifier cet effet.

J'ai choisi d'utiliser une méthode statique pour deux raisons. Tout d'abord, cela facilite l'ajouter et le supprimer à plusieurs endroits. Par exemple, dans la classe ModifyQuery, je n'accroche ce filtre que si nécessaire:

<code class="language-php">// ... (代码示例与原文相同) ...</code>

De plus, il est facile de créer des boucles récursives lors de l'utilisation de ce filtre. C'est génial de pouvoir le supprimer aussi facilement que dans cet exemple de code.

Une autre raison pour laquelle j'ai choisi d'utiliser une méthode statique est que la fonction interagit avec d'autres API. Ce ne sera jamais vraiment un unité-test. Ce modèle, une classe avec des méthodes statiques, facilite la simulation de la classe dans les tests d'intégration, minimisant ainsi l'impact de l'absence d'isolement fort dans une partie de ce système.

Faire fonctionner tous les contenus ensemble

Le code que nous avons vu jusqu'à présent est très découplé de WordPress. Il y a de nombreux avantages à cela. Mais cela signifie qu'il ne fait rien seul. C'est très bien. Nous n'avons traité que les exigences de la logique commerciale jusqu'à présent. Nous devons maintenant considérer l'intégration.

Ce n'est pas difficile, il suffit d'ajouter des crochets. Quels crochets? Les deux mêmes crochets que nous avons conçus pour les classes ModifyQuery et ModifySchema. Le désir de découpler la logique commerciale ne signifie pas que nous ne pouvons pas considérer les raisons réelles pour lesquelles nous écrivons du code lors de la conception de leurs interfaces publiques. Sinon, nous ne ferons qu'ajouter une complexité supplémentaire à notre code sans raison.

D'une manière générale, j'essaie d'augmenter la complexité des logiciels que lorsque cela facilite la vie. Je me suis dévié de ce chemin dans le passé. Nous l'avons tous, cela n'a pas d'importance, de pratiquer le pardon.

Les méthodes de la classe que nous sommes sur le point de crocher utilisent exactement les mêmes paramètres et types de retour que le crochet. Leur travail consiste à attribuer ces valeurs à d'autres composants.

<code class="language-php">// ... (代码示例与原文相同) ...</code>

Étape suivante: Tester

C'est assez proche. Cela fonctionnera. En raison de l'absence d'un système formel pour ajouter des crochets, c'est la meilleure chose que nous puissions faire pour l'initialisation. C'est très bien. Je vais couvrir comment créer un processus de démarrage plus complexe et évolutif dans un futur article sur les tests d'intégration WordPress.

Dans cet article, nous examinons le WP_Query sous-jacent pour créer du code pour modifier le schéma, la génération de paramètres WP_Query et le type de poste. Je vous encourage à convertir ce code en un plugin et à utiliser le compositeur pour le chargement automatique. Dans mon prochain article, nous examinerons les tests unitaires pour couvrir ces cours.

(Ce qui suit est la partie FAQ d'origine, et la création pseudo-originale a été faite sur la base du contenu original)

FAQ sur les points de terminaison API OOP et REST personnalisés avancés dans WordPress

Quelle est la signification de la programmation orientée objet (OOP) dans WordPress?

La programmation orientée objet (OOP) est un paradigme de programmation pour concevoir des applications et des logiciels à l'aide de "objets". Dans un environnement WordPress, la POO fournit un moyen simple, efficace et robuste de développer des applications complexes. Il permet aux développeurs de regrouper les tâches pertinentes en classes et objets, ce qui rend le code plus facile à lire, à réutiliser et à maintenir. La POO améliore également la sécurité des applications en encapsulant les données et en empêchant l'accès externe direct.

Comment personnaliser les points de terminaison de l'API REST dans WordPress?

L'API WordPress REST fournit un ensemble de points de terminaison par défaut pour différents types de données. Cependant, vous pouvez personnaliser ces points de terminaison ou créer de nouveaux points de terminaison en fonction de vos besoins spécifiques. Cela peut être fait en utilisant la fonction register_rest_route() dans votre plugin ou thème. Cette fonction vous permet de spécifier l'itinéraire ou l'URL du point de terminaison et de définir les méthodes auxquelles il doit répondre (obtenir, publier, etc.).

Quels sont les avantages de la personnalisation des points de terminaison de l'API WordPress REST?

Les points de terminaison API WordPress REST personnalisés vous permettent de créer des applications plus efficaces, flexibles et sécurisées. Vous pouvez ajuster les données renvoyées par le point final pour réduire la quantité de données inutiles envoyées sur le réseau. Vous pouvez également créer des points de terminaison qui effectuent des tâches spécifiques, telles que le traitement des soumissions de formulaires ou la génération de rapports, ce qui rend votre application plus interactive et conviviale.

Comment OOP améliore-t-il la sécurité des applications WordPress?

OOP améliore la sécurité des applications WordPress en encapsulant des données et des méthodes dans des objets. Cela signifie que les propriétés (données) et les méthodes (fonctions) de l'objet sont cachées du reste de l'application et ne sont accessibles que via les méthodes de l'objet. Cela empêche l'accès et la manipulation non autorisés des données, réduisant ainsi le risque de violations de sécurité.

peut-il être utilisé avec des versions plus anciennes de WordPress?

Oui, vous pouvez utiliser OOP avec des versions plus anciennes de WordPress. Cependant, il est important de noter que les versions plus récentes de WordPress ont amélioré le support OOP et incluent de nombreuses fonctionnalités pour faciliter le développement en utilisant ce paradigme. Ainsi, bien que la POO puisse être utilisée avec des versions plus anciennes, il est généralement recommandé d'utiliser la dernière version de WordPress pour la meilleure expérience de développement.

Quels sont les rôles des classes et des objets dans OOP?

Dans OOP, une classe est un plan ou un modèle pour créer un objet. Il définit les propriétés (données) et les méthodes (fonctions) qu'un objet devrait avoir. D'un autre côté, un objet est une instance d'une classe. Il a son propre ensemble de propriétés et de méthodes qui peuvent être différents des autres objets de la même classe. L'utilisation des classes et des objets rend le code plus organisé, réutilisable et facile à entretenir.

Comment créer une nouvelle classe dans WordPress?

Vous pouvez utiliser le mot-clé class, suivi du nom de classe et d'un ensemble de bretelles bouclées {} pour créer une nouvelle classe dans WordPress. Dans les parenthèses, vous pouvez définir les propriétés et les méthodes de la classe. Pour créer un objet d'une classe, vous pouvez utiliser le mot-clé new suivi du nom de classe.

Qu'est-ce que l'API REST dans WordPress?

L'API REST dans WordPress est une interface qui vous permet d'interagir avec votre site WordPress à l'aide des demandes HTTP. Il fournit un ensemble de points de terminaison pour différents types de données tels que les publications, les commentaires et les utilisateurs auxquels vous pouvez accéder à l'aide de méthodes HTTP standard telles que GET, Publier, Put et Supprimer. L'API REST vous permet de créer, de lire, de mettre à jour et de supprimer des données de votre site WordPress à partir d'une application externe.

Comment accéder à l'API REST dans WordPress?

Vous pouvez accéder à l'API REST dans WordPress en envoyant des demandes HTTP au point de terminaison correspondant. Chaque point final correspond à un type spécifique de données et prend en charge certaines méthodes HTTP. Par exemple, pour récupérer une liste de postes, vous pouvez envoyer une demande de GET au point de terminaison /wp/v2/posts. L'API REST renverra des données au format JSON, que vous pouvez ensuite traiter et afficher dans votre application.

Puis-je utiliser l'API REST avec une application non-WordPress?

Oui, vous pouvez utiliser l'API REST avec des applications non WordPress. L'API REST est autochtone, ce qui signifie qu'il peut être utilisé avec n'importe quelle application qui peut envoyer des demandes HTTP et traiter les données JSON. Cela en fait un outil puissant pour intégrer les sites WordPress avec d'autres applications telles que les applications mobiles, les applications de bureau et d'autres services Web.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!