wp_enqueue_script_module()
Définition : wp_enqueue_script_module() marque un module JavaScript ES pour le chargement sur une page WordPress. Elle utilise le registre de la Script Modules API et gère ses identifiants et dépendances.
Comprendre et utiliser
À quoi sert ce terme ?
Elle permet d’associer des modules modernes à une page sans écrire directement des balises script dans les templates. WordPress peut ainsi organiser les imports et leurs ressources dans son mécanisme prévu.
Fonctionnement technique
Si une source est fournie, le module peut être enregistré au passage. Sinon, son identifiant doit déjà correspondre à un module reconnu. Les dépendances et le versionnement suivent les conventions propres aux modules.
Dans quels contextes l’utiliser ?
À choisir pour un composant ES module sur WordPress 6.5 ou ultérieur ; éviter de l’utiliser pour un script classique supposant une variable globale et un environnement non modulaire.
Cas concret : ATOOLPHA
Une page ATOOLPHA charge un module de filtrage de contenus, tandis qu’une page de contact ne le demande pas.
Exemple de code commenté
Extrait PHP destiné à un plugin ou à un template WordPress, dans le contexte indiqué ; pas au contenu HTML de l’article.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( is_page( 'lexique' ) ) {
wp_enqueue_script_module(
'atoolpha/lexicon-filter',
plugin_dir_url( __FILE__ ) . 'assets/lexicon-filter.js',
array(), '1.0.0'
);
}
} );
Décryptage de l’exemple
La condition is_page() s’évalue sur le front-end avant d’enregistrer et charger le module. Le fichier .js doit être un module valide ; les imports externes éventuels doivent être déclarés et résolubles.
Résultat attendu
La page de lexique peut charger le module, tandis que les autres pages évitent sa requête réseau.
Exercice pratique et vérification
Créer un fichier module simple journalisant une information sans donnée sensible. Comparer son chargement sur la page lexique et sur une page témoin.
Précautions et limites
Ne pas supposer la compatibilité de tous les outils de minification ou de cache avec les import maps et les modules. Vérifier le comportement en navigateur et après optimisation.
À ne pas confondre
Enqueue charge un module ; register prépare uniquement son identification. Les scripts classiques wp_enqueue_script() constituent un pipeline distinct.
Diagnostic avancé
Un module silencieux peut être bloqué par un fichier manquant, une erreur import ou une politique de sécurité de contenu ; examiner la console et la réponse HTTP.
Choix d’architecture et déploiement
Le chargement conditionnel protège les pages sans fonctionnalité concernée contre des requêtes inutiles. Cela ne dispense pas de vérifier le fonctionnement lorsque le module est chargé depuis une page de cache, une URL traduite ou un modèle possédant un slug différent.
Contrôle avant intégration
Veiller aux modules réellement nécessaires, à la résolution des imports et à la compatibilité avec les outils de cache et CSP.
Notions associées
- wp_register_script_module()
- Script Modules API
- wp_enqueue_script()
