# « Uncaught ReferenceError: wp is not defined » dans un bloc mal enqueué

> L'éditeur plante à l'ouverture d'une page, la console affiche « wp is not defined ». Diagnostic d'une dépendance de script manquante dans block.json.

- Auteur : WordPress Développement
- Publié le : 2024-03-06
- Mis à jour le : 2024-03-06
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/wp-is-not-defined-bloc-mal-enqueue/

## L’essentiel

- L'erreur trahit presque toujours une dépendance de script absente
- Le fichier .asset.php généré par wp-scripts liste les vraies dépendances
- Une déclaration manuelle dans block.json doit rester synchronisée avec le build

`Uncaught ReferenceError: wp is not defined`, ligne 1 du fichier `index.js` d'un bloc tout juste ajouté à un thème. La console du navigateur pointe une ligne parfaitement anodine, un simple appel à `wp.blocks.registerBlockType(...)`, copié depuis un exemple de documentation. Le bloc fonctionnait pourtant très bien la veille sur l'environnement de développement local.

Cette erreur signifie toujours la même chose : le script du bloc s'exécute avant que l'objet global `wp`, exposé par les scripts natifs de WordPress (`wp-blocks`, `wp-element`, etc.), n'ait été chargé sur la page. C'est un problème d'ordre de chargement, pas un problème de syntaxe JavaScript.

## Retrouver la déclaration fautive

Le thème en cause enregistrait le bloc manuellement, sans passer par le générateur `@wordpress/scripts` et sans exploiter le fichier `.asset.php` qu'il produit automatiquement. La déclaration ressemblait à ceci, avec un tableau de dépendances incomplet :

```
wp_register_script(
    'acme-bloc-editeur',
    get_template_directory_uri() . '/blocks/mon-bloc/index.js',
    array( 'wp-blocks', 'wp-element' ),
    '1.0.0'
);
```

Le tableau de dépendances ne cite que `wp-blocks` et `wp-element`, alors que le fichier source utilise également des composants issus de `wp-block-editor` (pour `useBlockProps`) et `wp-i18n` (pour `__()`). Sur l'environnement local, un autre plugin actif chargeait incidemment ces dépendances en amont, masquant le problème ; en production, sans ce plugin, l'ordre réel d'exécution révélait le manque.

## La bonne pratique : ne jamais lister les dépendances à la main

Depuis que `@wordpress/scripts` existe, la génération du fichier `build/index.asset.php` à chaque compilation résout précisément ce problème : ce fichier contient un tableau PHP avec la liste exacte des dépendances détectées automatiquement à partir des imports du code source, ainsi qu'un numéro de version calculé à partir d'un hash du contenu, utile pour l'invalidation de cache navigateur.

> L'essentiel à retenir : L'erreur trahit presque toujours une dépendance de script absente ; Le fichier .asset.php généré par wp-scripts liste les vraies dépendances ; Une déclaration manuelle dans block.json doit rester synchronisée avec le build

```
<?php
// build/index.asset.php généré automatiquement
return array(
    'dependencies' => array( 'wp-block-editor', 'wp-blocks', 'wp-element', 'wp-i18n' ),
    'version' => '9f2a1c4e8b3d7f21',
);
```

L'enregistrement du script doit alors lire ce fichier plutôt que de recopier une liste figée, pour rester automatiquement synchronisé à chaque nouvelle compilation :

```
$asset = include get_template_directory() . '/blocks/mon-bloc/build/index.asset.php';

wp_register_script(
    'acme-bloc-editeur',
    get_template_directory_uri() . '/blocks/mon-bloc/build/index.js',
    $asset['dependencies'],
    $asset['version']
);
```

## Encore plus simple : déclarer via block.json

Depuis la déclaration de bloc basée sur `block.json`, la fonction `register_block_type()` appelée avec le chemin du dossier du bloc sait lire automatiquement les champs `editorScript` et `script`, et résout elle-même le fichier `.asset.php` associé sans code d'enregistrement manuel :

```
{
    "apiVersion": 3,
    "name": "acme/mon-bloc",
    "editorScript": "file:./build/index.js",
    "editorStyle": "file:./build/index.css"
}
```

```
add_action( 'init', function() {
    register_block_type( __DIR__ . '/blocks/mon-bloc' );
} );
```

Cette approche élimine la classe entière de bugs liés à une dépendance oubliée : tant que le bloc est recompilé avec `wp-scripts build`, la liste de dépendances reste toujours exacte, sans intervention manuelle du développeur.

## Vérifier après correctif

- Ouvrir l'éditeur avec l'outil de développement du navigateur, onglet réseau, et vérifier que chaque script `wp-*` nécessaire est bien chargé avant le script du bloc.
- Vider tout cache d'assets (OPcache, cache de page, CDN) après le déploiement, un ancien `index.js` pouvant rester servi malgré le correctif.
- Reproduire le test sur un environnement le plus proche possible de la production, l'incident initial n'étant apparu que faute d'un plugin masquant le symptôme en local.

> Face à un « wp is not defined », je ne cherche jamais la faute dans la logique du bloc lui-même : c'est systématiquement un problème de dépendances de script, réglé en quelques minutes une fois qu'on cesse de les déclarer à la main.

## En résumé

Cette erreur est l'une des plus fréquentes et des plus faciles à corriger dès lors qu'on comprend son origine : une dépendance de script manquante, jamais un défaut du code du bloc lui-même. Laisser `@wordpress/scripts` et le fichier `.asset.php` qu'il génère gérer cette liste évite d'avoir à la maintenir manuellement, et supprime durablement ce type de régression.