Insérer directement une balise <script> dans un gabarit fonctionne, mais expose à charger deux fois le même fichier si une autre extension fait la même chose, ou à casser l’ordre attendu entre bibliothèques. WordPress propose donc une file d’attente centralisée que chaque composant alimente sans connaître les autres.
Les fonctions à utiliser
On enregistre puis on ajoute un fichier à la file avec wp_enqueue_script() pour le JavaScript et wp_enqueue_style() pour le CSS, toujours accrochées au bon hook selon le contexte d’affichage :
add_action( 'wp_enqueue_scripts', function () {
wp_enqueue_style(
'mon-style',
plugins_url( 'css/style.css', __FILE__ ),
array(),
'1.0.0'
);
} );Le hook diffère selon le contexte : wp_enqueue_scripts pour le site public, admin_enqueue_scripts pour l’administration, et enqueue_block_editor_assets pour l’éditeur de blocs.
Pièges fréquents
- Charger un script en dehors du bon hook, par exemple directement dans le corps du fichier principal de l’extension, provoque souvent un chargement sur toutes les pages ou à un moment inapproprié du cycle de vie.
- Un numéro de version identique entre deux déploiements peut empêcher le navigateur de recharger un fichier modifié à cause du cache.
- La fonction
wp_localize_script()permet de transmettre des données PHP (une URL de l’API REST, un identifiant utilisateur) à un script déjà mis en file, sous forme d’une variable JavaScript globale. - Depuis WordPress 6.3,
wp_enqueue_script_module()propose un chemin dédié aux modules ES natifs, avec un système de dépendances et d’importations distinct de celui des scripts classiques.