Organisation des types, des vues et des abonnés WordPress
L’une des choses que j’essaie de faire régulièrement est de rationaliser la façon dont je construis des fonctionnalités axées sur WordPress. J’en ai récemment parlé, mais j’ai pensé que je développerais un peu plus.
Autrement dit, j’ai pensé que j’exposerais l’approche que j’adopte lors de la création d’éléments tels que les types de publication personnalisés, les taxonomies, les méta-boîtes, etc.
En règle générale, considérez cela comme une stratégie que je suis pour développer des aspects d’un projet qui s’interface directement avec WordPress mais qui peut nécessiter quelques composants tels que :
- des classes qui s’enregistrent auprès de WordPress via divers hooks,
- classes qui nécessitent des appels à certaines API WordPress
- et les classes qui nécessitent une vue personnalisée.
Bien sûr, tout ce qui s’interface avec WordPress n’aura pas besoin de tout ce qui précède (par exemple, un type de publication personnalisé a-t-il besoin d’une vue? Non. Mais une méta-boîte en a besoin.)
Organisation des types WordPress
Cela dit, je vais prendre un exemple plus complexe tel qu’une méta-boîte, puis décomposer une manière dont je pense qu’elle peut être implémentée. Je vais noter les choses que je pense nécessaires et les choses qui sont facultatives.
Et, comme je l’ai dit, j’utilise une méta-boîte comme exemple parce que j’ai une référence précédente et cela implique le plus de travail alors qu’autre chose comme une taxonomie personnalisée peut ne pas nécessiter tout (juste un sous-ensemble) des pièces .
Cela dit, permettez-moi d’exposer mon approche.
Nous avons besoin d’abonnés
J’ai suffisamment parlé de ce modèle particulier à un point où je vais simplement faire un lien vers une définition de celui-ci. Si vous lisez cette page, vous connaissez probablement bien les différents crochets et comment les utiliser dans WordPress.
Photo par Alexander Andrews sur Unsplash
Mais la raison pour laquelle je veux le mentionner est que plutôt que de penser à connecter une fonction pour qu’elle se déclenche chaque fois que quelque chose se produit, je veux que vous pensiez à un objet qui s’abonne à un événement lorsqu’il se produit.
Cela signifie que nous aurons besoin d’un type de classe d’abonnés.
Cours d’API WordPress
Deuxièmement, nous avons besoin de classes qui se chargent de s’interfacer directement avec WordPress. Ce sont les classes qui appellent l’API WordPress et enregistrent tout ce dont elles sont responsables.
C’est-à-dire qu’ils vont peut-être définir un type de publication personnalisé ou peut-être, comme indiqué, ils vont définir une méta-boîte.
Définition des vues
Enfin, il est important de noter que pour certaines fonctionnalités personnalisées de la zone d’administration de WordPress (ou même des zones publiques), vous pouvez inclure une vue ou un modèle ou une partie (je les appelle généralement vues) qui travail pour représenter les données d’une méta-boîte.
Photo de Saketh Garuda sur Unsplash
Parfois, ce sera simplement informatif. Parfois, cela nécessitera qu’il republie sur le serveur et sérialise les données. Bien que je pense que parler de ce dernier serait vraiment bénéfique, cela sort du cadre actuel de cet article.
Peut-être dans un prochain billet.
Organisation des cours
Qu’est-ce que tout cela a dit, à quoi cela ressemblerait-il d’exposer tout cela ? À tout le moins, nous examinons :
- un abonné,
- un type WordPress,
- une vue
Et, tout au plus, vous pourriez être intéressé par la définition d’interfaces ou de classes abstraites pour aider à faire respecter un contrat entre les différents types de WordPress. C’est aussi un principe orienté objet sain dont je parlerai dans un prochain article.
Pour l’instant, cependant, parlons de la façon de configurer chacun d’entre eux.
L’abonné
En termes simples, l’abonné est responsable d’écouter chaque fois que WordPress déclenche un événement (publie un événement). Et quand il s’en aperçoit, il déclenche une fonction qui lui est liée.
Ceci est généralement défini dans le modèle de registre. Si vous n’avez pas lu cet article, je le recommande, mais la configuration du code est assez simple :
<?php
class AcmeMetaBoxSubscriber extends AbstractSubscriber
{
public function __construct(string $hook)
{
parent::__construct($hook);
}
public function load()
{
(new AcmeMetaBox())->render();
}
}
À partir de là, chaque fois que l’événement est déclenché, la fonction se déclenche. Voici le problème: la fonction doit faire partie d’une certaine classe. Ainsi, la nécessité du type WordPress
Le type WordPress
J’aime considérer les types de choses qui s’interfacent avec WordPress comme des types WordPress (tout comme nos langages de programmation ont des types natifs tels que des chaînes et des entiers). WordPress a des taxonomies, des méta-boîtes, des menus, etc.
Pour que notre abonné fonctionne correctement, il doit être mis au courant de notre type de WordPress. Conformément à l’exemple de la boîte de méta, voici à quoi cela peut ressembler :
<?php
class AcmeMetaBox extends AbstractMetaBox
{
public function render()
{
add_meta_box(
'acme-data',
'Acme Data',
[$this, 'display'],
$this->postType,
'normal',
'high'
);
}
public function display()
{
include_once plugin_dir_path(__FILE__).'Views/acme-data.php';
}
}
Ensuite, nous devons nous assurer que le registre est conscient de cette classe.
La vue
Enfin, pour une boîte méta, nous devons nous assurer qu’il existe une vue qui affichera au moins des informations. La sérialisation des informations, puis la mise à jour de la vue pour l’utilisateur est un peu différente.
Mais à quoi pourrait ressembler une vue? Facile :
<div class="acme-data-metabox">
<?php echo __('Acme Data', 'acme-meta-box'); ?>
<p class="description">
This is the content of the metabox.
</p>
</div>C’est juste un balisage de base qui rend les informations à l’utilisateur.
Tout lier ensemble
Chaque fois que je mets tout cela ensemble, j’ai généralement une classe de plugin qui démarre tout. Si un projet est volumineux, il peut y en avoir plusieurs, mais dans ce cas, je pense qu’il est acceptable de montrer à quoi il ressemble en utilisant une seule classe.
Donc, tout d’abord, la classe principale du plugin ressemble à ceci :
<?php
class Plugin
{
private $registry;
public function __construct(Registry $registry)
{
$this->registry = $registry;
}
public function start()
{
array_map(function ($subscriber) {
add_action($subscriber->getHook(), [$subscriber, 'load']);
}, $this->registry->getRegisteredSubscribers());
}
}
Et le bootstrap du plugin ressemble à ceci :
<?php
// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('acmeApiRegistry', function() use ($registry) {
return $registry;
});
// Register all of our objects with a basic registry.
$registry->add('acmeMetaBoxSubscriber', new AcmeMetaBoxSubscriber('add_meta_boxes'));
$plugin = new Plugin($registry);
$plugin->start();Et, à partir de là, tout le reste est mis en mouvement.
Qu’en est-il des fonctionnalités plus avancées ?
Je soulève cette question car j’en ai déjà parlé un peu plus tôt dans le post. A savoir, j’ai parlé de :
- l’idée de poster des données sur le serveur (et probablement de les relire),
- et j’ai parlé de l’utilisation des interfaces.
Ce sont deux choses qui, je pense, méritent d’être explorées plus en détail. Mais avant de faire cela, jeter les bases de la façon dont j’organise ces informations est qu’elles sont construites d’autant plus qu’elles s’appuient sur des publications précédentes telles que le modèle de registre et l’organisation de classes centrées sur WordPress via des méta-boîtes également.