Les bases des crochets d’action dans WordPress

Chaque fois que vous commencez à vous lancer dans une programmation plus avancée – que ce soit dans WordPress ou dans tout autre framework, bibliothèque, fondation ou langage de programmation – il y a des moments où de nouveaux concepts peuvent souvent être plus difficiles à comprendre que d’autres.

J’ai généralement constaté que cela était vrai chaque fois qu’une personne a appris les bases de, disons, la programmation orientée objet mais n’a pas été exposée aux nuances de certaines choses telles que les modèles de conception.

Exemple: j’ai écrit sur le modèle de conception piloté par les événements (ou la publication-abonnement ou Pub/Sub comme certains aiment l’appeler) dans d’autres articles.

Oui, il y a des différences pour chacun, mais l’idée générale est que quelque chose se passe et qu’un événement est déclenché et que tout ce qui écoute cet événement ou s’y abonné répondra.

Photo de Claus Grünstäudl sur Unsplash

C’est le modèle principal utilisé par WordPress qui nous permet de nous accrocher littéralement à certains points d’exécution. Nous pouvons généralement les conceptualiser comme des crochets d’action dans WordPress.

Quoi qu’il en soit, l’application met certains points à notre disposition pour ajouter nos propres fonctionnalités. Une fois cette fonctionnalité enregistrée, WordPress quittera sa base de code, pour ainsi dire, sautera dans la nôtre, puis reviendra à la nôtre.

C’est assez facile à comprendre, mais que se passe-t-il si vous voulez exposer des zones de votre code qui permettent à d’autres de s’y accrocher ?

Crochets d’action dans WordPress

Avant de voir comment WordPress implémente ces modèles, il est important de comprendre les bases de ce modèle. Bien que ce ne soit en aucun cas exhaustif, il est destiné à aider à donner une compréhension fondamentale du modèle afin qu’il soit possible de lire et d’écrire du code centré sur WordPress.

Alors, quelle est une bonne façon de penser au modèle Pub/Sub ? Wikipédia le définit ainsi :

Dans l’architecture logicielle, la publication-abonnement est un modèle de messagerie dans lequel les expéditeurs de messages, appelés éditeurs, ne programment pas les messages à envoyer directement à des destinataires spécifiques, appelés abonnés, mais classent plutôt les messages publiés dans des classes sans savoir quels abonnés, le cas échéant., il peut y avoir. De même, les abonnés expriment leur intérêt pour une ou plusieurs classes et ne reçoivent que les messages qui les intéressent, sans savoir quels éditeurs, s’il y en a.

Comprendre le modèle

Cela pourrait être beaucoup à prendre au début. Je ne sais pas, mais décomposons-le:

1. Il existe un service, dans notre cas étant WordPress, qui est chargé de publier des messages à l’attention de celui qui s’abonne (il ne sait pas nécessairement qui écoute).
2. Lorsqu’un abonné écoute, il entreprendra alors une action chaque fois qu’il entendra cette action.
3. Une fois l’exécution du code de l’abonné terminée, le programme reviendra ensuite au point d’exécution d’origine (qui est l’endroit où l’éditeur a envoyé le message).

Il y a des nuances à cela, comme la fonctionnalité asynchrone et des choses comme ça, mais c’est plus avancé que ce que je préférerais obtenir dans ce post particulier. Après tout, le but est de jeter les bases de la compréhension et de la mise en œuvre des fonctionnalités.

La fonctionnalité asynchrone peut entrer dans le threading ou Ajax et à travers ce sont des sujets importants, ce n’est pas ce post.

À quoi cela ressemble-t-il dans WordPress ?

La façon la plus simple de décrire ce modèle particulier dans WordPress consiste peut-être à utiliser les appels de fonction :

• faire_action
• add_action

Parfois, la nomenclature peut prêter à confusion mais en termes simples, do_action publie et un événement et add_action abonnés à un événement. Ou peut-être une meilleure façon d’y penser est:

