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()

Références officielles

Bouton retour en haut de la page