Utilisation d’un registre, d’abonnés et de services dans WordPress

TL; DR : Je trouve l’utilisation d’un registre, d’abonnés et de services très utile lors de la création de plugins et d’utilitaires centrés sur le backend pour WordPress. Cet article explique comment procéder.

Après avoir travaillé avec des modèles de conception, la programmation orientée objet et WordPress pendant des années, des moyens courants de résoudre les problèmes sont inévitables.

C’est ainsi que nous avons commencé par créer des modèles de conception orientés objet, alors il s’agit peut-être d’une variante centrée sur WordPress.

Bien que j’aie écrit sur des choses telles que les registres dans des articles précédents (et ceux qui ne sont même pas si anciens ), ce n’est jamais une mauvaise idée de revenir sur le même sujet, surtout quand il y a quelque chose à ajouter à la prise précédente.

Un registre, des abonnés et des services

Tout ce qui est décrit ci-dessous doit être compris dans le contexte du plugin WordPress. Autrement dit, ceci n’est pas destiné à être lu comme un moyen de travailler avec d’autres frameworks, langages, applications ou lors de son utilisation avec d’autres modèles.

N’oubliez pas que lorsque vous lisez ceci.

Quoi qu’il en soit, l’idée générale derrière la combinaison de ces types d’objets est la suivante :

1. Le registre gère tous les abonnés,
2. Les abonnés écoutent les crochets au sein de WordPress (ceux qui existent ou même les crochets personnalisés),
3. Les services effectuent le travail réel chaque fois que l’abonné les envoie.

Le but étant qu’il y ait un seul endroit pour enregistrer les classes chargées de répartir le travail. C’est ça.

De plus, cela facilite également la séparation des choses, de sorte que si vous souhaitez tester vos services de manière isolée, c’est beaucoup plus facile car ils ne sont pas nécessairement étroitement couplés à WordPress. Et si c’est le cas, vous pouvez vous moquer des données qui doivent être transmises à une fonction donnée, puis évaluer le résultat.

Ceci n’est pas un article sur les tests, cependant, revenons aux classes réelles.

Enregistrement

Par définition, le but d’un registre est de garder une trace des choses. Lorsqu’il s’agit d’implémenter ce modèle dans WordPress, l’idée est que le registre peut suivre les abonnés (ce que je définirai plus loin dans cet article).

Photo de Denny Müller sur Unsplash

De plus, l’idée est que le moment venu, ce qui sera probablement différent selon la structure de votre plugin, tous les abonnés seront instanciés. À ce stade, cependant, vous voudrez probablement le faire tôt dans le cycle de vie de WordPress.

Cela dit, voici un exemple de comment utiliser le code pour enregistrer les abonnés :

private $subscribers = [
    AssetSubscriber::class,
    // ...
    DeletedUserSubscriber::class,
];

Ensuite, voici une fonction pour instancier les abonnés.

Ces blocs peuvent faire partie de la même fonction ou ils peuvent être séparés selon vos besoins.

Les abonnés

Comme mentionné, les abonnés sont le moyen de :

1. Écoutez un certain crochet dans WordPress
2. Envoyez un service pour effectuer le travail prévu pour le crochet donné.

Supposons donc un instant que vous vouliez faire quelque chose chaque fois qu’un utilisateur est supprimé. Vous souhaitez instancier un service via l’abonné chaque fois que ce crochet se produit.

Photo de Lee Campbell sur Unsplash

Par exemple:

Notez que l’abonné est au courant du service (bien qu’il n’en dépende pas car il s’agit simplement d’un intermédiaire entre WordPress et le service) et spécifie le crochet sur le service qu’il instancie.

Prestations de service

Enfin, les services sont les objets qui font tout le gros du travail dans un plugin. Cela signifie que s’ils ont besoin de lire ou d’écrire dans la base de données, le système de fichiers, le réseau, les données de processus, etc., tout se passe dans leur contexte.

Photo par Erik Mclean sur Unsplash

Ils peuvent être au courant d’autres classes, ils peuvent ne pas l’être. Ils peuvent implémenter une interface ou une classe abstraite ou non. C’est vraiment au-delà de la portée de ce post. Mais le fait est que, en utilisant le crochet ci-dessus comme exemple, si vous voulez faire quelque chose lorsqu’un utilisateur est supprimé, vous le faites dans le service.

Par exemple:

class DeletedUserService
{
    public function add(string $hook)
    {
        add_action($hook, [$this, 'deletedUser'], 99, 1);
    }

    public function deletedUser(int $userId)
    {
        $user = get_userdata($userId);
        if (false === $user) {
            return;
        }

        // Do work with the user that's being deleted.   
    }
}

Et c’est la fin. Une fois le service exécuté, le contrôle sera rendu à WordPress et l’application poursuivra son exécution normalement.

Tous ensemble maintenant

En supposant que vous ayez un fichier d’amorçage pour votre plug-in, ce qui est le cas pour la plupart, car c’est là que le plug-in requis est défini, un chargeur automatique est requis et l’instanciation du plug-in lui-même se produit.