WordPress publishing failed : l’erreur « the response is not a valid JSON response » apparait dans l’éditeur Gutenberg quand WordPress ne parvient pas à communiquer avec sa propre API REST. La solution la plus rapide consiste à vider les caches, puis à tester /wp-json/wp/v2/posts directement dans le navigateur : si la page renvoie du HTML au lieu de JSON, un plugin ou le .htaccess bloque l’API REST. Dans ce cas, renommer le fichier .htaccess et désactiver les plugins un par un suffit à résoudre le problème dans 80 % des cas.

Qu’est-ce que l’erreur « publishing failed » dans WordPress ?

L’erreur « publishing failed » (ou « mise à jour de la publication échouée ») s’affiche dans la barre latérale droite de l’éditeur Gutenberg quand un appel AJAX à l’API REST de WordPress retourne une réponse inattendue. Depuis WordPress 5.0, Gutenberg s’appuie entièrement sur l’API REST (/wp-json/wp/v2/) pour sauvegarder et publier les articles. Si cette API renvoie du HTML, un message d’erreur PHP, ou une réponse vide au lieu du JSON attendu, Gutenberg affiche immédiatement l’avertissement.

Deux variantes du message existent :

  • « Publishing failed. The response is not a valid JSON response. » : la requête REST reçoit une réponse non-JSON (souvent du HTML, une page d’erreur PHP, ou une redirection).
  • « Updating failed. The response is not a valid JSON response. » : même problème, déclenché lors d’une mise à jour plutôt qu’une publication initiale.

Contrairement à l’erreur 500 WordPress qui bloque complètement le site, l’erreur « publishing failed » ne touche que l’éditeur : le front-end du site reste accessible, mais vous ne pouvez plus sauvegarder ni publier de contenu.

# Test rapide : vérifier si l'API REST répond correctement
curl -s "https://votre-site.com/wp-json/wp/v2/posts" | head -c 200

# Résultat attendu : commence par [ {"id": ...}
# Résultat problématique : renvoie du HTML (commence par <!DOCTYPE html>)

Diagnostic rapide : identifier la cause en 2 minutes

Avant de corriger, identifiez la cause exacte. Ouvrez la console du navigateur (F12 > onglet Réseau), tentez de publier l’article, et repérez la requête en rouge vers /wp-json/wp/v2/posts. Cliquez dessus et lisez la réponse : elle indique immédiatement si le problème vient d’un plugin (message d’erreur PHP), d’une redirection .htaccess (HTTP 301/302), d’un conflit SSL (erreur de certificat) ou d’un blocage sécurité (HTTP 403).

// Dans la console navigateur, testez l'API REST directement :
fetch('/wp-json/wp/v2/posts')
  .then(r => {
    console.log('Status:', r.status, r.headers.get('content-type'));
    return r.text();
  })
  .then(body => console.log('Body (100 chars):', body.slice(0, 100)))
  .catch(e => console.error('Erreur réseau:', e));

Les 5 causes les plus fréquentes, dans l’ordre de probabilité :

  1. Un plugin de sécurité ou de cache bloque l’API REST (Wordfence, iThemes Security, W3 Total Cache).
  2. Le fichier .htaccess est corrompu ou contient une règle qui intercepte les requêtes REST.
  3. L’URL du site est mal configurée dans les réglages WordPress (http au lieu de https).
  4. Un conflit SSL : le site tourne en HTTPS mais WordPress pense être en HTTP.
  5. Une limite mémoire PHP trop basse provoque une erreur fatale avant la réponse JSON.

Données chiffrées utiles : selon la documentation officielle WordPress, plus de 60 % des erreurs REST proviennent de conflits de plugins ou de règles .htaccess non conformes. Un diagnostic rigoureux en 2 minutes évite des heures de débogage à l’aveugle.

Solution 1 : vérifier et corriger l’URL du site WordPress

Une URL incorrecte dans les réglages de WordPress est la cause numéro un de l’erreur « publishing failed ». Si l’URL WordPress est définie en http:// alors que le site tourne en https://, Gutenberg tente des appels REST vers une URL qui redirige (HTTP 301), ce qui produit exactement ce message d’erreur. WordPress reçoit du HTML de redirection là où il attend du JSON.

