Un guide simple pour organiser des cours centrés sur WordPress
L’une des choses sur lesquelles j’ai fait un effort beaucoup plus concerté, probablement plus que jamais auparavant, est la gestion de la séparation des préoccupations entre les classes responsables de l’interface avec WordPress et celles chargées de travailler avec le domaine problématique.
Par exemple, disons que vous travaillez sur un plugin et qu’il va communiquer avec une API tierce. De plus, ce plugin proposera également des menus, des types de publication, des taxonomies, etc. dans la zone d’administration de WordPress.
Il y a deux domaines de responsabilité ici :
- la zone responsable de la résolution générale du problème,
- la zone responsable de l’interfaçage avec WordPress.
Vous pouvez faire valoir qu’il est important de tester les zones qui communiquent avec WordPress, mais je sais aussi que ce sont des API éprouvées qui ont leur propre ensemble de tests.
Au lieu de cela, nous devrions nous concentrer sur les tests unitaires et séparer notre logique métier de WordPress.
Mais ce n’est pas le propos de ce post. Au lieu de cela, il s’agit plutôt d’un moyen de présenter potentiellement un projet lorsqu’une partie de celui-ci s’interfacera avec WordPress.
J’ai parlé de l’importance et des avantages des espaces de noms dans des articles précédents afin de ne pas plonger trop profondément dans cette discussion ici.
Au lieu de cela, je suis intéressé à parler de l’organisation des fichiers au niveau du système de fichiers et au niveau de l’espace de noms, afin qu’ils soient clairement séparés dans leurs domaines de spécialisation et afin que nous puissions nous assurer que nous concentrons, disons, nos tests unitaires (et d’autres tests) sur les zones les plus critiques.
Résumé des méta-boîtes
J’aime m’assurer que la structure de mon répertoire et de mes fichiers reflète celle de mes espaces de noms. Bien sûr, cela aide à l’organisation des fichiers, mais aussi à une organisation conceptuelle.
Autrement dit, si je vais travailler avec des boîtes de méta, je sais que je peux probablement trouver les fichiers de boîte de méta dans un répertoire imbriqué avec le répertoire WordPress parent, puis dans un sous-répertoire Admin suivi d’un répertoire MetaBox.
À cette fin, à quoi pourrait ressembler un ensemble de classes conçues pour travailler avec des méta-boîtes si nous écrivions du code pour elles de manière réutilisable ? Compte tenu de ce que nous savons des méta-boîtes, nous savons que nous aurons probablement besoin des éléments suivants :
- une classe abstraite qui définit le type de publication auquel chaque méta-boîte sera liée,
- deux fonctions pour la boîte méta – une pour l’enregistrer, une pour afficher le contenu,
- un répertoire pour contenir la vue ou la présentation de la meta box,
- un fichier qui servira de ladite vue.
Compte tenu des points ci-dessus, peut-être que la structure du répertoire ressemblerait à ceci :
Ensuite, nous avons un code qui reflète cette structure. Autrement dit, dans notre répertoire WordPress, nous aurions le sous-répertoire Admin puisque la boîte méta est affichée dans la zone d’administration de WordPress, et nous aurions le sous-répertoire View qui contiendrait le fichier responsable de l’affichage des informations.
Cela nous oblige à créer quelques classes comme indiqué ci-dessus. Peut-être que la classe de base abstraite ressemblerait à ceci :
<?php
namespace AcmeWordPressAdminMetaBox;
abstract class AbstractMetaBox
{
protected $postType;
public function __construct()
{
$this->postType = 'acme_post_type';
}
abstract public function render();
abstract public function display();
}
Ensuite, une implémentation concrète étendrait la classe et ressemblerait à ceci :
<?php
namespace AcmeWordPressAdminMetaBox;
class AcmeMetaBox extends AbstractMetaBox
{
/**
* {@inheritdoc}
*/
public function render()
{
add_meta_box(
'acme-product-image',
'Product Image',
[$this, 'display'],
$this->postType,
'side',
'default'
);
}
/**
* {@inheritdoc}
*/
public function display()
{
include_once plugin_dir_path(__FILE__).'Views/acme-product-image.php';
}
}
Et enfin, la vue de la classe contiendrait tout code de balisage et de modèle pour le rendu des informations :
<div class="product-image-metabox">
<p>
<img src="<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>" alt="<?= esc_attr(get_the_title()); ?>" />
<input type="text" value="<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>" />
</p>
</div>Cela nous donne exactement ce dont nous avons besoin d’une manière bien organisée et réutilisable pour travailler avec les méta-boîtes. Il peut également être répété pour des éléments tels que les menus, les types de publication, les taxonomies, etc.
Mais je m’égare.
Un mot sur les tests unitaires (avec PHPUnit)
Comme je l’ai mentionné plus tôt dans l’article, je pense que les classes de tests unitaires qui résolvent des problèmes propres à notre espace de problèmes sont importantes. Cela signifie que vous devez indiquer à votre fichier de configuration PHPUnit d’exclure vos fichiers centrés sur WordPress.
L’avantage de ce que j’ai exposé ci-dessus est que cela devient trivialement facile. En termes simples, vous pouvez ajouter ceci à votre fichier phpunit.xml :
<testsuites>
<testsuite name="Plugin">
<directory>./tests</directory>
<exclude>./tests/phpunit</exclude>
<exclude>./src/WordPress</exclude>
</testsuite>
</testsuites>Cela vous donne la possibilité de vous concentrer sur l’écriture de tests spécifiquement pour votre espace de problèmes tout en vous assurant que vous écrivez un code basé sur WordPress évolutif, maintenable et réutilisable.
J’écris actuellement un livre électronique (avec une variété d’autres contenus premium). Si vous êtes intéressé, regardez ce que vous obtenez.