do_action indique à WordPress d’effectuer toutes les actions ajoutées.

Parfois, avoir des phrases simples pour se rappeler comment les choses fonctionnent est utile. Je ne sais pas si ce qui précède est la phrase la plus accrocheuse ou la plus mémorable, mais c’est quelque chose, non ?

De plus, notez que do_action et add_action sont des éléments essentiels de WordPress et sont également disponibles pour notre développement. Avant d’aller plus loin, regardons ce que chacun signifie :

Pour do_action :

Cette fonction invoque toutes les fonctions attachées à l’action hook $tag. Il est possible de créer de nouveaux crochets d’action en appelant simplement cette fonction, en spécifiant le nom du nouveau crochet à l’aide du $tagparamètre.

Ou encore plus simplement :

Exécutez des fonctions accrochées à un hook d’action spécifique.

Lorsque vous faites référence à des crochets, il peut s’agir de crochets définis par WordPress ou de crochets personnalisés que vous spécifiez dans votre thème ou votre plugin.

Quant à add_action :

Les actions sont les crochets que le noyau de WordPress lance à des moments spécifiques lors de l’exécution, ou lorsque des événements spécifiques se produisent. Les plugins peuvent spécifier qu’une ou plusieurs de ses fonctions PHP sont exécutées à ces points, à l’aide de l’API d’action.

Et, de même, plus simplement :

Accroche une fonction à une action spécifique.

Le réglage de ceci est pratiquement un peu différent car nous utilisons généralement add_action pour ajouter notre propre code à WordPress.

Un exemple pratique

Par exemple, vous avez peut-être écrit quelque chose comme ceci :

<?php
add_action('wp_insert_post_data', __NAMESPACE__. 'processPermalink');
/**
 * Processes the permalink so we can remove any characters that may cause a problem when communicating
 * with the API.
 *
 * @param  array $data The array of information about the post.
 * @return array $data The data without the malformed information in the post name for the URL.
 */
public function processPermalink($data)
{
    if (!in_array($data['post_status'], array('draft', 'pending', 'auto-draft'))) {
        $data['post_name'] =
            preg_replace(
                '/(%ef%b8%8f|™|®|©|™|®|©|™|®|©)/',
                '',
                $data['post_name']
            );
    }
    return $data;
}

Dans ce cas, quelque part dans la base de code WordPress, il y a un appel do_action pour le crochet wp_insert_post_data et il accepte une fonction et lui transmettra au moins un seul paramètre.

Ajouter vos propres crochets

Mais que se passe-t-il si vous voulez donner à d’autres développeurs la possibilité de s’accrocher à votre plugin ou à votre thème? Dans ce cas, vous devriez vous préoccuper de l’utilisation de do_action et la page liée plus haut dans ce document fournit tout ce dont vous avez besoin pour le configurer.

C’est en fait beaucoup plus simple, à mon avis, que de travailler avec add_action car add_action permet non seulement de se connecter à un éditeur existant, mais aussi d’ajouter notre propre logique personnalisée.

do_action en revanche nécessite que nous fournissions un nom de la fonction à exécuter puis la liste des arguments à passer à la fonction qui sera exécutée.

C’est ça?

En termes aussi simples que possible, oui. Il y a quelques nuances autour de la priorité, du nombre d’arguments et de l’utilisation des espaces de noms et de la programmation orientée objet. Mais, encore une fois, cela sort du cadre de cet article particulier. Peut-être que j’y reviendrai plus en profondeur dans un autre article.

Pour l’instant, cependant, si vous n’êtes pas familier avec les bases de :

• le modèle Pub/Sub,
• faire_action,
• et add_action

Vous êtes maintenant suffisamment à l’aise pour lire le code avec lequel vous travaillez, comprendre comment le code fonctionne et même implémenter vos propres solutions si nécessaire.

J’écris actuellement un livre électronique (avec une variété d’autres contenus premium). Si vous êtes intéressé, regardez ce que vous obtenez.