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.
<?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.jspouvant 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.
