« Insérer un script juste après l’ouverture du <body> » est une demande fréquente, mais elle se heurte souvent à une méconnaissance de ce qui se passe réellement entre l’appel à get_header() et le rendu final de la page. Deux hooks structurent l’essentiel de cette mécanique : wp_head et wp_footer.
Contrairement à une idée répandue, ces deux hooks ne sont pas de simples emplacements vides que le développeur remplit à sa guise. WordPress y accroche par défaut une série d’actions internes, avec des priorités précises, et comprendre cet ordre évite bien des scripts qui s’exécutent trop tôt ou trop tard.
Ce que wp_head exécute par défaut
Sur un thème classique fraîchement installé, une bonne dizaine de fonctions sont accrochées à wp_head avec des priorités qui vont de 1 à 99. Voici les principales, dans l’ordre où elles s’exécutent réellement :
| Priorité | Fonction accrochée | Rôle |
|---|---|---|
| 1 | wp_enqueue_scripts (action liée) | Déclenche l’enregistrement des styles et scripts |
| 2 | rsd_link | Balise de découverte pour l’API XML-RPC |
| 3 | wlwmanifest_link | Manifeste pour Windows Live Writer, vestige historique |
| 10 | wp_generator | Balise meta indiquant la version de WordPress |
| 20 | rel_canonical | Balise de lien canonique sur les pages singulières |
Un thème qui appelle simplement wp_head() déclenche donc l’exécution ordonnée de toutes ces fonctions, avant que le code personnalisé accroché par le développeur ne s’exécute à son tour, selon la priorité qu’il aura choisie.
Insérer son propre code au bon endroit
Pour ajouter une balise juste avant la fermeture de <head>, il suffit de s’accrocher au même hook avec une priorité élevée, ce qui garantit une exécution après les fonctions natives.
function monthème_meta_supplementaire() {
echo '<meta name="theme-color" content="#1a1a2e">' . "\n";
}
add_action( 'wp_head', 'monthème_meta_supplementaire', 99 );
À l’inverse, pour un script qui doit s’exécuter avant même la génération des styles enregistrés (cas rare, souvent pour définir une variable globale JavaScript lue ensuite par un autre script), une priorité basse comme 1 ou 2 convient.
Le rôle particulier de wp_footer
À l’opposé du document, wp_footer sert de point d’ancrage standard pour tout ce qui n’a pas besoin d’être chargé avant l’affichage du contenu : scripts de suivi, widgets tiers, scripts interactifs non bloquants. Par défaut, ce hook n’accroche qu’une poignée de fonctions internes, notamment celles liées à l’administration quand l’utilisateur est connecté (barre d’admin, styles associés).
- Placer les scripts non critiques dans
wp_footerplutôt quewp_headréduit le temps de blocage du rendu initial. - Les scripts enregistrés via
wp_enqueue_script()avec l’argumenttrueen dernier paramètre s’impriment automatiquement à cet endroit. - Un script inséré directement en dur dans
footer.php, avant l’appel àwp_footer(), s’exécute avant les scripts enregistrés par les extensions.
Un ordre qui dépend aussi des extensions actives
Ce qu’un thème contrôle, c’est sa propre priorité sur ces hooks. Ce qu’il ne contrôle pas, c’est ce que les extensions actives y accrochent également. Un plugin de statistiques, un plugin de consentement aux cookies ou une extension de cache peuvent tous ajouter des fonctions sur wp_head ou wp_footer, avec leurs propres priorités, parfois en conflit avec celles du thème.
Avant de chercher pourquoi un script s’exécute dans le mauvais ordre, il vaut mieux lister concrètement, via un outil de débogage, l’ensemble des fonctions accrochées à ces deux hooks sur le site concerné, plutôt que de supposer leur comportement par défaut.
En résumé
Maîtriser l’ordre réel des actions accrochées à wp_head et wp_footer évite de deviner par tâtonnement où placer un script. La priorité passée à add_action() reste l’outil principal pour se positionner précisément avant ou après les fonctions natives, à condition de connaître d’abord ce qui s’exécute déjà à cet endroit.
