Un script JavaScript de 40 kilo-octets se charge sur l’écran des réglages généraux, sur celui des commentaires, et même sur la page de profil utilisateur, alors qu’il ne sert que sur l’écran d’édition d’un seul type de contenu personnalisé. Ce genre de situation apparaît dès qu’un développeur accroche son enqueue de script directement sur admin_enqueue_scripts, sans condition de ciblage.
admin_enqueue_scripts se déclenche effectivement sur chaque page du back-office, ce qui en fait un hook pratique pour l’accroche, mais dangereux si on omet de restreindre son exécution à l’écran réellement concerné.
Le piège du chargement systématique
Sans condition, un script destiné à l’écran d’édition d’un produit se retrouve chargé aussi sur la liste des utilisateurs, l’écran des extensions, ou le tableau de bord général. Au mieux, cela ralentit inutilement chaque page administrative sans conséquence visible. Au pire, un script mal isolé entre en conflit avec des éléments d’interface présents sur d’autres écrans, provoquant des bogues difficiles à relier à leur origine réelle.
Le premier réflexe consiste souvent à filtrer sur le paramètre $hook_suffix transmis en argument à la fonction accrochée sur admin_enqueue_scripts. Cela fonctionne pour des écrans standards, mais devient vite fragile dès qu’un type de contenu personnalisé ou un écran d’options ajoute des variantes de suffixes moins prévisibles.
get_current_screen() pour un ciblage précis
La fonction get_current_screen() renvoie un objet WP_Screen décrivant précisément l’écran d’administration actuellement affiché : son identifiant, le type de contenu concerné le cas échéant, et le contexte général (édition, liste, réglages) :
add_action( 'admin_enqueue_scripts', function () {
$ecran = get_current_screen();
if ( ! $ecran || 'produit' !== $ecran->post_type || 'post' !== $ecran->base ) {
return;
}
wp_enqueue_script(
'gestion-produit',
get_template_directory_uri() . '/admin/js/gestion-produit.js',
array( 'jquery' ),
'1.0',
true
);
} );
La propriété base distingue les grandes familles d’écrans : post pour un écran d’édition, edit pour une liste de contenus, post-new spécifiquement pour la création. Combinée à post_type, elle permet un ciblage précis sans dépendre d’un suffixe de hook parfois peu lisible.
Un identifiant complet pour les cas plus fins
La propriété id de l’objet WP_Screen fournit un identifiant complet de l’écran, utile quand base et post_type ne suffisent pas à distinguer deux contextes proches, par exemple un écran de réglages propre à une extension :
add_action( 'admin_enqueue_scripts', function () {
$ecran = get_current_screen();
if ( ! $ecran || 'produit_page_reglages-boutique' !== $ecran->id ) {
return;
}
wp_enqueue_style(
'reglages-boutique',
get_template_directory_uri() . '/admin/css/reglages-boutique.css'
);
} );
Cet identifiant se construit généralement à partir du slug transmis à add_submenu_page() lors de la création de l’écran, ce qui le rend prévisible pour peu qu’on connaisse la fonction qui a enregistré la page en question.
Repérer l’identifiant d’un écran inconnu
Sur un écran dont l’identifiant n’est pas immédiatement évident, un moyen rapide de le découvrir consiste à l’afficher temporairement pendant le développement :
add_action( 'admin_notices', function () {
$ecran = get_current_screen();
if ( $ecran ) {
printf( '<div class="notice notice-info"><p>Écran courant : %s</p></div>', esc_html( $ecran->id ) );
}
} );
Cette astuce temporaire, retirée avant la mise en production, évite de deviner l’identifiant par tâtonnement en consultant le code source de chaque page.
Ce que le hook lui-même n’est pas
Il vaut la peine de préciser que admin_enqueue_scripts reste, en soi, un hook parfaitement adapté pour l’accroche des scripts d’administration : le problème ne vient jamais du hook, mais de l’absence de condition de ciblage à l’intérieur de la fonction qui y est accrochée. Confondre les deux mène parfois à chercher une alternative au hook, alors que la vraie correction se trouve dans la logique conditionnelle ajoutée derrière.
Sur toute page d’administration personnalisée, vérifier
get_current_screen()avant d’enregistrer un script devrait devenir un réflexe aussi systématique que l’enqueue lui-même.
En résumé
Cibler précisément l’écran concerné avec get_current_screen() évite de surcharger inutilement chaque page du back-office et referme la porte aux conflits difficiles à diagnostiquer entre scripts qui n’avaient rien à faire ensemble. Un seul appel bien placé suffit à transformer un enqueue global en un chargement réellement ciblé.
