La publication a échoué : réponse JSON invalide dans WordPress

La publication a échoué. La réponse n’est pas une réponse JSON valide.

En anglais : Publishing failed. The response is not a valid JSON response.

Vous cliquez sur « Publier » ou « Mettre à jour » dans l’éditeur de blocs, et une bannière rouge apparaît en bas ou en haut de l’écran : « La publication a échoué. La réponse n’est pas une réponse JSON valide. ». Sur un contenu déjà publié, le début devient « La mise à jour a échoué. ». Votre texte n’est pas perdu pour autant : il reste dans l’éditeur tant que vous ne fermez pas l’onglet. L’erreur apparaît dans l’administration, dans l’éditeur de blocs, mais aussi dans les réglages ou les écrans modernes qui communiquent avec l’API REST.

Ce que signifie cette erreur

L’éditeur de blocs n’enregistre pas vos contenus par un formulaire classique : il envoie une requête à l’API REST de WordPress (par exemple vers /wp-json/wp/v2/posts/123) grâce à la bibliothèque JavaScript api-fetch et attend en retour du JSON. Lorsque la réponse arrive mais que le navigateur n’arrive pas à la lire comme du JSON, la bibliothèque produit l’erreur interne de code invalid_json avec le message « La réponse n’est pas une réponse JSON valide. » (fichier wp-includes/js/dist/api-fetch.js). L’éditeur (wp-includes/js/dist/editor.js) fait précéder ce message de « La publication a échoué. », « La mise à jour a échoué. » ou « La planification a échoué. » selon l’état du contenu ; il ne l’ajoute que s’il ne contient pas de HTML, ce qui explique que certaines pannes n’affichent que la première phrase.

Autrement dit, le serveur a bien répondu, mais pas avec du JSON propre. Ce qui est renvoyé à la place est presque toujours du HTML : page 404 ou 403 du serveur, page d’erreur de WordPress (« Il y a eu une erreur critique sur ce site »), page de connexion, page de maintenance, ou JSON précédé de texte parasite. Ce texte parasite est typiquement un avertissement PHP (Warning, Notice, Deprecated), un espace, une ligne vide ou un caractère invisible (BOM) émis avant la réponse.

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
La réponse de la requête contient « Warning » ou « Notice » avant l’accolade ouvrante	Sortie parasite de PHP (affichage des erreurs, espace avant <?php, BOM)	Onglet « Réseau » du navigateur, WP_DEBUG_DISPLAY, fichiers modifiés récemment
La réponse est une page 404 du site ou du serveur	Permaliens ou règles de réécriture cassés, .htaccess manquant	Réglages, Permaliens ; /wp-json/ dans le navigateur
La réponse est une page 403 (« Forbidden ») ou une page de pare-feu	ModSecurity, extension de sécurité, règle CDN qui bloque la requête	Journaux du pare-feu, règle déclenchée
La réponse est la page d’accueil ou la page de connexion	Redirection http/https ou www, API REST protégée par une extension	Réglages généraux, extensions de sécurité
La réponse est une page « erreur critique » ou 500	Erreur fatale PHP pendant l’enregistrement	wp-content/debug.log, journaux PHP

Les causes les plus fréquentes

1. Des permaliens ou des règles de réécriture à régénérer : l’adresse /wp-json/ renvoie une page 404 au lieu de JSON.
2. Une extension ou un thème qui produit du texte avant la réponse (avertissement PHP affiché, espace après un ?> final, fichier enregistré avec un BOM, echo oublié).
3. Un pare-feu applicatif, une extension de sécurité ou un CDN qui bloque les requêtes REST ou certains contenus (code, balises, mots jugés suspects).
4. Une redirection entre http et https ou entre www et sans www qui renvoie une page HTML à la place de la réponse REST.
5. Une extension qui désactive ou restreint l’API REST pour les utilisateurs connectés.
6. Une erreur fatale PHP, un délai dépassé (504) ou un corps de requête trop gros (413) pendant l’enregistrement.

Solutions pas à pas

1. Sauvegarder le contenu et lire la vraie réponse

Avant toute manipulation, copiez votre contenu (Ctrl+A puis Ctrl+C dans l’éditeur, ou menu « Éditeur de code »). Ouvrez ensuite les outils de développement du navigateur (F12), onglet « Réseau », filtrez sur « wp-json » ou « rest_route », puis cliquez à nouveau sur « Mettre à jour ». Sélectionnez la requête en erreur : le statut HTTP et l’onglet « Réponse » vous disent exactement ce que le serveur a renvoyé. Tout le diagnostic découle de cette observation. En ligne de commande, vous pouvez aussi tester la racine de l’API :

