Identifier une erreur d’écriture plutôt qu’un refus général
Vous ouvrez Ajouter un article ou tentez de conserver un nouveau brouillon, puis WordPress annonce qu’il ne peut pas insérer l’article dans la base. Les anciens contenus peuvent rester visibles. L’objectif est de retrouver la création et la conservation d’un document, après avoir identifié la cause de l’écriture refusée.
Relevez le message exact, l’action et l’heure. Une erreur générale de publication, une réponse JSON non valide et une erreur de connexion à la base ne désignent pas le même stade. Ne concluez pas à une table endommagée uniquement parce que le texte contient le mot « base ».
La création d’un nouveau contenu et la modification d’un contenu existant utilisent des opérations différentes. WordPress peut aussi créer un brouillon automatique lors de la préparation de l’éditeur. Une erreur peut donc survenir avant même que vous ayez écrit le titre du nouvel article.
Si la connexion à la base échoue sur tout le site, suivez d’abord ce dépannage spécifique. Ce guide vise surtout une écriture qui échoue dans un environnement encore partiellement accessible. Une page publique servie depuis une copie en cache ne prouve pas que la base répond normalement au même moment.
Préserver le texte et éviter les tentatives répétées
Gardez l’onglet qui contient la rédaction et copiez le texte accessible dans un fichier local. Préservez le titre, l’extrait et les réglages importants. Si les commandes de copie de l’éditeur fonctionnent, utilisez-les puis vérifiez le passage le plus récent, pas seulement la première ligne.
Avant de relancer, ouvrez la liste administrative des articles dans un autre onglet. Cherchez si un brouillon identifiable a été créé malgré le message. N’enregistrez pas depuis plusieurs onglets concurrents. Une réponse incomplète ne permet pas d’affirmer qu’aucune donnée n’a été écrite.
Évitez d’ouvrir dix fois Ajouter un article ou de republier une copie pour voir si l’une fonctionne. Ces essais peuvent créer des états intermédiaires et rendre le diagnostic confus. Gardez un seul cas de contrôle clairement nommé lorsqu’un essai d’écriture sera nécessaire.
Avant toute intervention sur la base ou un composant, demandez une sauvegarde récupérable de la base et des fichiers. Sur une installation active, notez les données récentes à préserver. Restaurer un ancien site complet pour corriger une création d’article pourrait supprimer des informations sans rapport avec cet échec.
Comparer un nouveau brouillon et un document existant
Avec les droits nécessaires, observez si l’échec se produit dès l’ouverture d’un nouvel article ou seulement à son premier enregistrement. Comparez aussi l’ouverture d’une page et celle d’un contenu existant. Commencez par lire, sans modifier une page publique uniquement pour tester l’écriture.
Si un essai est autorisé, utilisez un brouillon de contrôle contenant un titre et une phrase ordinaires. Gardez son statut en brouillon. Notez si sa création, sa sauvegarde et sa réouverture réussissent. Un résultat correct avec ce cas n’exclut pas un problème lié à un bloc, un champ ou un traitement particulier du document initial.
Relevez WordPress autohébergé ou WordPress.com, la version, le type de contenu et le dernier changement : migration, restauration, modification d’extension ou intervention d’hébergement. En multisite, identifiez le site concerné ; les autres sites ne prouvent pas que sa propre table ou sa configuration sont correctes.
L’accès à la rédaction ne donne pas les droits d’administration du serveur de base. Sur WordPress.com ou un hébergement administré, transmettez ces comparaisons au support lorsque les contrôles techniques ne sont pas accessibles. Le diagnostic peut avancer sans distribuer des identifiants de base aux rédacteurs.
Vérifier si un brouillon a déjà été enregistré avec WP-CLI
Si vous avez accès à WP-CLI, vérifiez le résultat côté site avant de recréer l’article. Depuis le dossier WordPress, remplacez l’adresse par celle du site concerné, notamment en multisite. Cherchez un titre distinctif. La commande lit les brouillons et affiche leur identifiant sans créer de contenu.
Comparez le titre et l’identifiant avec l’éditeur. Si vous trouvez le brouillon attendu, ouvrez-le depuis la liste des articles et vérifiez qu’il contient votre texte. Le filtre cherche dans les brouillons et peut retourner plusieurs correspondances. Une liste vide peut aussi venir d’un titre modifié ou d’un autre statut. Vérifiez alors les autres filtres de la liste avant de recommencer la création.
wp --url=https://exemple.test post list --post_type=post --post_status=draft --s='Titre du brouillon' --fields=ID,post_title,post_statusChoisir le parcours selon l’erreur démontrée
Le premier parcours confirme ce que l’interface et la demande ont réellement produit. Il sert à distinguer un refus de session, une réponse remplacée et un échec d’insertion signalé par WordPress. Il évite de modifier la base avant d’avoir identifié le stade de la panne.
Le deuxième examine un composant qui intervient dans la création du document. Il devient pertinent si le problème suit une mise à jour, ne touche qu’un type de contenu ou apparaît avec certaines données. Les essais se font sur une copie séparée.
Le troisième relève de l’hébergement ou de l’administration de la base. Choisissez-le si les journaux désignent un droit d’écriture, un stockage saturé, une lecture seule ou une anomalie de structure. Il nécessite une personne capable de préserver les données et d’appliquer la correction adaptée au serveur réel.
Ces parcours peuvent se rejoindre. Une extension peut tenter une écriture dans sa propre table et recevoir un refus du serveur. Gardez le nom de la table et le message pour distinguer l’étape qui échoue ; changer les droits WordPress du rédacteur ne résout pas automatiquement une permission du compte de base.
Approche 1 — Lire la requête qui échoue dans l’éditeur
Ce parcours convient à la personne qui rédige ou assiste la rédaction. Préservez d’abord le texte déjà saisi. Sur la copie, utilisez un seul brouillon avec un titre distinct. Dans le navigateur, ouvrez les outils de développement puis **Réseau** avant l’essai. Gardez le journal pendant le changement de page, ouvrez **Articles → Ajouter un article**, puis essayez une seule fois d’enregistrer le brouillon. Notez si l’échec arrive à l’ouverture, avant toute rédaction, ou au moment de la sauvegarde.
Si l’éditeur s’ouvre, relevez l’identifiant visible dans son adresse ou dans la liste des articles. WordPress peut déjà avoir créé un brouillon automatique à l’ouverture. Dans **Réseau**, repérez la demande à l’heure où vous avez enregistré. Pour un article natif de l’éditeur de blocs, elle peut viser la route REST /wp/v2/posts ou la route qui se termine par l’identifiant d’un article. Une route de sauvegarde automatique a un autre rôle. Si l’ouverture elle-même échoue, regardez aussi la demande du document d’administration. Gardez la méthode, le chemin utile, l’heure, le statut HTTP et le type de réponse. Ne diffusez ni les paramètres d’authentification ni le contenu de l’article.
Vérifiez enfin dans la liste des articles si un brouillon correspondant existe déjà. Une réponse qui s’interrompt après l’écriture peut faire croire à un échec complet. Si le brouillon existe, reprenez-le et contrôlez son contenu avant une nouvelle tentative. Si vous trouvez un problème de session ou d’accès, reprenez l’essai dans une session normale et conservez le même contrôle. Le résultat attendu est un brouillon identifiable que vous pouvez rouvrir, avec le texte de test et le statut voulus.
- Si la réponse contient une page HTML de connexion ou de protection à la place de la réponse attendue, vérifiez d’abord la session, le bon domaine ou la règle du service intermédiaire avec son responsable. Un code HTTP seul peut masquer cette différence.
- Si WordPress répond en JSON avec
rest_invalid_json, c’est la demande JSON que WordPress n’a pas pu lire. L’alerte d’interface « réponse JSON non valide » peut aussi apparaître lorsque le navigateur reçoit autre chose que le JSON attendu. Comparez la réponse réelle avant de relier ces deux messages. - Si la réponse comporte
rest_cannot_create, comparez le compte et le type de contenu. Avec un code 403 et une page HTML, le même nombre peut venir d’une protection avant WordPress. Gardez le code WordPress lorsqu’il existe. - Si la réponse contient
db_insert_error, rapprochez-la de la trace WordPress ou du journal de base. Ce code indique que l’insertion a échoué dans ce parcours. À lui seul, il ne dit pas si la cause est un refus d’écriture, une validation, une limite ou une contrainte.
Distinguer le droit WordPress du droit de la connexion de base
Avec le responsable du site, comparez le compte affecté et un compte autorisé à créer le même type de contenu. Faites ce contrôle avec deux sessions séparées, sur le bon site et avec le même type d’article. Dans **Utilisateurs**, l’administrateur peut relever le rôle sans le modifier. Sur un site où les capacités ont été personnalisées, le nom du rôle est un indice. Faites vérifier la capacité de création pour le type de contenu visé. Pouvoir créer un brouillon et pouvoir le publier sont deux permissions à distinguer.
Si seul le compte concerné reçoit rest_cannot_create et que l’autre peut enregistrer, corrigez son accès uniquement si la création fait partie de son rôle. Sinon, faites enregistrer le brouillon par une personne déjà habilitée. Vérifiez ensuite le même accès et gardez l’ancien réglage si une correction a été appliquée. Un changement général du rôle ou un passage temporaire de tous les comptes en administrateur ne vous aiderait pas à identifier l’écriture refusée.
Si un compte autorisé atteint la base et rencontre encore un refus, transmettez la trace au responsable de l’hébergement. Le compte de connexion SQL peut lire une table tout en étant privé d’insertion, ou être relié à une instance prévue pour la lecture. Le responsable peut vérifier la destination et les droits effectifs de la connexion qui sert WordPress. Sur MySQL ou MariaDB, il doit tenir compte du compte réellement utilisé, de ses rôles éventuels et de l’instance qui reçoit la demande. Il ne suffit pas de tester avec une session d’administration SQL plus privilégiée.
Confirmer la cause SQL avec une trace de la même écriture
Pour le responsable technique, le relevé doit associer la demande d’enregistrement et la bonne opération sur la base. Rapprochez l’heure avec son fuseau, le site, le type de contenu, l’identifiant éventuel et le code de réponse. Recherchez ensuite le message du moteur ou de WordPress pour cet essai. Une trace relative à une autre extension ou à une tâche de fond peut arriver à la même minute. Si elle concerne une autre table ou une autre action, conservez-la séparément tant que le lien avec l’article n’est pas démontré.
Si la trace indique un refus d’insertion ou une connexion en lecture seule, identifiez le serveur qui reçoit l’écriture et vérifiez que cette destination est censée accepter les modifications. Le test d’une lecture sur la même connexion est utile pour distinguer un défaut total d’accès d’une restriction d’écriture. Pour un refus lié à une clé, une contrainte ou une taille de valeur, comparez plutôt la donnée minimale et le schéma attendu. Commencez par l’inspection et la sauvegarde. Une correction de données ou de structure demande une procédure testée sur copie, à partir du message exact et du moteur en service.
Demandez que les constats soient conservés hors du site public. Dans le relevé partagé, gardez le code, le type d’opération et la table ou le champ si cela aide le responsable. Masquez les identifiants de connexion et le texte privé. Pour le prochain essai, utilisez un brouillon distinct après avoir vérifié que la tentative précédente n’a laissé aucun document à reprendre. Un test qui réussit doit être suivi de la réouverture et d’une modification contrôlée du même brouillon.
Approche 2 : isoler un composant sur une copie
Si l’échec suit une modification d’extension ou ne concerne qu’un type de contenu, préparez une préproduction séparée avec une base propre à la copie. Protégez son accès et neutralisez ses courriels et intégrations externes. Conservez une sauvegarde avant toute modification de composant.
Reproduisez d’abord le cas minimal dans cet environnement. Si la panne n’y existe pas, comparez les versions, les règles d’hébergement et la configuration, sans remplacer la production par la copie. Une différence d’environnement peut expliquer le résultat.
Si le cas se reproduit, isolez le composant désigné par le journal ou le changement récent. Désactivez-le normalement, créez un brouillon de contrôle puis réactivez-le avant l’essai suivant. Ne supprimez pas ses données. Une extension peut ajouter des champs ou écrire dans ses propres tables ; le document principal et ce traitement complémentaire doivent être distingués.
Si la création revient, transmettez ce résultat au développeur avec les versions et un exemple minimal autorisé. Le correctif doit traiter son écriture ou sa compatibilité, pas seulement masquer le message. Si rien ne change, rétablissez l’état initial et poursuivez avec le responsable de la base. Une désactivation générale sur le site actif n’est pas nécessaire pour commencer cette comparaison.
Approche 3 : vérifier les droits d’écriture et la destination
Le responsable de l’hébergement doit confirmer le serveur et la base réellement utilisés pour cette écriture. Après une migration ou une restauration, une application peut atteindre une destination qui permet la lecture sans être celle prévue pour les modifications. Cette vérification précède les changements de permissions.
Le compte de base et le compte WordPress sont différents. Les privilèges de lecture, d’insertion et de mise à jour ne sont pas identiques. Un résultat correct pour un ancien article ne prouve donc pas que la création d’une nouvelle ligne est autorisée.
Si le message désigne un refus de privilège, faites vérifier le compte et le périmètre concernés. Demandez les droits adaptés à l’installation, sans donner des privilèges d’administration globale au site pour débloquer un seul essai. Conservez les valeurs initiales et la raison de la correction.
Si le serveur est volontairement en lecture seule, faites identifier le rôle de cette instance et le trajet attendu des écritures. Ne désactivez pas ce mode sur une copie de réplication pour contourner le problème. L’administrateur doit corriger la destination ou la configuration appropriée, puis vérifier que les autres sites et traitements gardent leur fonctionnement prévu.
Faire contrôler le stockage et les limites réellement atteintes
Une erreur de stockage demande de vérifier l’espace disponible et les quotas du service de base, pas seulement l’espace annoncé pour les fichiers du site. Les journaux, fichiers temporaires ou espaces de tables peuvent dépendre d’un stockage distinct. Le support doit relever la ressource effectivement saturée.
Le comportement dépend aussi du moteur et de la version du serveur. Sur MySQL, une erreur d’espace dans un espace de tables InnoDB peut annuler l’opération concernée. D’autres situations ont des comportements différents ; ne supposez pas qu’un rechargement ou une attente fixe résoudra tous les cas.
Ne supprimez pas des articles, des tables ou des fichiers du serveur pour libérer de l’espace sans inventaire et sauvegarde. Faites choisir une action ciblée par l’hébergeur. Une augmentation de capacité ou un nettoyage documenté doit être suivi d’un contrôle de l’écriture, pas seulement d’une jauge moins remplie.
Si les journaux désignent une limite d’échange ou de taille, demandez quelle valeur est réellement atteinte et pour quelles données. Un texte court qui passe et un contenu particulier qui échoue fournissent un cas à comparer. Augmenter toutes les limites du serveur sans ce diagnostic pourrait déplacer le problème sans expliquer sa cause.
Examiner le champ ou la structure seulement si l’erreur les désigne
Une valeur refusée peut concerner un champ particulier, son type ou sa longueur autorisée. Conservez l’exemple minimal qui déclenche le message, sans retirer des caractères du document original pour le faire entrer de force. Le responsable doit comparer les données envoyées et la définition du champ visé.
Les champs n’ont pas tous le même rôle ni les mêmes limites. Une extension peut écrire ailleurs que dans le corps de l’article. Une erreur désignant son propre champ ne justifie pas d’agrandir toutes les colonnes WordPress ou de transformer toutes les tables.
Après une migration, un message de structure ou de clé demande une comparaison avec le schéma attendu pour la version et le composant concernés. Faites confirmer la bonne base, la bonne table et son préfixe. N’appliquez pas une modification trouvée pour une autre installation, même si son nom de table ressemble.
Une erreur de clé ne doit pas être traitée en supprimant les lignes jugées gênantes ou en renumérotant les identifiants. Ces valeurs peuvent relier d’autres données au document. Si un correctif de structure est confirmé, testez-le sur copie avec sauvegarde et plan de retour. Les procédures doivent correspondre au serveur réel, notamment à sa version et à son moteur de stockage.
Préparer une correction limitée et un vrai retour arrière
Demandez au responsable de décrire le changement prévu : rétablir un privilège, corriger une destination, libérer une ressource ou appliquer une migration documentée. Le résultat doit répondre à l’erreur relevée. Une optimisation générale de base ne remplace pas ce choix.
Avant l’intervention, préservez les paramètres et les données concernés. Pour une modification de structure, une sauvegarde vérifiée et un essai sur copie sont essentiels. Une simple désactivation du composant ou un redémarrage ne ramène pas automatiquement la base à son état antérieur.
Si des données doivent être récupérées depuis une sauvegarde, faites d’abord examiner cette copie dans un environnement isolé. Préservez les créations récentes du site actif. Ne réimportez pas toute une ancienne base pour remplacer une table sans avoir évalué ses relations et les informations qui seraient perdues.
Gardez les protections du site pendant le diagnostic. N’activez pas une page de réparation publique ou un mode de récupération forcée sans procédure spécialisée adaptée. Si l’erreur ne concerne pas une corruption démontrée, ces outils peuvent être inutiles. Le retour arrière doit annuler le changement précis, avec ses conséquences connues, et non tenter une restauration globale après un essai mal préparé.
Comparer quatre réponses dans une recette locale
La recette a appelé les routes natives de WordPress 7.1.4 sur une installation SQLite jetable. Un corps de requête JSON incomplet a renvoyé **400** et rest_invalid_json. Un compte abonné connecté, dépourvu de capacité de création pour les articles ordinaires, a reçu **403** et rest_cannot_create. Ces deux réponses n’ont donné ni identifiant de nouvel article ni message d’erreur de SQLite.
Avec un compte éditeur autorisé, la connexion SQLite de la copie a été placée temporairement en lecture seule. La lecture de contrôle a réussi, mais la création a renvoyé **500** et db_insert_error, avec le message du moteur indiquant une tentative d’écriture sur une base en lecture seule. Après rétablissement de l’écriture, la recette a provoqué un refus SQL limité à l’insertion d’un titre fictif. La même réponse WordPress est apparue, mais le journal de la connexion portait le signal distinct du refus ciblé. Pendant ce refus, la mise à jour d’un autre brouillon est restée possible. Aucun des deux essais refusés n’a créé la ligne attendue.
Après retrait de ces conditions de test, la création a renvoyé **201**. La mise à jour a renvoyé **200** pour le même identifiant, puis la relecture a retrouvé le nouveau texte. La fonction que WordPress utilise pour préparer l’éditeur a aussi créé un autre document au statut auto-draft. Ces résultats concernent les fonctions et routes de WordPress sur SQLite. Sur un site MySQL ou MariaDB, le message du moteur et le contrôle des permissions dépendent de la connexion réelle.
Après la correction sur votre copie, reproduisez les deux actions qui vous intéressent. Ouvrez un nouvel article si c’est là que l’erreur commençait, puis enregistrez un brouillon identifiable. Rouvrez-le et changez une seule phrase. Vérifiez son identifiant, son statut et le nouveau texte dans l’éditeur après rechargement. Si la création réussit mais que la mise à jour échoue, gardez les deux relevés et reprenez le diagnostic de la seconde écriture.
Vérifier la création puis transmettre les réserves restantes
Après correction, créez un unique brouillon de contrôle clairement nommé, avec un titre et une phrase. Enregistrez-le puis rouvrez-le depuis la liste administrative. Vérifiez qu’il possède une identité propre, que le texte est conservé et que vous retrouvez le même document au chargement suivant.
Ajoutez ensuite, sur ce cas de test, l’élément représentatif qui déclenchait l’échec : champ, bloc ou donnée autorisée. Contrôlez de nouveau la conservation. Une création simple réussie ne valide pas automatiquement les traitements complémentaires de l’article initial.
Réintroduisez la rédaction préservée dans le document approprié et vérifiez le statut avant de publier ou de mettre à jour. Rétablissez les composants nécessaires et retirez les diagnostics temporaires. Faites relire les journaux à l’heure des derniers essais pour confirmer que l’erreur initiale ne revient pas.
Si le défaut subsiste, transmettez le message nettoyé, l’heure, le type de contenu, les versions, le dernier changement et les comparaisons effectuées. Précisez ce qui fonctionne encore et ce qui a été remis à l’état initial. Conservez la réserve tant qu’aucune cause n’est démontrée. Pour la suite, vérifiez une création et un enregistrement après les migrations ou modifications qui touchent les données, avec une sauvegarde adaptée et sans publier un doublon de contrôle.
