L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Personnalisation des points de terminaison de l'API REST –
Cet article sur la POO avancée pour WordPress était à l'origine publié par Torque Magazine et est reproduit ici avec autorisation.
J'ai beaucoup écrit sur PHP orienté objet et l'API WordPress REST pour Couple au cours des dernières années. J’ai également évoqué l’utilisation de Composer pour la gestion des dépendances et la fourniture d’un chargeur automatique, ainsi que des tests unitaires couverts. Le message de base de tout ce que j'ai écrit est que, en appliquant les meilleures pratiques établies en matière de développement logiciel à notre développement pour WordPress, nous pouvons créer de meilleurs plugins.
Il s'agit du premier d'une série d'articles qui rassembleront ces concepts dans un exemple pratique et fonctionnel. Je vais créer un plug-in WordPress pour modifier les fonctionnalités des points de terminaison de l'API REST de WordPress afin qu'ils puissent être optimisés pour la recherche. Le plugin est disponible sur GitHub . Vous voudrez peut-être parcourir le journal de commit pour voir comment je l'assemble.
Dans cette série, je vais couvrir la structuration des plugins et des classes à l'aide de PHP orienté objet et non seulement comment le créer. testable, mais aussi comment écrire des tests automatisés. Je vais couvrir la différence entre les tests unitaires, les tests d'intégration et les tests d'acceptation et vous montrer comment écrire et automatiser l'exécution de chaque type. Cet article commence par expliquer comment utiliser des filtres pour modifier l'API REST de WordPress à l'aide d'une approche orientée objet.
Amélioration de la recherche WordPress à l'aide de l'API REST
Des plug-in tels que SearchWP ou . Relevansi ou des intégrations avec ElasticSearch – une technologie utilisant une pile totalement différente de WordPress – utilisant Jetpack ou ElasticPress, sont souvent utilisées pour améliorer la recherche dans WordPress. Ces types de plug-in fournissent de meilleurs résultats de recherche et se marient souvent bien avec une interface de recherche à facettes, ce qui est très bien pour les applications de commerce électronique.
La recherche via l'API WordPress REST hérite de tous ces problèmes et de la même solution. Dans cet article, je commencerai par examiner le fonctionnement de la recherche par défaut et ses limites. Nous verrons ensuite comment modifier la recherche à l’aide de deux méthodes différentes et l’intégrer à SearchWP.
Les fonctionnalités de recherche intégrées de WordPress doivent souvent être améliorées à l’aide de services externes. Bien que cet article traite d'une approche orientée objet pour modifier le fonctionnement des itinéraires de l'API REST de WordPress pour les publications, l'exemple concret sera l'amélioration de la recherche.
Lorsque WordPress est utilisé comme back-end pour un serveur frontal découplé tel qu'un mobile natif application ou application Web, probablement construite avec Vue, React ou Angular, il est important d’avoir une recherche de qualité via l’API REST. Le code traité dans cet article vous aidera si les utilisateurs de votre application ont besoin de trouver la bonne variante de produit ou de rechercher du contenu à l'aide d'un algorithme complexe basé sur plusieurs taxonomies, et si vous écrivez du code personnalisé et pas seulement un plugin.
avec l’API REST de WordPress
Si vous souhaitez rechercher tous les articles de type «produit» sur un site, utilisez les termes de recherche «Taco Shirts» pour adresser une demande à / wp /. v2 / produit? s = point final Taco + Shirt . Si vous souhaitez améliorer la qualité des résultats, les solutions que j'ai énumérées ci-dessus pourraient vous aider.
Comme nous en avons discuté ci-dessus, WP_Query les points de terminaison de l'utilisation de l'API REST WordPress ne sont pas très intéressants. outil de recherche. Plus précisément, WP_Query probablement en raison de sa dépendance à MySQL, est inférieur aux outils de recherche spécialisés généralement créés à l'aide de bases de données NoSQL.
Tout d'abord, voyons comment nous pouvons contourner WP_Query. Interactions de avec la base de données WordPress en cas de requête d'une API REST.
Telle est la stratégie adoptée par de nombreux plug-ins de recherche pour remplacer les résultats de leurs propres systèmes de recherche par ce que WP_Query aurait généré par défaut. Le système de recherche peut utiliser la même base de données. Il peut également se connecter à une autre base de données, éventuellement via une requête d'API, par exemple à un serveur ElasticSearch ou Apache Solr.
Si vous regardez dans le noyau de WordPress vous trouverez le filtre «posts_pre_query». s'exécute juste avant WP_Query interroge la base de données, mais une fois la requête SQL préparée. Ce filtre renvoie null par défaut. Si cette valeur est null, WordPress poursuit son comportement par défaut: interroger la base de données WordPress et renvoyer les résultats sous la forme d'un tableau simple d'objets WP_Post .
D'autre part, si la valeur renvoyée par ce filtre est un tableau contenant des objets WP_Post – le comportement par défaut de WordPress n'est pas utilisé.
Voyons comment utiliser posts_pre_query pour renvoyer une maquette de WP_Post . Cette stratégie est très utile pour les tests, mais une version plus complexe du même modèle peut être utilisée pour intégrer une base de données séparée à votre site WordPress:
/ **
* Remplacer tous les résultats de WP_Query par des messages fictifs
* /
add_filter ('posts_pre_query',
fonction ($ postsOrNull, WP_Query $ query) {
// Ne pas exécuter si les messages sont déjà envoyés
if (is_null ($ postsOrNull)) {
// Créer 4 posts simulés avec des titres différents
$ mockPosts = [];
for ($ i = 0; $ i <= 3; $i++) {
$mockPosts[$i] = (new WP_Post((new stdClass()))); //Fake post for demonstration, could be any WP_Post
$mockPosts[$i]-> post_title = "Message simulé $ i"; // Le titre faux sera différent pour chaque message, utile pour les tests.
$ mockPosts [$i] -> filter = "raw"; // Contourner sanitzation dans get_post, pour éviter que nos données fictives ne soient épurées.
}
// Retourne un tableau factice de messages simulés
retourne $ mockPosts;
}
// retourne toujours quelque chose, même s'il est inchangé
return $ postsOrNull;
},
// Priorité par défaut, 2 arguments
10, 2
)
Dans cet exemple, nous utilisons des données fictives, mais nous pourrions utiliser la classe de requête de SearchWP, ou autre chose. Une autre chose à garder à l'esprit à propos de ce code est qu'il s'exécutera sur n'importe quel WP_Query et pas seulement un objet WP_Query créé par l'API WordPress REST. Modifions cela pour que nous n'utilisions pas le filtre, sauf s'il s'agissait d'une demande d'API REST WordPress, en ajoutant une logique conditionnelle:
<? Php
/ **
* Remplacer tous les résultats de WP_Query par des messages fictifs, pour les requêtes d'API RPress WordPress
* /
add_filter ('posts_pre_query',
fonction ($ postsOrNull, WP_Query $ query) {
// exécuté uniquement lors des demandes d'API WordPress REST
if (défini ('REST_REQUEST') && REST_REQUEST) {
// Ne pas exécuter si les messages sont déjà envoyés
if (is_null ($ postsOrNull)) {
// Créer 4 posts simulés avec des titres différents
$ mockPosts = [];
for ($ i = 0; $ i <= 3; $i++) {
$mockPosts[$i] = (new WP_Post((new stdClass()))); //Fake post for demonstration, could be any WP_Post
$mockPosts[$i]-> post_title = "Message simulé $ i"; // Le titre faux sera différent pour chaque message, utile pour les tests.
$ mockPosts [$i] -> filter = "raw"; // Contourner sanitzation dans get_post, pour éviter que nos données fictives ne soient épurées.
}
// Retourne un tableau factice de messages simulés
retourne $ mockPosts;
}
}
// retourne toujours quelque chose, même s'il est inchangé
return $ postsOrNull;
},
// Priorité par défaut, 2 arguments
10, 2
)
Modification des arguments des points de terminaison de l'API REST WordPress
Nous venons de voir comment modifier la manière dont les résultats de la recherche sont générés pour les demandes d'API REST WordPress. Cela nous permet d'optimiser nos requêtes pour une meilleure recherche, mais risque d'exposer un schéma différent pour les noeuds finaux.
Par exemple, si vous souhaitez autoriser la recherche sur vos noeuds finaux de produits, autorisez éventuellement des messages supplémentaires. type à inclure dans la recherche. J'ai abordé une approche différente du même problème l'année dernière .
Problèmes recoupés
Nous sommes sur le point de voir comment modifier les arguments de paramètre autorisés ainsi que la manière dont ils sont utilisés pour créer. WP_Query arguments. C’est deux préoccupations distinctes et le principe de responsabilité unique stipule que nous avons besoin d’une classe pour chaque préoccupation. Mais les deux classes auront des préoccupations communes.
Par exemple, si nous souhaitons autoriser l’interrogation par différents types de publication, nous devons savoir quels sont les types de publication publics et quels sont leurs arguments slug et rest_base. Ce sont toutes les informations que nous pouvons obtenir de la fonction get_post_types .
Le résultat de cette fonction n’est pas exactement ce dont nous avons besoin. Nous allons donc concevoir une classe pour formater les données en fonction des besoins que je viens d'énumérer et nous donner des méthodes d'assistance pour y accéder. 19659018] setPostTypes ($ postTypes);
}
/ **
* Obtenez un tableau de valeurs "rest_base" pour tous les types de publications publiques
*
* @return array
* /
fonction publique getPostTypeRestBases (): array
{
retourner! vide ($ this-> postTypes)? array_keys ($ this-> postTypes): [];
}
/ **
* Préparer les types de poste
*
* @param array $ postTypes
* /
fonction protégée setPostTypes (array $ postTypes)
{
$ this-> postTypes = [];
/ ** @var WP_Post_Type $ postType * /
foreach ($ postTypes en tant que $ postType) {
if ($ postType-> show_in_rest) {
$ this-> postTypes [$postType->rest_base] = $ postType-> nom;
}
}
}
/ **
* Convertir la base de l'API REST en post slug de type
*
* @param string $ restBase
* @retour string | null
* /
fonction publique restBaseToSlug (string $ restBase)
{
if (in_array ($ restBase, $ this-> getPostTypeRestBases ())) {
retourne $ this-> postTypes [$restBase];
}
return null;
}
}
Remarquez que nous n’appelons pas get_post_types () dans la classe. Nous l’avons plutôt utilisée comme dépendance, injectée via le constructeur. En conséquence, cette classe peut être testée sans charger WordPress.
C'est pourquoi je décrirais cette classe comme «unité testable». Il ne repose sur aucune autre API et nous ne sommes pas inquiets des effets secondaires. Nous pouvons le tester comme une seule unité isolée. En séparant les problèmes et en isolant les fonctionnalités en petites pièces, le code est maintenable une fois que nous disposons d'une couverture de test unitaire. Je verrai comment tester ce type de classe dans mon prochain article.
N'oubliez pas que cette classe s'appuie sur WP_Post_Type . Mes tests unitaires n'auront pas cette classe définie, car seuls les tests d'intégration auront WordPress ou toute autre dépendance externe disponible. Cette classe est uniquement utilisée pour représenter des données, pas pour effectuer des opérations. Nous pouvons donc dire que son utilisation ne crée aucun effet secondaire. En conséquence, je suis à l'aise avec l'utilisation d'une maquette à la place du réel WP_Post_Type dans les tests unitaires.
En parlant d'injection de dépendance, les classes qui nécessitent des objets de cette nouvelle classe, nous souhaitons suivre le même motif. Au lieu d'instancier PreparedPostTypes à l'intérieur des classes qui en ont besoin, nous allons passer à un exemple. Cela signifie que les classes consommant PreparedPostTypes et PreparedPostType restent isolées et peuvent être testées séparément.
Cela pourrait également conduire à une réutilisation du code car nous devons rendre cette injection de dépendance possible et disposer d'un propriété pour cet objet. Nous pourrions utiliser couper / coller, ou un trait PHP, qui est un moyen plus évolutif de copier des méthodes et des propriétés entre les classes.
Voici un trait qui établit un modèle pour l'injection de PreparedPostTypes. objet dans d'autres classes
preparePostTypes = $ preparePostTypes;
}
}
Notre autre préoccupation est que nous devons savoir certaines choses sur un type de message à plusieurs endroits. Par exemple, le slug du type de message. Ceci est une idée différente d'une préoccupation transversale par rapport à la précédente. Le dernier problème que nous avons résolu concernait les données dynamiques. Maintenant, nous avons juste besoin d’un seul endroit pour changer une chaîne ou deux que nous utilisons à plusieurs endroits.
Une classe qui a des constantes de classe résout ce problème pour nous simplement:
<? Php
/ **
* Classe PostType
*
* Type de message dont nous détournons le message POST wp / v2 /
*
* /
classe PostType
{
/ **
* Type de limace
*
* @TODO Changez ceci en slug de votre type de message
* /
const SLUG = 'post';
/ **
* Type de poste rest_base
*
* @TODO Changez ceci en la base rest_base de votre post
* /
const RESTBASE = 'posts';
}
Nous pouvons maintenant garder ces chaînes cohérentes dans tout notre code. Cela peut sembler une étape inutile. Mais mon exemple de code fonctionne pour le type de message posts. Si vous souhaitez modifier le type de publication utilisé, cette classe doit être modifiée et rien d'autre ne doit être modifié. Ceci correspond à la définition préférée du principe de responsabilité unique par Tom McFarlin lorsqu'il écrit: « Une classe ne devrait avoir qu'une raison de changer.
Modification des schémas de points de terminaison de l'API REST
Nous devons maintenant modifier le schéma des noeuds finaux d'un type d'article. Ce faisant, WordPress communiquera aux points d'extrémité de l'API REST que l'argument post_type est autorisé et que, lors de l'analyse des demandes, le nouvel argument du point d'extrémité est autorisé.
Voici notre classe pour ajouter le . attribut post_type . Notez qu'il utilise le trait UsesPreparedPostTypes dont nous venons de parler:
shouldFilter ($ post_type)) {
$ query_params [self::ARGNAME] = [
[
'default' => PostType::RESTBASE,
'description' => __('Post type(s) for search query'),
'type' => 'array',
//Limit to public post types and allow query by rest base
'items' =>
[
'enum' => $this->preparedPostTypes->getPostTypeRestBases(),
'type' => 'string',
],
]
];
}
return $ query_params;
}
/ **
* Vérifiez si le schéma de ce type de message doit être filtré
*
* @param WP_Post_Type $ WP_Post_Type
* @return bool
* /
fonction publique devraitFilter ( WP_Post_Type $ WP_Post_Type): bool
{
return PostType :: SLUG === $ WP_Post_Type-> name;
}
}
Dans les paramètres de cet attribut, nous indiquons à WordPress que cet attribut est un attribut de tableau et nous spécifions les valeurs autorisées à l'aide de l'index "enum" du tableau.
En "enum", nous énumérons les valeurs autorisées. Dans ce cas, la classe PreparedPostTypes fournit ce tableau de valeurs autorisées car il s'agit d'un problème transversal précédemment résolu.
Notez que cette classe n'est associée à aucun type de message ni même à cet usage spécifique. Cas. Nous verrons comment faire fonctionner ce travail avec nos besoins réels. Découpler cette classe de l'API des plugins WordPress permet de la réutiliser et de la tester à l'unité. Nous devons tester cette interaction avec WordPress, mais nous la couvririons dans un test d'intégration. Je vais vous montrer comment faire cela dans un prochain article.
Nous reviendrons bientôt sur les crochets à utiliser pour que cette classe fonctionne avec un type d'article spécifique.
Modification de l'API REST WP_Query Arguments
La section précédente a montré comment rendre disponible un nouvel attribut de point final post_type . Cela ne change pas les arguments WP_Query générés par l’API WordPress REST. Nous avons tout ce dont nous avons besoin, sauf un dernier filtre.
Le type de message est un WP_Query argument selon lequel le noyau interdit spécifiquement de modifier via une demande d'API REST. Nous avons un filtre nommé dynamiquement – rest _ {$ post_type} _query – qui peut remplacer n'importe quel argument WP_Query .
Voici notre classe qui injecte notre post_type . args, qui auparavant n'étaient pas autorisés:
shouldFilter ($ request)) {
add_filter ('posts_pre_query', [FilterWPQuery::class, 'posts_pre_query']10, 2);
$ args ['post_type'] = $ this-> restBasesToPostTypeSlugs ($ request [ModifySchema::ARGNAME]);
}
return $ args;
}
/ **
* Vérifiez si nous devrions filtrer les arguments de demande
*
* @param WP_REST_Request $ request
* @return bool
* /
fonction publique devraitFilter ( WP_REST_Request $ request): bool
{
$ attributs = $ request-> get_attributes ();
if (isset ($ attributs ['args'][ModifySchema::ARGNAME])) {
if ($ request-> get_param (ModifySchema :: ARGNAME)) {
retourne vrai;
}
}
retourne faux;
}
/ **
* Convertir un tableau de bases de repos pour poster des slugs
*
* @param array $ postTypes
* @return array
* /
fonction publique restBasesToPostTypeSlugs (array $ postTypes): array
{
$ postTypeSlugs = [];
foreach ($ postTypes en tant que $ postTypeRestBase) {
if ($ this-> preparePostTypes-> restBaseToSlug ($ postTypeRestBase)) {
$ postTypeSlugs [] = $ this-> preparePostTypes-> restBaseToSlug ($ postTypeRestBase);
}
}
return $ postTypeSlugs;
}
}
Cela consiste principalement à valider si nous devons effectuer le changement puis utiliser la méthode get_param de WP_Rest_Request pour obtenir la valeur de la requête. La majeure partie est automagique car nous modifions le schéma pour qu'il corresponde en premier.
Modification de WP_Query Objet pour la requête d'API WordPress REST
J'ai déjà montré comment faire cela dans la première partie de ce message. . Voici une classe qui implémente le même modèle:
<? Php
/ **
* Classe FilterWPQuery
*
* Modifie l'objet WP_Query
*
* @package ExamplePlugin
* /
classe FilterWPQuery
{
/ **
* Montre comment utiliser une méthode différente pour définir les publications renvoyées par WP_Query.
* @uses "posts_pre_query"
*
* @param $ postsOrNull
* @param WP_Query $ query
* retour mixte
* /
Fonction statique publique posts_pre_query ($ postsOrNull, $ query)
{
// exécuté uniquement lors de demandes d'API WordPress
if (défini ('REST_REQUEST') && REST_REQUEST) {
// Prévenir les récursions
remove_filter ('posts_pre_query', [FilterWPQuery::class, 'posts_pre_query']10);
// Ne pas exécuter si les messages sont déjà envoyés
if (is_null ($ postsOrNull)) {
// Créer 4 posts simulés avec des titres différents
$ mockPosts = [];
pour ($ i = 0; $ i <= 3; $i++) {
$mockPosts[$i] = (new WP_Post((new stdClass())));
$mockPosts[$i]-> post_title = "Mock Post $ i";
$ mockPosts [$i] -> filter = "raw";
}
// Retourne un tableau factice de messages simulés
retourne $ mockPosts;
}
// retourne toujours quelque chose, même s'il est inchangé
return $ postsOrNull;
}
}
}
init.php
<? php
/ **
* Faire tout ce travail
* /
add_action ('init', function () {
$ postType = PostType :: SLUG;
$ preparePostType = new PreparedPostTypes (get_post_types ([]'objets'));
$ modifySchema = new ModifySchema ($ preparePostType);
add_filter ("rest _ {$ postType} _collection_params", [$modifySchema, 'filterSchema']25, 2);
$ modifyQuery = new ModifyQueryArgs ($ preparePostType);
add_filter ("rest _ {$ postType} _query", [$modifyQuery, 'filterQueryArgs']25, 2);
});
J'espère que vous avez remarqué que ce code est très fortement lié à WordPress et qu'il ne sera pas testable. Il utilise WP_Post à partir de WordPress, il vérifie une constante à partir de WordPress et interagit avec l’API Plugins de WordPress. Nous pouvons nous moquer de WP_Post et nous pouvons définir la constante nous-mêmes. Mais l’API du plugin est une fonctionnalité essentielle à tester. Dans mes prochains articles, je vais expliquer comment refactoriser cette classe afin que nous puissions utiliser des tests unitaires pour tout couvrir sauf les effets de la suppression de ce filtre et des tests d'intégration pour vérifier cet effet.
J'ai choisi d'utiliser une méthode statique pour deux raisons. Premièrement, il a été facile de l'ajouter et de le supprimer à plusieurs endroits. Par exemple, dans la classe ModifyQuery je raccorde ce filtre uniquement lorsque cela est nécessaire:
add_filter ('posts_pre_query', [FilterWPQuery::class, 'posts_pre_query']10, 2);
$ args ['post_type'] = $ this-> restBasesToPostTypeSlugs ($ request [ModifySchema::ARGNAME]);
}
return $ args;
}
/ **
* Vérifiez si nous devrions filtrer les arguments de demande
*
* @param WP_REST_Request $ request
* @return bool
* /
fonction publique devraitFilter ( WP_REST_Request $ request): bool
{
$ attributs = $ request-> get_attributes ();
if (isset ($ attributs ['args'][ModifySchema::ARGNAME])) {
if ($ request-> get_param (ModifySchema :: ARGNAME)) {
retourne vrai;
}
}
retourne faux;
}
/ **
* Convertir un tableau de bases de repos pour poster des slugs
*
* @param array $ postTypes
* @return array
* /
fonction publique restBasesToPostTypeSlugs (array $ postTypes): array
{
$ postTypeSlugs = [];
foreach ($ postTypes en tant que $ postTypeRestBase) {
if ($ this-> preparePostTypes-> restBaseToSlug ($ postTypeRestBase)) {
$ postTypeSlugs [] = $ this-> preparePostTypes-> restBaseToSlug ($ postTypeRestBase);
}
}
return $ postTypeSlugs;
}
}
ModifySchema.php
shouldFilter ($ post_type)) {
$ query_params [self::ARGNAME] = [
[
'default' => PostType::RESTBASE,
'description' => __('Post type(s) for search query'),
'type' => 'array',
//Limit to public post types and allow query by rest base
'items' =>
[
'enum' => $this->preparedPostTypes->getPostTypeRestBases(),
'type' => 'string',
],
]
];
}
return $ query_params;
}
/ **
* Vérifiez si le schéma de ce type de message doit être filtré
*
* @param WP_Post_Type $ WP_Post_Type
* @return bool
* /
fonction publique devraitFilter ( WP_Post_Type $ WP_Post_Type): bool
{
return PostType :: SLUG === $ WP_Post_Type-> name;
}
}
En outre, il est facile de créer des boucles récursives avec ce filtre. Pouvoir facilement le supprimer, comme dans cet exemple, le code est très agréable.
L'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 testable à l'unité. Ce modèle, une classe avec des méthodes statiques, permet très facilement de se moquer de la classe dans les tests d'intégration, minimisant ainsi les effets de l'absence d'isolation importante dans cette partie du système.
Bien travailler ensemble
Le code Nous avons examiné jusqu'à présent est très découplé de WordPress. Cela a beaucoup d'avantages. Mais cela signifie que tel quel, il ne fait rien. C'est très bien. Nous n’avons traité jusqu’à présent que les exigences de la logique métier. Nous devons maintenant examiner l’intégration.
Ce n’est pas trop difficile, c’est juste une question d’ajout de points d’accroche. Quels crochets? Nous avons conçu exactement les mêmes deux crochets que nos classes ModifyQuery et ModifySchema autour. Le désir d’une logique métier découplée ne signifie pas que nous ne pouvons pas penser à la raison réelle pour laquelle nous écrivons le code lors de la conception de son interface publique. Sinon, nous ajouterons simplement une complexité supplémentaire à notre code sans raison.
En général, j'essaie d'ajouter une complexité logicielle uniquement lorsque cela simplifie la vie. Je me suis écarté de ce chemin dans le passé. Nous avons tous, c’est OK, pratiqué le pardon.
Les méthodes des classes que nous sommes sur le point d’accrocher utilisent exactement les mêmes arguments et renvoient les mêmes types que les hooks. Leur travail consiste à répartir ces valeurs commerciales avec les autres composants.
<? Php
/ **
* Faire tout ce travail
* /
add_action ('init', function () {
$ postType = PostType :: SLUG;
$ preparePostType = new PreparedPostTypes (get_post_types ([]'objets'));
$ modifySchema = new ModifySchema ($ preparePostType);
add_filter ("rest _ {$ postType} _collection_params", [$modifySchema, 'filterSchema']25, 2);
$ modifyQuery = new ModifyQueryArgs ($ preparePostType);
add_filter ("rest _ {$ postType} _query", [$modifyQuery, 'filterQueryArgs']25, 2);
});
Next Up: Testing
C’est assez proche du jazz. Ça va marcher. En l'absence d'un système formel pour ajouter des points d'ancrage, c'est tout ce que nous pouvons faire pour l'initialisation. C'est très bien. Nous verrons comment créer un processus d'amorçage plus sophistiqué et plus extensible dans un prochain article sur les tests d'intégration avec WordPress.
Dans cet article, nous avons examiné la création d'un code permettant de modifier le schéma, WP_Query . génération d'argument et sous-jacent WP_Query pour un type de message. Je vous encourage à transformer ce code en plug-in, en utilisant Composer pour l'autoloader. Dans mon article suivant nous examinerons des tests unitaires pour couvrir ces classes
Josh est un développeur et un éducateur WordPress. Il est le fondateur de Caldera Labs concepteur d’impressionnants outils WordPress, notamment Caldera Forms, un constructeur de formulaires WordPress réactif (glisser-déposer).
Source link