curl -i https://www.exemple.fr/wp-json/
curl -s https://www.exemple.fr/wp-json/ | head -c 300

Une réponse correcte commence par {"name":. Tout caractère situé avant l’accolade est le texte parasite recherché.

2. Régénérer les permaliens

Si la réponse est une page 404, ouvrez Réglages, Permaliens, et cliquez sur « Enregistrer les modifications » sans rien changer. WordPress réécrit alors ses règles. Sans accès à l’administration, utilisez WP-CLI :

wp rewrite flush --hard

Si le fichier .htaccess est absent ou incomplet (Apache), il doit contenir le bloc standard :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Sous nginx, la règle équivalente se place dans le bloc server :

location / {
    try_files $uri $uri/ /index.php?$args;
}

Vérification : https://www.exemple.fr/wp-json/ doit afficher du JSON. Si ce n’est pas le cas, https://www.exemple.fr/?rest_route=/ doit le faire : dans ce cas, seuls les permaliens ou le serveur sont en cause.

3. Trouver la sortie parasite

Si la réponse contient du texte avant le JSON, commencez par masquer l’affichage des erreurs tout en les journalisant, dans wp-config.php, avant la ligne « That’s all, stop editing! » :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Réessayez de publier, puis lisez wp-content/debug.log : chaque avertissement indique le fichier et la ligne en cause. Corrigez-le ou mettez l’extension concernée à jour. Pour un espace ou un BOM, recherchez les fichiers PHP qui commencent par un caractère invisible ou qui contiennent un ?> final suivi d’une ligne vide :

grep -rl $'\xEF\xBB\xBF' wp-content/themes wp-content/plugins --include=*.php

Enregistrez le fichier fautif en « UTF-8 sans BOM » et supprimez toute ligne vide avant <?php et après un ?> final. Notre article sur la ligne vide avant le PHP de functions.php illustre ce piège. Pensez à désactiver ensuite WP_DEBUG en production et à lire nos bons réflexes avec debug.log.

4. Isoler l’extension ou le thème fautif

Désactivez toutes les extensions, puis réactivez-les une à une en testant après chacune. Sans accès à l’administration, renommez le dossier wp-content/plugins ou utilisez WP-CLI :

wp plugin deactivate --all
wp plugin activate nom-de-l-extension

Si l’erreur persiste, basculez temporairement sur un thème par défaut (wp theme activate twentytwentyfive, si ce thème est installé). Si le problème disparaît, la sortie parasite vient du thème ou d’une extension, et la solution 3 vous aide à la localiser.

5. Débloquer le pare-feu, le CDN ou l’extension de sécurité

Si la réponse est une page 403 ou une page de challenge, cherchez dans les journaux du pare-feu (ModSecurity, extension de sécurité, règle du CDN) la règle déclenchée à l’heure de l’échec. Autorisez les requêtes vers /wp-json/ pour les utilisateurs connectés, ou ajoutez une exception pour la règle précise. Évitez de désactiver tout le pare-feu : une exception ciblée suffit.

6. Corriger les adresses et les redirections

Vérifiez, dans Réglages, Général, que « Adresse WordPress (URL) » et « Adresse web (URL du site) » correspondent à l’URL utilisée dans le navigateur (même protocole, même www). Une requête REST qui subit une redirection vers une autre adresse peut aboutir à du HTML. Si le navigateur signale aussi trop de redirections, consultez la fiche sur la boucle de redirection ERR_TOO_MANY_REDIRECTS.

Dans Outils, Santé du site, les tests « L’API REST a rencontré une erreur » ou « L’API REST a rencontré un résultat inattendu » confirment que le problème dépasse l’éditeur.

Prévenir l’erreur

• Gardez WP_DEBUG_DISPLAY à false en production, et journalisez les erreurs dans debug.log plutôt que de les afficher.
• Ne laissez pas de balise ?> de fermeture à la fin des fichiers PHP : elle n’est pas obligatoire et évite les espaces parasites.
• Testez l’éditeur après chaque mise à jour d’extension de sécurité ou de cache sur un site de préproduction.
• Centralisez vos journaux PHP et serveur, comme dans notre article sur les journaux nginx et PHP de WordPress.
• Documentez les exceptions du pare-feu pour /wp-json/ afin de les retrouver après une migration.

FAQ