FR | EN
Introduction
Les hooks sont omniprésents dans WordPress. Au début, à chaque étape, dans les fonctions, autour des données, et jusqu’à la fin du cycle d’exécution. Ils font partie intégrante de l’architecture du CMS. Ils sont des centaines, et de nouveaux apparaissent régulièrement.
Les hooks offrent une flexibilité immense au cœur de WordPress. Et en créant les vôtres, vous donnez à votre propre code cette même capacité d’adaptation.
Un code vivant et pilotable. Un code qui s’adapte au présent et peut même, parfois, changer le futur.
Concept
Un hook (crochet) est un point d’accroche que WordPress met à disposition pour que les développeurs puissent ajouter ou modifier des fonctionnalités sans toucher au cœur du CMS.
Il en existe deux types principaux :
- Actions : pour exécuter du code à un moment précis,
- Filters : pour modifier des données avant qu’elles ne soient utilisées ou affichées.
Les hooks sont comme des points de montage prévus dans le moteur : ils permettent de greffer ses propres pièces sans démonter l’ensemble. Ils permettent donc de brancher son propre code au noyau de WordPress, mais aussi à l’ensemble des extensions et theme qui en proposent.
Ordre
Les hooks s’enchaînent et se succèdent jusqu’au shutdown
.
L’ordre d’exécution a toute son importance. Comprendre cette séquence est essentiel : un add_action()
ou add_filter()
trop tôt ou trop tard, et votre code n’atteindra pas son objectif.
Vous pouvez consulter le référentiel des actions disponibles. La première partie de la page propose un aperçu de la séquence de chargement de muplugins_loaded
à shutdown
. Le même référentiel existe aussi pour les filtres.
Comprendre le chargement du cœur de WordPress – Rarst.net
Contextes
Un même hook peut apparaître dans plusieurs contextes.
Un hook n’est jamais intrinsèquement “trop tôt” ou “trop tard” : sa pertinence dépend uniquement de ce que vous souhaitez accomplir.
Le véritable secret est de toujours se demander : « Dans quel contexte ce hook est-il exécuté ? »
Ainsi, un hook n’est “trop tôt” ou “trop tard” que par rapport à un contexte spécifique, jamais de manière absolue.
Quelques exemples pour illustrer :
after_setup_theme ou template_redirect :
- after_setup_theme se déclenche après le chargement du theme.
Il intervient très tôt, utile si vous voulez enregistrer des fonctionnalités de theme (supports, menus, images, etc.). - template_redirect se déclenche avant de déterminer quel template charger.
Celui-ci ne se déclenche qu’une fois que WordPress a résolu quel template va être utilisé : c’est le moment idéal pour rediriger un utilisateur avant l’affichage. - Ici donc, utiliser template_redirect pour enregistrer un support de theme serait “trop tard”, et utiliser after_setup_theme pour rediriger serait “trop tôt”. La main query ne serait pas encore exécutée.
admin_init :
- admin_init se déclenche lors de l’initialisation d’une page d’administration ou d’un script.
- Cela signifie que ce même hook est partagé par plusieurs contextes (toutes les pages de l’admin).
- Si vous voulez cibler uniquement une page particulière (par ex. la page d’options d’un plugin), vous devez ajouter un test de contexte.
- Ici, le hook n’est pas “trop tôt” ni “trop tard” en soi : il est simplement partagé par tous les écrans, et c’est à vous de valider le contexte.
pre_get_posts :
- Le hook pre_get_posts se déclenche avant l’exécution de chaque requête
WP_Query
. - Ce hook est implémenté dans la méthode
get_posts()
de la classeWP_Query
.
Il est donc exécuté à chaque exécution de cette méthode, c’est-à-dire à chaque récupération de posts viaWP_Query
. - Cela inclut la requête principale (main query), mais aussi toutes les requêtes secondaires qui peuvent être générées par des widgets, des menus ou des appels à
WP_Query
. Si vous souhaitez manipuler uniquement la requête principale, il est indispensable de tester le contexte (via is_main_query(), notamment).
Timing
Pour utiliser un hook, il est indispensable d’attacher votre callback à un hook avant son exécution bien sûr. Sinon, cela ne peut pas fonctionner, vous vous en doutez bien. Autrement dit, tant qu’un hook n’a pas encore été exécuté, vous pouvez toujours vous y accrocher ou préparer une intervention sur le suivant.
Vous pouvez donc vous appuyer sur un hook pour vérifier une donnée ou un contexte et envisager des actions futures sur les hooks à venir.
Il est possible d’enregistrer un callback de manière dynamique, à la volée, avant l’exécution du hook cible, en tenant compte du contexte et en choisissant le moment opportun.
Maîtriser le moment d’attachement, c’est maîtriser le flux et les comportements.
Bifurcations
Un hook est une occasion de modifier ou d’enrichir une donnée avant son utilisation : la réécrire, la détourner ou l’adapter selon le contexte, l’utilisateur ou le moment. C’est une passerelle entre ce qui aurait dû être… et ce qui sera.
Chaque do_action()
ou apply_filters()
est un point clé sur la timeline de WordPress : comprendre ces hooks, c’est savoir quand et comment agir pour faire évoluer le flux des données.
Attacher un comportement, injecter une logique, modifier une valeur : maîtriser les hooks, c’est le pouvoir de changer le futur de votre application.
Laisser un commentaire