enqueue_block_editor_assets (hook)

Définition : enqueue_block_editor_assets est une action WordPress utilisée pour charger des scripts ou styles propres à l’interface de l’éditeur de blocs. Elle concerne les ressources de l’administration, pas automatiquement celles du site public.

Comprendre et utiliser

À quoi cela sert ?

Ce hook permet d’étendre l’éditeur sans charger les mêmes ressources sur chaque page front-end. Il peut servir à ajouter un panneau, un filtre ou des outils d’édition.

Comment cela fonctionne ?

L’action déclenche un callback PHP dans lequel on peut appeler wp_enqueue_script() ou wp_enqueue_style() avec les dépendances adaptées. Les blocs avec block.json préfèrent souvent la déclaration de leurs assets dans les métadonnées.

Dans quel contexte l’utiliser ?

À employer pour une extension de l’interface de l’éditeur qui n’est pas directement un script déclaré par un type de bloc.

Cas concret : ATOOLPHA

ATOOLPHA ajoute un script de vérification éditoriale à l’écran de rédaction, sans charger ce script sur les pages publiques du lexique.

Exemple de code commenté

Extrait documentaire : le contexte WordPress du plugin/éditeur et les dépendances décrites sont nécessaires ; ne pas coller dans le contenu d’une page.

<?php
add_action( 'enqueue_block_editor_assets', function () {
    $url = plugin_dir_url( __FILE__ ) . 'editor-helper.js';
    wp_enqueue_script(
        'atoolpha-editor-helper', $url,
        array( 'wp-element', 'wp-data' ), '1.0.0', true
    );
} );

Décryptage de l’exemple

La dépendance wp-element et wp-data garantit l’ordre de chargement des bibliothèques déclarées. Le fichier editor-helper.js doit réellement exister dans le plugin et être compatible avec le navigateur cible.

Résultat attendu

Lorsque l’éditeur se charge, le script déclaré peut s’exécuter dans son contexte ; les pages publiques n’ont pas à charger ce même asset par défaut.

Atelier pratique de vérification

Charger un petit script de diagnostic dans l’interface de l’éditeur et confirmer sa présence dans l’onglet Réseau du navigateur. Ouvrir ensuite une page publique et vérifier qu’il n’y est pas chargé. Tester les dépendances déclarées, les environnements iframe et la différence avec enqueue_block_assets pour les styles du contenu.

Précautions et limites

Éviter d’utiliser ce hook pour les styles qui doivent aussi exister côté public. Prendre en compte l’éditeur en iframe et la séparation entre interface et contenu édité.

Contrôle avant intégration dans un plugin

Vérifier les dépendances du script, son chargement uniquement dans l’interface ciblée et la compatibilité iframe. Pour les styles du contenu, documenter plutôt les mécanismes appropriés au front-end et à l’éditeur.

À ne pas confondre

enqueue_block_editor_assets charge des ressources de l’interface ; wp_enqueue_scripts concerne les ressources du site public et les métadonnées block.json peuvent gérer les assets d’un bloc.

Diagnostic et dépannage avancés

Si le script est chargé mais ne trouve pas une API wp.*, inspecter les dépendances déclarées et l’environnement d’édition plutôt que d’introduire des temporisateurs arbitraires.