# current_screen dans l’administration : charger un script sur la bonne page

> Un script d'administration chargé sur toutes les pages du back-office ralentit inutilement chaque écran. get_current_screen cible précisément la bonne page.

- Auteur : WordPress Développement
- Publié le : 2023-12-29
- Mis à jour le : 2023-12-29
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/current-screen-charger-script-bonne-page/

## L’essentiel

- admin_enqueue_scripts s'exécute sur toutes les pages du back-office
- get_current_screen() identifie précisément l'écran affiché
- L'identifiant de l'écran dépend du type de contenu et du contexte

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

> L'essentiel à retenir : admin_enqueue_scripts s'exécute sur toutes les pages du back-office ; get_current_screen() identifie précisément l'écran affiché ; L'identifiant de l'écran dépend du type de contenu et du contexte

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é.