Vérifiez dans Réglages > Général : les champs « Adresse du site WordPress » et « Adresse du site » doivent correspondre exactement à l’URL visible dans votre navigateur, protocole compris.

<?php
// Correction directe via WP-CLI si vous n'avez pas accès a l'admin :
// wp option update siteurl "https://votre-site.com"
// wp option update home "https://votre-site.com"

// Ou via wp-config.php (prioritaire sur les reglages en base) :
define('WP_HOME', 'https://votre-site.com');
define('WP_SITEURL', 'https://votre-site.com');

Si votre hébergeur effectue la terminaison SSL devant WordPress (cas fréquent sur cPanel, o2switch, OVH), ajoutez ces lignes dans wp-config.php juste avant /* That's all, stop editing! */ :

<?php
// Force HTTPS quand le SSL est termine par un reverse proxy/CDN
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}
define('FORCE_SSL_ADMIN', true);

Solution 2 : désactiver les plugins et identifier le conflit

Les plugins de sécurité (Wordfence, iThemes Security, All-In-One Security) et certains plugins de cache (W3 Total Cache, WP Super Cache) bloquent parfois l’API REST. Ce blocage peut être intentionnel (option « désactiver l’API REST » cochée par erreur) ou accidentel (règle WAF trop agressive). La méthode la plus fiable consiste à désactiver tous les plugins via FTP, puis à les réactiver un par un.

# Via FTP/SSH : renommer le dossier plugins pour tout désactiver d'un coup
mv wp-content/plugins wp-content/plugins-disabled

# WordPress desactive automatiquement tous les plugins au prochain chargement.
# L'admin reste accessible car WordPress cree les tables en mode sans plugins.

# Via WP-CLI (si accessible) :
wp plugin deactivate --all

# Reactiver un par un pour identifier le coupable :
wp plugin activate nom-du-plugin
# Puis testez la publication apres chaque activation.

Si le problème disparait après désactivation, réactivez les plugins un par un et testez la publication après chaque réactivation. Le dernier plugin activé avant la réapparition de l’erreur est le coupable. Vérifiez ses réglages pour une option « REST API » ou « API REST » et désactivez le blocage.

Solution 3 : régénérer le .htaccess et débloquer l’API REST

Un fichier .htaccess corrompu ou une règle trop restrictive peut intercepter les requêtes vers /wp-json/ et renvoyer une réponse inattendue. Sur Apache (la grande majorité des hébergements mutualisés), WordPress utilise le .htaccess pour les permaliens, et une corruption peut tout bloquer.

# Contenu standard d'un .htaccess WordPress propre :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Pour régénérer proprement le .htaccess :

  1. Renommez l’actuel en .htaccess-backup via FTP.
  2. Dans l’admin WordPress, allez dans Réglages > Permaliens.
  3. Cliquez simplement sur « Enregistrer les modifications » sans rien changer : WordPress recrée un .htaccess propre automatiquement.

Si un plugin de sécurité a ajouté des règles deny from all ou des restrictions sur /wp-json/, supprimez ces lignes. L’API REST WordPress doit rester accessible depuis le serveur et depuis le navigateur de l’utilisateur authentifié. Pour aller plus loin dans la gestion du .htaccess, notre générateur .htaccess WordPress produit un fichier adapté à votre configuration.

Solution 4 : résoudre les conflits SSL et le contenu mixte HTTPS

Le contenu mixte (mixed content) entre HTTP et HTTPS est une cause fréquente et souvent négligée. Si votre site est accessible en HTTPS mais que WordPress pense être en HTTP, le navigateur bloque les requêtes REST pour des raisons de sécurité. Cela se traduit par une erreur ERR_CONNECTION_REFUSED ou un blocage silencieux visible uniquement dans la console navigateur.

<?php
// wp-config.php : forcer HTTPS pour tous les appels WordPress
define('WP_HOME', 'https://votre-site.com');
define('WP_SITEURL', 'https://votre-site.com');

// Verifier la configuration SSL depuis le terminal :
// openssl s_client -connect votre-site.com:443 -servername votre-site.com 2>/dev/null | grep "Verify return"
// Resultat attendu : Verify return code: 0 (ok)

Si vous utilisez Cloudflare, vérifiez que le mode SSL est bien réglé sur Full (strict) et non sur « Flexible ». Le mode Flexible crée une boucle de redirection entre Cloudflare (HTTPS) et votre serveur (HTTP) qui produit exactement l’erreur « the response is not a valid JSON response ».

