Commencez par préserver le texte qui n’a pas été enregistré
Vous cliquez sur Enregistrer, Mettre à jour ou Publier, et WordPress annonce que la réponse n’est pas une réponse JSON valide. Le texte reste parfois visible dans l’éditeur, mais cela ne signifie pas qu’il a été enregistré sur le serveur. Avant de recharger la page, de fermer l’onglet ou de vous déconnecter, conservez une copie de votre travail.
Dans le menu de l’éditeur, utilisez la copie de l’ensemble des blocs lorsqu’elle est disponible. Collez le résultat dans un document local que vous pourrez retrouver. Si cette fonction ne répond pas, copiez au minimum le texte, le titre et les éléments récemment modifiés. Notez séparément les réglages importants : image mise en avant, catégories, extrait, statut et adresse prévue.
Pour un contenu complexe, gardez aussi des captures de la mise en page. Elles ne remplacent pas les blocs, mais elles aident à reconstruire une disposition. Vérifiez que votre copie contient réellement le dernier paragraphe rédigé : un presse-papiers vide ou un ancien extrait ne constitue pas une sauvegarde.
Les révisions WordPress peuvent permettre de retrouver des versions déjà enregistrées. Elles ne garantissent pas la récupération de modifications qui n’ont jamais atteint le serveur. Gardez l’onglet original ouvert pendant les premiers contrôles et évitez de lancer des essais directement sur un article publié. Un brouillon de diagnostic permet de travailler sans modifier ce que voient les lecteurs.
Comprenez le message pour choisir la bonne approche
L’éditeur échange des données avec WordPress par son API REST. Pour enregistrer un article, il envoie une demande et attend une réponse structurée au format JSON. Si une page HTML, un avertissement PHP ou un résultat incomplet arrive à la place, l’éditeur peut afficher cette erreur. Le message décrit donc un échange qui a échoué ; il ne désigne pas une cause unique.
Ce n’est pas une demande de convertir votre base de données en JSON. Il n’y a pas non plus de fichier JSON universel à supprimer. Réinstaller WordPress ou effacer des tables avant d’avoir observé la réponse risquerait d’ajouter une panne à un problème parfois limité à une session expirée.
Les trois approches ci-dessous correspondent à des indices différents. Commencez par les contrôles accessibles à votre niveau. Si une étape vous demande des accès que vous ne possédez pas, transmettez les observations à la personne qui administre l’hébergement, sans lui donner une liste de corrections à appliquer au hasard.
- Approche 1 : la panne suit une longue session, un changement d’adresse, une migration HTTPS ou une erreur de route. Vérifiez la connexion, les URL et les permaliens.
- Approche 2 : la réponse contient une page de blocage, une redirection inattendue ou une erreur du serveur. Examinez l’hébergement, le cache et les protections intermédiaires.
- Approche 3 : le problème apparaît avec un bloc précis, après une modification de code ou l’activation d’un composant. Isolez le conflit sur une copie du site.
Délimitez le problème avec un brouillon très simple
Dans un autre onglet, ouvrez la liste des articles et créez un brouillon contenant seulement un titre et une phrase ordinaire. Enregistrez-le comme brouillon, sans le publier. Notez si le problème se produit immédiatement, seulement après ajout d’une image ou uniquement avec le contenu original.
Si le brouillon simple fonctionne, votre compte peut au moins enregistrer ce type de contenu dans ces conditions. Cela oriente vers un élément particulier, une taille de demande ou une opération différente. Ne concluez pas que le serveur fonctionne parfaitement : une règle peut accepter une phrase et refuser un autre contenu.
Si tous les brouillons échouent, vérifiez si un autre utilisateur autorisé rencontre le même problème avec son propre compte. Ne partagez pas vos identifiants pour effectuer ce test. La différence peut venir des droits, de la session ou du navigateur, mais aussi du type de contenu choisi. Comparez donc des actions semblables.
Consultez également Outils, puis Santé du site. Relevez les avertissements concernant l’API REST et les informations utiles sur WordPress, PHP et les composants actifs. Un résultat favorable sur cet écran ne reproduit pas nécessairement l’enregistrement qui échoue dans votre navigateur. Il s’agit d’un indice complémentaire, pas d’un certificat de fonctionnement de toutes les fonctions.
Regardez la réponse reçue, sans modifier les requêtes
Dans Chrome, ouvrez les outils de développement avec F12 ou le menu du navigateur, puis l’onglet Réseau. Sélectionnez le filtre Fetch/XHR si nécessaire. Laissez ce panneau ouvert et reproduisez une seule fois l’enregistrement du brouillon. Repérez la demande correspondante, souvent vers une adresse contenant wp-json ou rest_route.
Ouvrez cette ligne et regardez son URL, sa méthode, son statut, puis l’onglet Réponse. Une sauvegarde d’article peut viser une route d’articles ou de pages, tandis qu’un envoi d’image utilise une autre route. Choisissez la demande liée à l’action, pas simplement la première ligne rouge. Relevez son heure pour la comparer aux journaux de l’hébergeur.
Un statut HTTP 200 ne suffit pas : le contenu reçu peut être une page HTML alors que l’éditeur attend du JSON. À l’inverse, un message d’erreur correctement structuré peut expliquer un refus précis. Si vous voyez une page de connexion, une page de sécurité ou le début d’un avertissement PHP, gardez cette information.
Vous n’avez pas besoin de modifier ou de rejouer manuellement la requête. Ne publiez pas une exportation complète du trafic : elle peut contenir des cookies, des jetons et le texte privé du brouillon. Pour demander de l’aide, partagez uniquement les éléments nécessaires, après retrait de ces valeurs.
Approche 1 : rétablir une session de connexion utilisable
Après avoir conservé votre texte, ouvrez la connexion WordPress habituelle dans un nouvel onglet. Vérifiez le domaine et le compte affiché. Si la session a expiré, reconnectez-vous normalement. Revenez ensuite à l’éditeur et rechargez-le seulement lorsque vous êtes certain de pouvoir retrouver les modifications non enregistrées.
WordPress utilise la session et un jeton de protection appelé nonce pour les demandes de l’éditeur. Un jeton absent ou devenu invalide peut faire échouer une opération même si une ancienne page d’administration reste affichée. La reconnexion et le rechargement propre de l’éditeur permettent de repartir d’une session actuelle ; ils ne corrigent pas une permission manquante.
Si l’échec reste limité à votre navigateur, essayez un profil distinct ou une fenêtre privée dans laquelle vous vous connectez au site. Ce test aide à comparer l’état du navigateur. Il ne prouve pas à lui seul quel réglage est responsable. Si vous effacez ensuite les données du site, prévoyez que cela vous déconnectera et préservez d’abord le travail local.
Une extension du navigateur peut aussi intervenir dans une page. Testez son effet de façon ciblée si les observations la désignent, puis remettez vos réglages habituels. Ne transformez pas une exception de diagnostic en abandon permanent des protections du navigateur.
Vérifiez les adresses, notamment après une migration HTTPS
Dans Réglages, puis Général, comparez l’adresse de WordPress et celle du site avec l’installation attendue. Recherchez une ancienne adresse, un domaine de préproduction ou un protocole incohérent. Comparez aussi l’adresse de la requête en échec : une administration ouverte sur un domaine peut envoyer sa demande vers un autre emplacement à cause d’une configuration incomplète.
Ne rendez pas automatiquement les deux champs identiques. WordPress peut être installé dans un sous-répertoire tout en affichant le site à la racine. Cette organisation est valide lorsqu’elle est configurée correctement. Les constantes de configuration et le multisite peuvent également modifier la manière dont les adresses sont gérées.
Avant de corriger une URL, notez les valeurs actuelles et assurez-vous de disposer d’un accès à l’hébergement pour revenir en arrière. Une mauvaise adresse peut vous faire perdre l’accès au tableau de bord. Si vous ne savez pas quelle organisation était prévue, faites confirmer la correction par l’hébergeur ou la personne qui a réalisé la migration.
Le certificat HTTPS, les redirections et la configuration du serveur doivent être cohérents avec l’adresse retenue. Ne désactivez pas la vérification des certificats pour faire disparaître l’erreur. Après une correction, reconnectez-vous sur l’adresse définitive et reprenez le même test de brouillon.
Ne régénérez les permaliens que si les routes sont en cause
Une réponse 404 sur la route REST peut signaler que le serveur ne transmet pas cette adresse à WordPress. Le chemin courant est /wp-json/, mais une installation sans permaliens réécrits peut utiliser ?rest_route=/. Utilisez l’adresse réellement employée par le site au lieu de conclure à une panne à partir d’un chemin deviné.
Lorsque les indices pointent vers les règles de réécriture, ouvrez Réglages, puis Permaliens. Notez la structure actuelle et enregistrez-la sans en choisir une autre. Cela permet à WordPress de régénérer ses règles dans les conditions prévues par l’installation. Changer la structure des articles n’est pas nécessaire pour ce diagnostic.
Si WordPress demande une intervention sur la configuration du serveur, ne remplacez pas tout le fichier par un exemple générique. Un hébergement peut contenir des règles supplémentaires nécessaires. Sur Nginx, une modification de .htaccess ne corrige pas les règles du serveur ; faites vérifier la configuration adaptée par le prestataire.
L’ouverture de la racine REST dans le navigateur vérifie seulement une lecture de cette adresse. Elle ne valide pas l’écriture authentifiée d’un article. Après correction, revenez au brouillon et essayez l’action qui échouait. C’est ce résultat qui permet de juger l’effet de la modification.
Approche 2 : identifier le blocage côté serveur ou pare-feu
Si la réponse montre une page de protection, relevez son identifiant de requête, l’heure et le chemin concerné. Consultez les événements de sécurité de l’hébergeur ou du service placé devant le site. Le but est de retrouver la règle qui a traité cette demande, pas de désactiver toutes les protections pour voir si l’éditeur recommence à fonctionner.
Un pare-feu peut considérer un extrait de code, une chaîne particulière ou un volume de données comme suspect. Sur un brouillon de test, comparez un contenu simple avec le contenu qui provoque l’échec. Si une différence reproductible apparaît, fournissez un exemple réduit au support. N’envoyez pas un article confidentiel entier lorsque quelques caractères suffisent au diagnostic.
Demandez une correction limitée à la règle ou à la situation légitime identifiée. Une exception trop large sur toutes les routes REST pourrait affecter d’autres fonctions. Les protections, les droits WordPress et la validation des données doivent rester actifs. Un changement utile doit être vérifiable et réversible.
Une réponse 401 ou 403 peut également venir de WordPress et des droits du compte, sans intervention d’un pare-feu externe. Lisez le contenu de la réponse avant de demander une exception. Donner le rôle administrateur à tous les auteurs ne constitue pas une correction de l’éditeur.
Distinguez cache, taille excessive et incident de service
Une règle de cache trop large peut servir une réponse qui ne correspond pas à l’utilisateur ou à l’action. Faites vérifier le traitement de l’administration, des utilisateurs connectés et des opérations d’écriture. Purger un cache peut servir à confirmer un indice, mais une règle inadaptée recréera le problème dès qu’une nouvelle réponse sera mise en cache.
Si vous recevez un statut 413, la taille de la demande dépasse une limite acceptée par un composant du trajet. Comparez un petit brouillon avec le contenu concerné, ou une petite image avec celle qui échoue. Une limite peut se trouver dans le serveur web, PHP, un proxy ou le service de protection ; modifier une valeur WordPress ne change pas forcément cette limite.
Pour une erreur 500, 502 ou 503, donnez au support l’heure exacte et la route. Une panne de service, une erreur PHP ou une ressource indisponible peut renvoyer une page d’erreur à la place du résultat attendu. Le statut oriente la recherche, mais ne suffit pas à attribuer la panne à une extension.
Après une correction de limite, utilisez un fichier et un contenu de taille réaliste. Après un incident temporaire, vérifiez que plusieurs enregistrements espacés fonctionnent. Gardez votre copie locale tant que la persistance du brouillon n’a pas été confirmée.
Approche 3 : isoler un conflit de bloc, de thème ou d’extension
Privilégiez une copie de préproduction récente pour les essais qui changent les composants du site. Vérifiez qu’elle possède sa propre base et qu’elle ne déclenche pas les envois ou les paiements de la production. Sauvegardez les fichiers et la base avant toute désactivation importante. L’objectif est de pouvoir revenir exactement à l’état de départ.
Si seul un article complexe échoue, recopiez son contenu dans un brouillon de test. Retirez un groupe de blocs, puis répétez l’enregistrement. Procédez par étapes pour réduire l’exemple qui déclenche le problème. Conservez le contenu original ailleurs : supprimer un bloc du seul exemplaire disponible ferait perdre l’information nécessaire à la réparation.
Sur la copie, commencez par le composant récemment modifié ou lié au bloc suspect. Désactivez-le normalement depuis l’administration, testez, puis réactivez-le avant d’en examiner un autre. Un retour à la normale établit une relation utile, mais le conflit peut impliquer deux composants. Notez leurs versions et les conditions exactes de reproduction.
Un essai avec un thème standard compatible peut compléter cette recherche sur la copie. Une différence de résultat ne signifie pas forcément que tout le thème est inutilisable : une fonction personnalisée ou une intégration peut être responsable. Ne changez pas brusquement le thème d’une boutique publique simplement pour obtenir ce diagnostic.
Corrigez une sortie parasite sans masquer une erreur persistante
Si la réponse commence par du HTML ou un avertissement PHP avant les données, faites rechercher le code qui produit cette sortie. Un composant peut afficher du contenu au mauvais moment, y compris pendant une demande REST. Le nom d’un fichier dans le message et l’heure du test aident à retrouver le traitement concerné.
Consultez d’abord les journaux privés disponibles chez l’hébergeur. Si un diagnostic WordPress temporaire est nécessaire, faites conserver les erreurs dans un emplacement protégé, sans les afficher aux visiteurs. Un fichier de journal accessible publiquement peut révéler des chemins ou des informations internes. Retirez les réglages temporaires après l’intervention.
Masquer les avertissements dans la réponse peut éviter qu’ils perturbent son format, mais il faut aussi corriger leur cause. Une erreur fatale, par exemple, peut empêcher l’opération de se terminer même si son texte n’est plus visible. Faites tester la correction du composant sur la copie avant son installation en production.
N’ajoutez pas un extrait de code qui désactive l’API REST, les contrôles de nonce ou les permissions pour contourner le message. L’éditeur dépend précisément de ces échanges et de leurs autorisations. Un plugin de dépannage n’est pas indispensable ici : le navigateur, Santé du site et les outils de l’hébergement permettent déjà de réunir les principaux indices.
Confirmez que le contenu est réellement conservé
Enregistrez le brouillon de test, puis rouvrez-le depuis la liste des articles dans un nouvel onglet. Vérifiez la dernière phrase et les réglages modifiés. Ajoutez ensuite un élément représentatif de votre travail habituel, comme une image ou le bloc qui posait problème, et répétez le contrôle.
Reprenez enfin le contenu original à partir de votre copie préservée. Vérifiez son statut avant de valider : un essai de sauvegarde ne doit pas publier un brouillon par surprise. Si l’article est déjà public, relisez l’aperçu et faites la mise à jour lorsque les modifications sont prêtes à être vues.
Consignez la cause retenue, le réglage corrigé et les essais réussis. Rétablissez les composants utilisés pendant le diagnostic et retirez les exceptions temporaires devenues inutiles. Si la panne revient, ce relevé permettra de comparer les situations. Le dépannage est terminé lorsque le contenu attendu est enregistré, retrouvé et utilisable avec les droits et les protections normaux du site.
