Chapitre 7.2 — Les hooks en pratique

⏱️ TL;DR — Un plugin s’organise autour des hooks (Partie 5). En pratique : on encapsule le plugin dans une classe (ou un namespace) pour éviter les collisions et regrouper la logique, on branche les hooks dans une méthode dédiée, on charge les dépendances proprement, et on choisit le bon hook au bon moment (init pour enregistrer, wp_enqueue_scripts pour les assets, save_post pour réagir à un enregistrement…). Objectif : un plugin lisible, testable et sans effets de bord.

🎯 Objectifs

• Structurer un plugin autour d’une classe principale.
• Brancher les hooks proprement (et pouvoir les retirer).
• Choisir le bon hook selon l’objectif.
• Éviter les pièges (closures non retirables, hook trop tôt/tard, instanciation multiple).

1. Encapsuler dans une classe

Plutôt que des dizaines de fonctions globales préfixées, on regroupe la logique dans une classe (les méthodes évitent les collisions et clarifient l’organisation) :

<?php
// includes/class-wpr-books.php
namespace WPR\Books;
 
if ( ! defined( 'ABSPATH' ) ) { exit; }
 
final class Plugin {
 
    private static ?Plugin $instance = null;
 
    public static function instance(): Plugin {
        if ( null === self::$instance ) {
            self::$instance = new self();
        }
        return self::$instance;
    }
 
    private function __construct() {
        $this->register_hooks();
    }
 
    private function register_hooks(): void {
        add_action( 'init',                array( $this, 'register_content' ) );
        add_action( 'wp_enqueue_scripts',  array( $this, 'enqueue_front' ) );
        add_action( 'save_post_livre',     array( $this, 'on_save_livre' ), 10, 3 );
    }
 
    public function register_content(): void { /* CPT, taxonomies (ch. 7.3) */ }
    public function enqueue_front(): void    { /* assets (ch. 6.4) */ }
    public function on_save_livre( $post_id, $post, $update ): void { /* réagir */ }
}

Dans le fichier principal, on amorce une seule instance :

// wpr-books.php (après l'en-tête)
require_once __DIR__ . '/includes/class-wpr-books.php';
 
add_action( 'plugins_loaded', function () {
    \WPR\Books\Plugin::instance();
} );

⚠️ Piège n°1 — l’instanciation multiple. Sans singleton (ou garde), un plugin instancié plusieurs fois branche ses hooks en double → callbacks exécutés deux fois. Le patron instance() garantit une seule initialisation.

2. Brancher (et pouvoir retirer) les hooks

Utiliser des méthodes (array( $this, 'methode' )) plutôt que des closures permet de retirer un hook si besoin (remove_action avec la même référence) et facilite les tests. Rappel (ch. 5.2) :

add_action( 'save_post_livre', array( $this, 'on_save_livre' ), 10, 3 );
// retrait possible :
remove_action( 'save_post_livre', array( $this, 'on_save_livre' ), 10 );

⚠️ Piège n°2 — la closure non retirable. add_action('init', function(){…}) marche mais est impossible à retirer et dur à tester (pas de référence stable). Préférez des méthodes nommées pour tout hook qu’on pourrait devoir désactiver ou tester.

3. Choisir le bon hook (table de survie)

💡 Pour un dev React — La classe Plugin avec son register_hooks() est votre point de montage : un endroit unique qui déclare tous les abonnements (comme un fichier qui enregistre les listeners/effets au démarrage). Chaque méthode publique = un handler. Cette structure rend le plugin lisible d’un coup d’œil (« que fait ce plugin ? → regardez register_hooks() ») et testable (on appelle les méthodes directement).

4. Charger le code proprement

• Inclusions explicites (require_once) pour un petit plugin, ou un autoloader (Composer PSR-4) pour un gros.
• Charger au bon moment : les classes au chargement du fichier ; l’instanciation sur plugins_loaded (tous les plugins présents) ; l’enregistrement du contenu sur init.
• Éviter le travail lourd au chargement : ne faites pas de requêtes/API à chaque requête HTTP dès l’include. Branchez sur un hook, et mettez en cache (ch. 5.7).

5. Un squelette réutilisable

Le trio fichier principal (amorçage) → classe Plugin (hooks) → classes spécialisées (CPT, meta, admin…) est un squelette réutilisable pour tous vos plugins. On l’étoffe dans les chapitres suivants (CPT, meta, admin, sécurité) et on l’assemble en entier au ch. 7.9 (wpr-books).

📚 Aller plus loin — WP-CLI peut générer ce squelette : wp scaffold plugin wpr-books (ch. 4.3) crée une base avec structure, tests et build. Beaucoup d’équipes partent d’un boilerplate (ex. « WordPress Plugin Boilerplate ») pour standardiser l’organisation.

✏️ Exercices

1. Pourquoi encapsuler un plugin dans une classe (ou un namespace) plutôt qu’en fonctions globales ?
2. Sur quel hook enregistrez-vous un CPT, et sur lequel chargez-vous les CSS du front ?
3. Pourquoi préférer une méthode nommée à une closure pour un callback de hook ?

🧠 Quiz de révision

Chapitre suivant : Custom Post Types & taxonomies.