WordPress hooks expliqués aux DSI qui migrent vers Drupal

Ce qu'est un hook WordPress — et pourquoi c'est à la fois puissant et fragile

Un hook WordPress est un point d'interception dans le cycle d'exécution du système. Il en existe deux types : les actions (add_action) qui exécutent du code à un moment précis, et les filtres (add_filter) qui modifient une valeur avant qu'elle soit utilisée.

Ce modèle est simple à prendre en main — et c'est précisément ce qui en fait un point de fragilité à l'échelle. Dans un projet WordPress mûr, des dizaines de hooks coexistent dans le thème, les plugins actifs et le code sur mesure. Leur ordre d'exécution dépend d'un paramètre de priorité. Personne ne documente les interactions. Et quand un plugin est mis à jour, une chaîne de hooks change silencieusement.

Le diagnostic pour le DSI : si votre site WordPress comporte de la logique métier distribuée dans des hooks, cette logique est probablement non testée, non documentée, et non isolée. C'est le premier risque à évaluer avant de parler de migration.

Ce que Drupal utilise à la place

Drupal a conservé les hooks — mais il a aussi construit, depuis Drupal 8, une architecture orientée services qui répond aux mêmes besoins avec plus de structure.

Les hooks Drupal : familiers, mais encadrés

Drupal dispose de ses propres hooks (hook_node_presave(), hook_form_alter(), etc.). La différence structurante : un hook Drupal appartient à un module, pas à un thème ou à un plugin sans périmètre défini. Un module a un répertoire, une feuille de route, des tests.

Le système d'événements

Drupal 8 a introduit le composant Symfony EventDispatcher. Là où WordPress utilise un hook pour signaler qu'un nœud vient d'être sauvegardé, Drupal peut émettre un événement. D'autres parties du système s'y abonnent via des EventSubscribers — avec deux avantages concrets : la lisibilité (les abonnés sont déclarés dans un fichier de services) et la testabilité (on peut tester un EventSubscriber seul, sans démarrer Drupal entier).

Les services Drupal

Le cœur de l'architecture Drupal 8+ repose sur le conteneur de services Symfony. Une logique métier qui, sous WordPress, aurait été glissée dans un hook peut être encapsulée dans un service — une classe PHP avec une interface explicite, injectée là où elle est nécessaire. Testable indépendamment, versionnée, remplaçable.

Les anti-patrons à éviter

Transposer les hooks WordPress en hooks Drupal, un à un

C'est la migration la plus rapide à décrire — et la plus risquée à exécuter. Les hooks Drupal ne correspondent pas aux hooks WordPress de manière bijective. Les points d'interception ne sont pas aux mêmes endroits dans le cycle d'exécution. Une migration mécanique produit un code qui « tourne » mais qui se comporte différemment.

Concentrer toute la logique dans un seul module custom

L'équivalent WordPress du plugin fourre-tout est le module custom sans découpage. La règle : un module par domaine fonctionnel. Chaque module a ses tests, sa documentation, sa responsabilité.

Ignorer la couche de configuration

WordPress stocke les paramètres dans wp_options. Drupal dispose d'un système de configuration structuré, versionnable, exportable en YAML. Migrer de la logique conditionelle sans la transposer dans ce système, c'est perdre la traçabilité et l'auditabilité que les DSI réclament.

Ce que ça change sur la maintenabilité et les tests

Un EventSubscriber correctement écrit peut être testé en isolation : PHPUnit, données mockées, aucune base de données nécessaire. Cette testabilité transforme la maintenance : les évolutions futures peuvent être vérifiées avant déploiement, pas découvertes en production.

Le signal à surveiller : si l'équipe produit des hooks Drupal sans service associé et sans test unitaire, elle reproduit le pattern WordPress, pas l'architecture Drupal.

Structurer le backlog de migration

• Inventaire des hooks WordPress actifs : combien, où, lesquels sont en code sur mesure ?
• Classification par complexité métier : distinguer la logique de présentation de la logique métier.
• Identification des équivalents Drupal : hook natif, EventSubscriber, service ou plugin ? Décision documentée, pas laissée à chaque développeur.
• Définition de la stratégie de test : les règles métier critiques doivent avoir des tests avant la migration, pas après.

Drupal comme architecture de long terme

Ce qui distingue Drupal de WordPress pour les organisations à métier complexe, c'est la structure qui permet à l'équipe technique de maîtriser ce qu'elle livre, de tester ce qu'elle change, et de faire évoluer le système sans en perdre le contrôle. La migration ne se résume pas à un transfert de contenu et de fonctionnalités — c'est une réécriture d'architecture.