Un plugin, ou « intercepteur » en français, dans Magento 2 est un composant de personnalisation essentiel qui permet aux développeurs d’étendre et de modifier le comportement des méthodes publiques d’une classe sans avoir à modifier directement le code source de cette classe. En d’autres termes, un plugin agit comme une sorte d’intermédiaire qui peut intercepter et modifier les appels de méthodes sans altérer le code source de la classe originale.
Les plugins peuvent être configurés pour s’exécuter avant, après, ou autour de l’exécution d’une méthode existante, ce qui offre un haut degré de flexibilité pour modifier le comportement de Magento sans toucher au code principal. Ils sont un élément clé de l’architecture de Magento 2, permettant aux développeurs de personnaliser la plateforme de manière propre et structurée.
1. Quand tu tombes dedans pour la première fois
Plugin et observer, observer et plugin, ca se ressemble un peu, ca fait des trucs que l’on pourrait croire similaire mais en fait ca n’a pas tout à fait le meme usage ! Mais ne casse pas ton clavier tout de suite, à la fin de cet article t’y verras déjà bien plus clair !
En fait tous les deux interviennent pour modifier un comportement, c’est d’ailleurs pour ca qu’on pourrait les confondre : ils font à première vue la meme chose : écouter un comportement natif et ajouter ton code, et pourtant !
En fait c’est la logique derrière qui est différente : un plugin se branche sur une méthode alors qu’un observer intervient sur un événement.
Normalement à ce stade tu y vois un peu plus clair mais on va aller un peu plus loin parce que ce que tu veux savoir, c’est dans quel cas utiliser l’un ou l’autre ?
2. Observer : le classique du publish-subscribe
L’observer se base sur les évènements dispatchés par Magento (tu peux également créer tes propres events mais on verra ca dans un autre article).
Dans un observer, on ne modifie pas le comportement, on ajoute simplement des traitements en parallèle.
Prenons un exemple concret :
On te demande de développer un module qui va venir, de manière automatique, attribuer un groupe client pour les nouveaux clients qui ont un email en @acme.fr. C’est là que tu vas pouvoir te brancher sur l’event customer_register_success pour venir faire ton traitement d’ajout. Tu n’interfère pas dans le traitement en cours, tu viens simplement rajouter une étape, en gros tu observe et tu agis en fonction.
Pour le mettre en place, c’est simple :
- Tu déclare ton l’événement Tu crées un fichier
etc/events.xmldans ton module, et tu te branches surcustomer_register_success. - Tu crée ta classe observer Tu implémentes
\\Magento\\Framework\\Event\\ObserverInterface. C’est dans la méthodeexecute()que tu vas écrire ta logique pour changer le groupe client. - Tu récupère les données et tu fais ton traitement Tu reçois un objet
Observer $observer. À partir de là, tu récupères ce qu’il te faut avec$observer->getData()ou, plus souvent dans ce cas,$observer->getCustomer().
3. Plugin : l’art d’intercepter une méthode
Le plugin, lui, ne se branche pas sur un événement. Il s’intercale directement dans l’exécution d’une méthode d’une classe Magento. En gros, tu viens dire : « avant que cette méthode se lance, j’aimerais faire un truc », ou « une fois qu’elle est finie, je veux modifier le résultat », ou carrément : « je prends la main sur tout ».
Il existe trois types de plugins dans Magento :
before→ ton code s’exécute avant la méthode, tu peux modifier les arguments.after→ ton code s’exécute après, tu peux modifier la valeur retournée.around→ tu contrôles toute l’exécution, et tu choisis si tu appelles ou non la méthode d’origine.
Prenons un exemple concret :
Tu veux modifier automatiquement le nom d’un client lorsqu’il est chargé (par exemple pour rajouter un tag [VIP] devant certains noms). Ici, on ne parle plus d’un événement global, mais bien d’une méthode : \\Magento\\Customer\\Api\\Data\\CustomerInterface::getFirstname.
Tu vas donc créer un plugin qui va s’appliquer à cette méthode, et retourner une version modifiée du prénom. Et contrairement à l’observer, tu interviens directement dans le flux d’exécution, ce qui te donne beaucoup plus de contrôle… mais aussi plus de responsabilités.
Pour le mettre en place, voici ce que tu dois faire :
- Tu déclare ton plugin dans le
di.xmlTu crées un fichieretc/di.xmlet tu y déclares ton plugin en indiquant :- la classe cible (celle que tu veux intercepter),
- le nom de ta classe plugin,
- le type (
before,after,around).
- Tu crée ta classe plugin Pas d’interface à implémenter ici, tu définis simplement une méthode nommée
afterGetFirstname,beforeSave, ouaroundExecuteselon le cas. Magento l’exécutera automatiquement selon le type de plugin. - Tu appliques ton traitement Tu reçois les arguments (dans
before), le résultat (dansafter), ou un callable (dansaround). C’est à toi de renvoyer les bonnes valeurs ou d’appeler$proceed()si besoin dans le cas d’unaround.
Simple dans le principe, mais puissant. Et comme tu t’insères dans le fonctionnement natif de Magento, il faut être rigoureux : un plugin mal fichu peut vite devenir un cauchemar à maintenir.
4. Observer vs Plugin : qui gagne quand ?
L’observer, c’est un peu le couteau suisse tranquille. Il te permet d’ajouter un comportement sans te soucier du reste. Tu te branches à un moment précis du cycle Magento (un event), tu fais ce que tu as à faire, et tu laisses le système continuer sa vie. Tu ne modifies ni les arguments, ni le résultat d’une méthode. Tu observes, tu agis à côté, et tu ne casses rien. Simple, propre, lisible.
Le plugin, lui, c’est l’outil chirurgical. Tu veux intervenir dans une méthode ? Avant son exécution ? Après ? Ou carrément la remplacer ? C’est pour toi. Mais avec cette puissance vient aussi plus de risques : mauvaise implémentation, empilement de plugins, effets de bord… Tu peux facilement complexifier ton code si tu ne poses pas des limites claires.
En résumé :
- Si tu veux ajouter un traitement parallèle sans toucher au fonctionnement natif → Observer.
- Si tu veux intercepter une méthode précise et modifier ses données, ses arguments, ou son résultat → Plugin.
- Si tu veux bloquer ou rediriger complètement l’exécution d’une méthode → Plugin (around), mais garde en tête que c’est la forme la plus délicate à maintenir.
Il n’y a pas de solution universelle. L’essentiel, c’est de bien comprendre ce que tu veux faire, et de choisir l’approche la plus simple, la plus lisible, et la plus robuste possible. Et si tu hésites ? Commence par un observer. Tu pourras toujours passer à un plugin plus tard si ça ne suffit pas.
5. En conclusion : un petit résumé de tout ca
- Observer : tu regardes ce qui se passe, et tu ajoutes ton grain de sel à côté. Tu ne touches pas au déroulement, tu restes en soutien.
- Plugin : tu mets les mains dans le cambouis. Tu interviens dans une méthode, avant, après, ou à la place. Plus puissant, mais plus risqué. (–> vous pouvez aussi voir la doc officielle)
- En cas de doute, commence toujours par un observer. C’est plus simple, plus lisible, et souvent suffisant.
- Si ton besoin est ultra ciblé, qu’il touche une méthode bien précise, et que tu veux modifier le retour ou les paramètres → plugin, sans hésiter.
- Et surtout : code pour les autres (ou pour toi dans 6 mois). Plus c’est clair, plus c’est sain.
Et si un jour tu regrettes… n’oublie jamais : l’élevage de chèvres dans le Larzac reste une option valable.
