Corriger l'éditeur de blocs WordPress qui ne se charge pas

La plupart du temps, un éditeur de blocs WordPress qui refuse de se charger, c’est une erreur JavaScript — un seul script cassé d’un plugin ou d’un thème bloque toute l’application React, et l’éditeur ne finit jamais son rendu. Ouvrez la console développeur de votre navigateur (F12, ou Cmd+Option+I sur Mac), rechargez l’écran d’édition et lisez l’erreur en rouge. Elle nomme presque toujours le fichier qui a planté. Cette seule ligne vous dit quel plugin désactiver, et vous êtes généralement de retour à l’écriture en moins de cinq minutes. Réinstaller WordPress, augmenter la limite de mémoire PHP et passer à l’éditeur classique sont les trois suggestions les plus courantes en ligne, et ces trois-là sont presque toujours la mauvaise décision.

Pourquoi l’éditeur casse de cette façon

L’éditeur de blocs (Gutenberg) est une application React monopage qui tourne à l’intérieur de wp-admin/post.php et post-new.php. WordPress met en file une pile de paquets de scripts — wp-blocks, wp-element, wp-editor, wp-edit-post — et l’application s’initialise via wp.domReady(). Le JavaScript cesse de s’exécuter à la première exception non interceptée. Donc si un script mis en file plante pendant l’initialisation de l’éditeur, tout ce qui suit meurt avec lui. Votre zone de rédaction soigneusement écrite se réduit à un panneau blanc vide ou au message « L’éditeur a rencontré une erreur inattendue ».

Par défaut, WordPress concatène aussi les scripts d’administration en moins de requêtes. Ça veut dire que le JS cassé d’un seul plugin peut entraîner dans sa chute des scripts sans rapport chargés dans le même paquet, et c’est pour ça que le coupable n’est pas toujours évident à partir du comportement seul. La console, elle, l’est.

Le second mode de défaillance a une autre allure : l’éditeur se charge, mais l’enregistrement renvoie « La mise à jour a échoué. La réponse n’est pas une réponse JSON valide. » Ce n’est pas un problème JavaScript. L’éditeur dialogue avec l’API REST sur /wp-json/wp/v2/, et il attend du JSON propre en retour. Si un plugin ou le functions.php de votre thème émet une notice, un avertissement ou une erreur fatale PHP avant le JSON — ou si un plugin de sécurité bloque la route REST, ou si un plugin de redirection réécrit l’URL — la réponse est polluée et l’éditeur n’arrive pas à l’analyser.

Comment corriger, le plus rapide d’abord

1. Lisez la console. Reproduisez la panne avec les DevTools ouverts. Une erreur du type Uncaught TypeError ... some-plugin/build/index.js pointe directement vers le plugin fautif. Cette seule étape résout la majorité des cas et vous évite de bisecter à l’aveugle.

2. Écartez le navigateur. Faites un rechargement forcé (Cmd/Ctrl+Shift+R), puis essayez une fenêtre de navigation privée avec les extensions désactivées. Les bloqueurs de pub et les extensions de confidentialité suppriment parfois des scripts d’administration. Si ça marche en navigation privée, le problème vient d’une extension du navigateur ou d’un cache périmé, pas de votre site.

3. Testez l’API REST directement si vous avez vu le message « réponse JSON non valide ». Rendez-vous sur https://votresite.com/wp-json/ dans un navigateur. Vous devriez obtenir un mur de JSON. Si vous obtenez du HTML, une erreur 500 ou une redirection vers la connexion, c’est là qu’est votre bug — un plugin casse la réponse REST, pas l’éditeur lui-même.

4. Bisectez vos plugins. Désactivez-les tous, confirmez que l’éditeur se charge, puis réactivez-les un par un jusqu’à ce que ça recasse. Si vous êtes complètement bloqué hors de wp-admin, faites-le en SFTP en renommant le dossier :

mv wp-content/plugins wp-content/plugins_off

WordPress désactive tout quand le dossier disparaît. Renommez-le en sens inverse, puis déplacez les plugins vers l’extérieur et l’intérieur un à un.

5. Testez le thème. Basculez sur Twenty Twenty-Four. Un thème qui met en file du JS d’éditeur cassé ou qui plante en PHP dans functions.php produit les mêmes symptômes.

6. Activez le journal et lisez la vraie erreur. Pour les défaillances REST/JSON en particulier, activez le débogage dans wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

L’erreur fatale est écrite dans wp-content/debug.log avec le fichier et le numéro de ligne exacts. Si cette trace d’appel est dense — noms de classes avec espaces de noms, chaînes de require, une erreur fatale enfouie sous dix lignes de trace — collez-la dans notre décodeur de journal d’erreurs WordPress pour voir, en clair, quel plugin et quelle ligne l’ont réellement déclenchée. C’est toute la différence entre « quelque chose est cassé » et « la ligne 214 de ce plugin précis est cassée ».

Si vous soupçonnez que la concaténation des scripts masque le vrai coupable, forcez chaque script à se charger séparément pour que l’erreur de la console pointe vers un seul fichier :

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

Ce qu’il ne faut pas faire

N’installez pas le plugin Classic Editor en croyant que c’est réglé. Ça ne corrige rien — ça masque l’éditeur de blocs pour que vous cessiez de voir l’erreur. Le JavaScript cassé ou la réponse REST cassée est toujours là, et il vous rattrapera dans l’éditeur de site, dans les widgets, ou à votre prochaine mise à jour. Diagnostiquez d’abord ; ne repliez sur l’éditeur classique que si vous avez délibérément choisi d’arrêter d’utiliser les blocs.

N’augmentez pas la limite de mémoire PHP par réflexe. C’est le correctif copier-coller préféré d’Internet, mais un éditeur blanc est rarement un épuisement de mémoire. Un vrai épuisement renvoie une erreur fatale précise — « Allowed memory size of N bytes exhausted » — que vous verrez dans debug.log. Si cette ligne n’y est pas, ajouter de la mémoire ne change rien.

Ne réinstallez pas le cœur de WordPress. Les fichiers du cœur sont identiques au bit près sur chaque installation. Si le cœur était le problème, tous les sites WordPress de la planète auraient un éditeur cassé en ce moment. La faute vient presque toujours de vos plugins ou de votre thème, et réinstaller le cœur risque d’écraser des choses tout en ne corrigeant rien.

Ne videz pas et ne désactivez pas aveuglément votre plugin de cache en première étape. La minification et la concaténation JS agressives peuvent casser l’éditeur, donc ça vaut le coup de tester — mais vérifiez la console avant de vous mettre à vider les caches au hasard. Deviner, c’est comme ça qu’un correctif de cinq minutes se transforme en après-midi.

Toujours bloqué ?

Si la console est propre, que l’API REST renvoie du JSON valide et qu’une bisection complète des plugins et du thème laisse quand même l’éditeur mort, la réponse est presque toujours dans debug.log. Activez WP_DEBUG_LOG, reproduisez la panne une fois, et passez l’erreur fatale obtenue dans le décodeur de journal d’erreurs. La trace d’appel nomme le fichier — commencez par là.