# Test de l'API REST avec verification SSL depuis le terminal :
curl -k -s "https://votre-site.com/wp-json/wp/v2/types" | python3 -m json.tool | head -10
# L'option -k ignore les erreurs de certificat pour le diagnostic uniquement.
# Si ca marche avec -k mais pas sans, le certificat est invalide ou mal configure.

Solution 5 : augmenter la mémoire PHP et purger les caches

Une limite mémoire PHP trop basse (souvent 32M ou 64M sur les hébergements partagés) peut provoquer une erreur fatale PHP au milieu d’une requête REST. WordPress retourne alors une réponse HTML partielle (contenant le message d’erreur PHP) au lieu du JSON attendu par Gutenberg. Selon Kinsta, WordPress recommande au minimum 128M de mémoire PHP et 256M est préférable pour les sites actifs.

<?php
// wp-config.php : augmenter la memoire disponible pour WordPress
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // Pour les taches admin (import, export, media)

Vous pouvez aussi modifier la limite dans .htaccess ou dans le php.ini de votre hébergeur :

# Dans .htaccess (hebergements Apache avec PHP en module) :
php_value memory_limit 256M

# Dans php.ini ou .user.ini (hebergements avec PHP-FPM) :
memory_limit = 256M

Après avoir corrigé les réglages mémoire, videz impérativement tous les caches : cache WordPress, cache de votre hébergeur (LiteSpeed, Nginx), et cache navigateur. Notre guide sur comment vider le cache WordPress sans plugin détaille 6 méthodes adaptées à chaque situation. Une version ancienne en cache peut masquer vos corrections et faire croire que le problème persiste.

Solution 6 : débloquer l’API REST désactivée dans le code

Certains tutoriels de sécurité recommandent de désactiver l’API REST pour les utilisateurs non connectés. Cette pratique casse Gutenberg si elle est mal implémentée. Vérifiez votre functions.php et vos plugins pour ce type de filtre problématique :

<?php
// Ce filtre (present dans certains tutoriels de securite) casse Gutenberg :
add_filter('rest_authentication_errors', function($result) {
    if (!is_user_logged_in()) {
        return new WP_Error('rest_not_logged_in', 'Acces refuse.', ['status' => 401]);
    }
    return $result;
});

// Solution : supprimer ce filtre ou le limiter aux endpoints publics non essentiels.
// WordPress gere deja les permissions par endpoint nativement.
// Si vous voulez securiser l'API REST, filtrez par namespace specifique :
add_filter('rest_authentication_errors', function($result) {
    if (null === $result && !is_user_logged_in()) {
        $route = $GLOBALS['wp']->query_vars['rest_route'] ?? '';
        // Bloquer seulement les endpoints tiers, pas wp/v2 natif :
        if (!str_starts_with($route, '/wp/v2/') && !str_starts_with($route, '/wp/v3/')) {
            return new WP_Error('rest_forbidden', 'Non autorise.', ['status' => 401]);
        }
    }
    return $result;
});

Le cluster d’articles sur les erreurs WordPress complète ce guide : l’erreur critique WordPress partage plusieurs causes avec « publishing failed » (notamment les conflits de plugins qui provoquent des erreurs fatales PHP), et l’erreur de connexion à la base de données peut aussi déclencher des réponses non-JSON si MySQL est indisponible au moment de la requête REST.

Vérifier que l’API REST WordPress fonctionne correctement

Après toute correction, vérifiez le bon fonctionnement de l’API REST avec plusieurs tests progressifs :

# Test 1 : endpoint de decouverte (doit retourner du JSON, pas du HTML)
curl -s "https://votre-site.com/wp-json/" | python3 -m json.tool | grep '"name"'

# Test 2 : liste des types de contenu (ne requiert pas d'authentification)
curl -s "https://votre-site.com/wp-json/wp/v2/types" | python3 -m json.tool

# Test 3 : verifier les en-tetes de reponse (Content-Type doit etre application/json)
curl -I "https://votre-site.com/wp-json/wp/v2/types"
# Chercher : Content-Type: application/json

