« Cannot read properties of undefined (reading ‘Item’) » — l’écran blanc de l’éditeur qui suit ce message ne donne aucune indication sur le bloc ou le composant réellement en cause. La stack trace pointe vers un fichier minifié de React, ce qui n’aide en rien à remonter jusqu’à la ligne de code fautive dans l’extension.
Ce plantage est apparu après la mise à jour du cœur WordPress vers une version embarquant une nouvelle édition de @wordpress/components, sans que rien n’ait changé dans le code du bloc lui-même. La cause : un composant utilisé par le bloc avait changé de structure interne entre les deux versions.
Comprendre pourquoi l’erreur est aussi vague
WordPress ne fige pas @wordpress/components comme une dépendance npm classique installée localement : le paquet wp-components côté navigateur correspond à la version embarquée dans le cœur WordPress installé sur le site, potentiellement différente de celle utilisée en développement local si le fichier package.json de l’extension n’a pas été mis à jour en conséquence.
Un composant peut alors exposer une structure différente (sous-composant renommé, prop renommée, export déplacé) sans qu’aucun avertissement explicite ne l’indique avant le plantage en runtime.
Isoler le composant fautif
La première étape a consisté à commenter, un par un, les imports du fichier edit.js jusqu’à faire disparaître l’erreur — une méthode rudimentaire mais efficace sur un fichier de taille raisonnable :
import { Dropdown, MenuGroup, MenuItem } from '@wordpress/components';
// ...
<Dropdown
renderContent={ () => (
<MenuGroup>
<MenuGroup.Item>Option 1</MenuGroup.Item>
</MenuGroup>
) }
/>
La vraie cause : un accès à une propriété qui n’existe plus
Le code utilisait MenuGroup.Item comme sous-composant, un pattern qui fonctionnait sur l’ancienne version de la librairie mais qui n’était en réalité jamais officiellement documenté de cette façon. La version mise à jour de @wordpress/components exposait MenuItem comme composant autonome, à importer séparément — ce qui était d’ailleurs déjà fait plus haut dans le fichier, sans être utilisé correctement :
// Correctif
<Dropdown
renderContent={ () => (
<MenuGroup>
<MenuItem>Option 1</MenuItem>
</MenuGroup>
) }
/>
Une ligne changée, et l’éditeur redevient fonctionnel. Le vrai travail a consisté à isoler cette ligne parmi plusieurs centaines de lignes de composants imbriqués.
Réduire le risque pour la prochaine mise à jour
- Consulter le
CHANGELOG.mddu paquet@wordpress/componentsavant toute montée de version majeure de WordPress, disponible sur le dépôt GitHub officiel du projet Gutenberg. - Éviter les patterns non documentés, même s’ils fonctionnent visuellement : un sous-composant accédé via la notation pointée sans être exporté explicitement de cette façon reste un pari sur la stabilité interne de la librairie.
- Tester chaque mise à jour de WordPress sur un environnement de recette avant la production, avec un passage rapide sur chaque écran d’édition contenant des blocs personnalisés.
- Ajouter un test end-to-end minimal qui ouvre l’éditeur et vérifie l’absence d’erreur JavaScript en console, avec
@wordpress/e2e-test-utils.
Ce que cet article ne couvre pas
La migration complète de toutes les dépendances @wordpress/* d’une extension vers leurs dernières versions demande une revue bien plus large que ce seul correctif ponctuel. Le passage à apiVersion 3 et à l’éditeur en iframe, qui change également la façon dont certains styles et composants se comportent, mérite un traitement séparé et plus complet.
En résumé
Une erreur JavaScript vague qui pointe vers React n’implique jamais un bug de React lui-même : elle signale presque toujours un décalage entre le code de l’extension et la version réelle des dépendances WordPress chargées en production. Isoler le composant en cause, ligne par ligne si nécessaire, reste la méthode la plus fiable quand la stack trace n’aide pas.
