Un bloc qui plante l’éditeur entier : isoler la cause avec error boundary

Un mardi matin, un rédacteur signale que l’éditeur d’un article spécifique affiche un écran entièrement blanc dès l’ouverture, alors que tous les autres articles du site s’ouvrent normalement. Aucun message d’erreur visible à l’écran, aucune information dans les journaux PHP puisque le plantage se produit entièrement côté JavaScript, dans le navigateur. La tentation immédiate est de désactiver les extensions une à une pour isoler la coupable, une méthode qui fonctionne mais qui devient vite pénible sur un site chargé de vingt extensions actives, et qui interrompt le travail de toute une équipe éditoriale pendant l’opération.

Il existe une méthode plus rapide, qui s’appuie sur la façon dont React gère normalement les erreurs de rendu grâce aux composants de type error boundary, et sur les informations que le navigateur fournit directement dans sa console de développement sans qu’il soit nécessaire de toucher à la configuration du site.

Pourquoi l’éditeur entier plante, pas juste un bloc

Depuis plusieurs versions, l’éditeur de blocs englobe chaque bloc individuel dans son propre composant BlockErrorBoundary, ce qui signifie qu’une erreur de rendu dans un seul bloc ne devrait normalement afficher un message d’erreur circonscrit à ce bloc, sans faire tomber le reste de l’interface. Quand l’écran entier devient blanc, cela signifie généralement que l’erreur se produit en dehors de ce périmètre protégé : dans un composant enregistré via registerPlugin, dans un filtre appliqué globalement, ou pendant l’initialisation du store de données avant même que le rendu des blocs ne commence.

Premier réflexe : la console du navigateur

Avant toute désactivation d’extension, ouvrir la console de développement du navigateur affiche presque toujours la trace de la pile d’appels JavaScript ayant provoqué le plantage, avec le nom du fichier source et souvent celui de la fonction fautive. Sur un projet compilé avec @wordpress/scripts, cette trace pointe généralement vers le fichier build/index.js d’une extension précise, sans même avoir besoin de désactiver quoi que ce soit.

Uncaught TypeError: Cannot read properties of undefined (reading 'map')
    at Edit (index.js:842)
    at renderWithHooks (react-dom.development.js:16305)

Le nom du fichier index.js associé au numéro de ligne suffit souvent à identifier l’extension à l’origine, en particulier si le nom du plugin apparaît dans le chemin complet affiché au survol de la ligne dans l’onglet réseau.

Isoler avec un paramètre d’URL

Quand la console ne suffit pas à trancher, WordPress propose un mode de débogage accessible en ajoutant ?gutenberg-experiments ou, plus utile ici, en forçant temporairement le safe mode via le paramètre d’URL réservé aux extensions, qui désactive tous les plugins pour la requête en cours sans les désactiver réellement en base de données.

wp-admin/post.php?post=42&action=edit&plugin_safe_mode=1

Ce mécanisme, calqué sur le safe mode déjà connu côté thèmes, permet de confirmer en un seul chargement de page si le plantage vient bien d’une extension active, sans qu’aucun visiteur ni collègue ne soit affecté par une désactivation réelle pendant l’investigation.

Circonscrire le composant fautif

Une fois l’extension identifiée, il reste à localiser le composant précis. Envelopper temporairement le rendu suspect dans un composant d’error boundary personnalisé, importé depuis React directement, permet de confirmer l’hypothèse sans devoir lire l’intégralité du code source de l’extension tierce.

class Isolement extends React.Component {
    state = { erreur: null };
    static getDerivedStateFromError( erreur ) {
        return { erreur };
    }
    render() {
        if ( this.state.erreur ) {
            return <p>Erreur isolée : { this.state.erreur.message }</p>;
        }
        return this.props.children;
    }
}

• La console du navigateur reste toujours plus rapide qu’une désactivation manuelle d’extensions.
• Le safe mode par paramètre d’URL confirme l’hypothèse sans effet de bord pour les autres utilisateurs.
• Un error boundary personnalisé permet d’isoler précisément le composant sans lire tout le code source d’un tiers.

Prévenir plutôt que déboguer

Pour ses propres blocs, mieux vaut anticiper ce genre d’incident en enveloppant systématiquement les composants d’édition les plus complexes dans un error boundary maison, avec un message clair invitant à contacter le support plutôt qu’un écran blanc muet. C’est un filet de sécurité peu coûteux à mettre en place, qui transforme un incident bloquant en simple message d’avertissement localisé.

Un écran blanc sans message n’est jamais une fatalité technique : c’est le signe qu’aucun composant, à aucun niveau, n’a pris la responsabilité de capturer l’erreur avant qu’elle ne remonte jusqu’en haut de l’arbre.

Ce qu’il faut retenir

Face à un écran blanc dans l’éditeur, la désactivation séquentielle des extensions reste un dernier recours, pas un premier réflexe. La console du navigateur, le safe mode par paramètre d’URL et un error boundary temporaire permettent, dans la grande majorité des cas, d’isoler la cause en quelques minutes, sans interrompre le travail de toute une équipe éditoriale pendant l’investigation.