# Test 4 : test authentifie avec un mot de passe d'application WordPress
# (Profil utilisateur > Mots de passe d'application)
curl -s -u "votre-login:xxxx xxxx xxxx xxxx xxxx xxxx"   "https://votre-site.com/wp-json/wp/v2/posts?status=draft" | python3 -m json.tool | head -20

Si curl -I retourne Content-Type: text/html au lieu de application/json, l’API REST est interceptée avant que WordPress puisse traiter la requête. C’est un problème de configuration serveur (.htaccess, règles Nginx, plugin de sécurité) à corriger selon les solutions 2, 3 ou 4 ci-dessus.

Pour les installations WordPress sur Nginx (sans .htaccess), vérifiez votre bloc serveur :

server {
    # Regle essentielle pour WordPress sur Nginx :
    # try_files doit inclure /index.php comme fallback pour l'API REST
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Ne bloquez PAS /wp-json/ avec une location specifique.
    # L'API REST passe par /index.php grace a la regle ci-dessus.
    location ~ .php$ {
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Questions fréquentes sur l’erreur WordPress publishing failed

Pourquoi l’erreur « publishing failed » apparait-elle seulement sur certains articles ?

Si l’erreur apparait sur certains articles mais pas d’autres, la cause est souvent liée au contenu : un bloc Gutenberg corrompu, un shortcode qui produit une erreur PHP, ou un média dont l’URL cause un conflit SSL. Ouvrez l’article problématique en mode « Code » (dans le menu contextuel de l’éditeur en haut à droite), copiez le contenu, créez un nouvel article vierge et collez le contenu par sections pour identifier le bloc fautif. Selon la documentation REST API WordPress, certains shortcodes anciens génèrent du HTML non valide qui perturbe la sérialisation JSON.

Comment corriger « publishing failed » sans accès à l’admin WordPress ?

Connectez-vous en FTP, renommez wp-content/plugins en plugins-disabled, et renommez .htaccess en .htaccess-bak. Ces deux actions désactivent les plugins et suppriment les règles de réécriture personnalisées au prochain chargement. Si l’admin redevient fonctionnel, réactivez les plugins un par un (en renommant le dossier) et recréez un .htaccess propre depuis Réglages > Permaliens. Si l’accès FTP n’est pas disponible, WP-CLI permet les mêmes opérations : wp plugin deactivate --all puis wp rewrite flush.

L’erreur « the response is not a valid JSON response » touche-t-elle l’éditeur classique ?

Non. L’éditeur classique (plugin Classic Editor) utilise des requêtes AJAX traditionnelles vers admin-ajax.php, pas l’API REST. L’erreur « publishing failed » est spécifique à l’éditeur Gutenberg (WordPress 5.0 et suivants). Si vous installez le plugin Classic Editor, l’erreur disparait dans l’éditeur, mais l’API REST reste cassée en arrière-plan, ce qui peut affecter WooCommerce, les aperçus de blocs dynamiques, les applications découplées (headless) et les plugins modernes qui dépendent de l’API REST.

Un firewall ou WAF peut-il causer cette erreur ?

Oui. Les WAF de Cloudflare, Sucuri, Wordfence et certains hébergeurs filtrent les requêtes qui ressemblent à des injections (corps de requête contenant du HTML ou du JavaScript). Quand vous publiez un article avec des blocs de code ou des extraits HTML, la requête REST contient exactement ce type de données. Dans les logs du WAF, cherchez les requêtes vers /wp-json/wp/v2/posts bloquées avec le code HTTP 403. La solution consiste à ajouter une exception pour cet endpoint ou à désactiver la règle WAF trop agressive selon la documentation de Cloudflare WAF.

Comment éviter que l’erreur « publishing failed » revienne après correction ?

Maintenez WordPress, vos plugins et votre thème à jour : la majorité des conflits avec l’API REST proviennent de plugins obsolètes incompatibles avec les versions récentes de Gutenberg. Évitez les plugins qui désactivent globalement l’API REST. Testez chaque nouveau plugin sur un environnement de staging avant de l’activer en production. Activez les logs PHP (WP_DEBUG = true + WP_DEBUG_LOG = true dans wp-config.php) : les erreurs fatales PHP y apparaissent avant de se manifester comme « publishing failed » dans l’éditeur. Consultez aussi les guides de WPBeginner et d’Elegant Themes pour des cas supplémentaires documentés.

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.