TypeError: Cannot read property 'attributes' of undefined — ce message apparaît dans la console, une fois sur dix, quand on ouvre un pattern personnalisé dans la version expérimentale de l’éditeur de site, encore livrée par le plugin Gutenberg en dehors du cœur de WordPress. Le rendu semble correct à l’écran, mais quelque chose s’est cassé pendant l’hydratation du bloc, et sans remontée d’erreur, ce genre de régression reste invisible jusqu’à ce qu’un client se plaigne d’un écran blanc.
Sur un projet où plusieurs patterns expérimentaux cohabitent avec des blocs cœur encore instables, on a choisi d’installer un SDK de suivi d’erreurs directement côté client, dans l’éditeur, sans attendre que le projet Gutenberg stabilise son propre système de rapports. Le choix s’est porté sur Sentry, pour sa configuration minimale et son plan gratuit suffisant à l’échelle d’un thème en développement.
Pourquoi suivre les erreurs de l’éditeur et pas seulement celles du front
La tentation, sur un projet WordPress classique, est de ne surveiller que le rendu public : c’est ce que voit le visiteur, donc ce qui compte commercialement. Mais dans un contexte où l’éditeur de site est encore expérimental, la majorité des régressions se produisent précisément là, dans l’interface d’administration, au moment où un rédacteur glisse un bloc dans un template part fraîchement créé.
Une erreur JavaScript non interceptée dans l’éditeur peut simplement figer le panneau latéral, empêcher l’enregistrement d’un pattern, ou pire, corrompre silencieusement les attributs sérialisés d’un bloc. Sans remontée, l’équipe ne le découvre qu’en relisant les tickets de support, plusieurs jours après.
Installer le SDK Sentry côté client, en minimal
Le SDK JavaScript de Sentry s’installe en quelques minutes. Pour un thème encore en expérimentation, pas question d’ajouter un bundler supplémentaire : on charge simplement le script depuis un CDN, dans le fichier functions.php du thème, en le limitant à l’écran d’édition.
function wpm_enqueue_sentry_editor() {
if ( ! is_admin() ) {
return;
}
wp_enqueue_script(
'sentry-browser',
'https://browser.sentry-cdn.com/6.19.7/bundle.min.js',
array(),
'6.19.7',
true
);
wp_add_inline_script(
'sentry-browser',
"Sentry.init({ dsn: 'https://exemplecle@o0.ingest.sentry.io/0', environment: 'editeur-experimental' });"
);
}
add_action( 'admin_enqueue_scripts', 'wpm_enqueue_sentry_editor' );
Le champ environment mérite une attention particulière : il permet de filtrer, dans le tableau de bord Sentry, les erreurs qui viennent spécifiquement de l’éditeur expérimental, sans les mélanger avec celles d’un futur suivi côté front. Un projet Sentry unique, plusieurs environnements, c’est suffisant à ce stade.
Filtrer le bruit propre à un éditeur encore instable
Sans filtrage, le tableau de bord se remplit très vite d’erreurs qui ne viennent pas de votre code, mais de l’éditeur lui-même, en version expérimentale : des avertissements internes au paquet @wordpress/block-editor, des erreurs liées à des extensions tierces de l’utilisateur, ou des messages provenant d’API navigateur non encore stabilisées.
La méthode beforeSend du SDK permet d’écarter ce bruit avant l’envoi :
- Ignorer les erreurs dont le message contient
ResizeObserver, bruit classique des navigateurs sur les interfaces à colonnes redimensionnables. - Ignorer les erreurs dont la pile d’appel pointe vers une extension de navigateur (
chrome-extension://). - Ne conserver que les erreurs dont le fichier source contient le nom du thème ou du pattern en développement.
Isoler l’erreur au niveau du pattern
Quand plusieurs patterns expérimentaux sont testés en parallèle, il devient utile d’ajouter un contexte supplémentaire à chaque erreur : le nom du pattern actif au moment du crash. Un simple appel à Sentry.setTag('pattern', patternSlug), déclenché à l’ouverture de chaque pattern dans l’éditeur, suffit à transformer une pile d’erreurs anonymes en informations exploitables.
Sur ce projet, on a pris l’habitude d’ajouter un tag avant même d’avoir un vrai besoin : la première semaine, ça ne sert à rien ; la troisième semaine, ça fait gagner une demi-journée de recherche à chaque incident.
Ce que ce suivi ne remplace pas
Ce dispositif reste volontairement minimal. Il ne remplace pas un vrai outil de monitoring PHP côté serveur : les erreurs de rendu côté back-end, les fatales dans un hook de sauvegarde, ou les problèmes de base de données ne remontent jamais par ce canal. Il ne remplace pas non plus une stratégie de tests automatisés sur les blocs, qui reste la meilleure prévention contre les régressions.
Il ne cherche pas non plus à suivre les erreurs d’un thème classique encore basé sur des templates PHP traditionnels : le périmètre choisi ici est strictement l’éditeur de site expérimental et les patterns qui y sont développés.
En résumé
À ce stade expérimental du projet Gutenberg, aucune remontée d’erreur native ne couvre correctement l’éditeur de site. Installer un SDK Sentry minimal, réservé à l’écran d’administration, filtré pour ignorer le bruit du navigateur et tagué par pattern, coûte une vingtaine de minutes de configuration et change complètement la capacité de l’équipe à diagnostiquer un problème signalé par un client testeur. Ce n’est pas un dispositif de production au sens classique, mais un filet de sécurité pour une phase où tout, y compris l’éditeur lui-même, est encore mouvant.
