WordPress erreur 422 : corriger Unprocessable Content

Vous envoyez un formulaire WordPress, la requête part bien, puis le serveur répond « 422 Unprocessable Content ». Pour corriger une WordPress erreur 422, vérifiez d’abord les champs et leur format, puis la réponse JSON, le nonce, la route REST et les règles de validation du plugin concerné. Le code 422 signifie que le serveur a compris la requête, mais ne peut pas traiter les données qu’elle contient. Il ne s’agit donc ni d’un simple problème de connexion ni d’une panne générale du site.

Ce diagnostic est souvent rassurant. Une erreur 422 protège parfois la base de données en refusant une valeur incomplète ou incohérente. La bonne méthode consiste à lire le message retourné, reproduire l’appel avec un contenu minimal et corriger le champ précis qui échoue.

Que signifie une WordPress erreur 422 ?

Le statut HTTP 422, appelé Unprocessable Content dans la spécification actuelle, indique que la syntaxe de la requête est correcte, mais que son contenu ne peut pas être accepté. L’ancien libellé Unprocessable Entity reste très présent dans les serveurs, les bibliothèques et les recherches. La différence avec une erreur 400 est importante. Un 400 signale généralement une requête mal formée. Un 422 signale plutôt une donnée lisible, mais invalide selon les règles de l’application.

Dans WordPress, le statut peut être produit par la REST API, WooCommerce, un plugin de formulaire, une extension de sécurité ou un endpoint personnalisé. Un champ obligatoire absent, une valeur hors liste, un identifiant inexistant ou un contenu refusé par une règle métier sont des causes classiques. Le serveur a reçu la demande. Il faut donc chercher la validation qui l’a rejetée.

Le code 422 n’est pas une preuve d’intrusion et ne se corrige pas en augmentant la mémoire PHP. Notez l’URL, la méthode HTTP, le statut, le corps de réponse et l’heure du test. Ces cinq informations permettent de séparer une validation WordPress d’un blocage du WAF ou d’un proxy.

Lire la réponse avant de modifier le site

Commencez dans les outils de développement du navigateur. Ouvrez l’onglet Réseau, reproduisez l’action une seule fois et sélectionnez la requête en rouge. Contrôlez l’URL, la méthode, le type de contenu et l’onglet Réponse. Une route /wp-json/ renvoie souvent un objet JSON contenant un code, un message et parfois des détails sur le champ fautif.

curl -i -sS --max-time 20 
  -H 'Accept: application/json' 
  'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'

Ne copiez pas publiquement les cookies, les nonces, les mots de passe ou les jetons. Si la réponse est une page HTML signée par un CDN ou un pare feu, le 422 peut venir d’une couche en amont. Si elle est structurée en JSON avec un message WordPress, remontez plutôt vers la route, le plugin et ses règles.

La documentation MDN rappelle qu’une répétition identique d’une requête 422 échoue normalement de la même manière. Il faut modifier la donnée ou le contexte, pas simplement cliquer plusieurs fois sur Envoyer.

Corriger les champs invalides dans la REST API

La REST API WordPress accepte des schémas précis pour ses ressources. Pour un article, le titre, le contenu, le statut, les catégories et les métadonnées n’ont pas tous les mêmes formats. Une chaîne envoyée à la place d’un entier, une date impossible ou une valeur non autorisée peut déclencher une validation.

Réduisez l’appel au strict nécessaire, puis ajoutez les champs un par un. Cette méthode évite de chercher une erreur dans un objet JSON de plusieurs centaines de lignes. Pour une création de contenu, commencez par un titre et un contenu simples. Ajoutez ensuite l’extrait, les catégories et les champs personnalisés.

curl -i -sS -X POST 'https://exemple.fr/wp-json/wp/v2/posts' 
  -H 'Content-Type: application/json' 
  -H 'Accept: application/json' 
  --user 'utilisateur:mot-de-passe-application' 
  --data '{"title":"Test 422","content":"Contenu court","status":"draft"}'

Un appel de test doit utiliser un compte et un environnement adaptés. Ne placez jamais un mot de passe d’application dans un script partagé ou un historique de terminal exposé. Si cet appel minimal fonctionne, comparez les champs de votre requête initiale. Le coupable est souvent une valeur vide, un tableau mal formé ou un identifiant supprimé.

Pour connaître les paramètres réellement disponibles, consultez la réponse de la collection et la documentation de la route. Les extensions peuvent ajouter leurs propres champs et modifier les règles d’autorisation. Un champ accepté dans un site de test peut être refusé en production si la version du plugin ou sa configuration diffère.

Vérifier le JSON, les types et l’encodage

Un JSON peut être syntaxiquement valide tout en contenant des types incorrects. La valeur 12 n’est pas équivalente à la chaîne 12 dans toutes les validations. Un tableau, un objet et une chaîne ne sont pas interchangeables. Contrôlez aussi les caractères invisibles, les guillemets typographiques et les retours à la ligne ajoutés par un éditeur.

python3 - <<'PY'
import json
from pathlib import Path

payload = json.loads(Path('payload.json').read_text())
print(json.dumps(payload, ensure_ascii=False, indent=2))
PY

Si vous construisez une requête en PHP ou en JavaScript, utilisez l’encodeur natif du langage. Évitez de fabriquer du JSON par concaténation. Avant l’envoi, vérifiez que les champs obligatoires existent et que les nombres, booléens et tableaux ont le bon type.

const payload = {
  title: 'Brouillon de test',
  content: 'Texte court',
  status: 'draft'
};

const response = await fetch('/wp-json/wp/v2/posts', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(payload)
});
console.log(response.status, await response.json());

Une réponse 422 accompagnée d’un message sur un champ permet généralement de corriger le problème sans toucher au thème. Si le message est vide, activez la journalisation temporaire et comparez la requête reçue par le serveur avec celle produite par le client.

Traiter les nonces et l’authentification de l’éditeur

L’éditeur de blocs utilise des requêtes REST et des nonces. Un nonce expiré ou généré pour une autre session peut produire un refus qui ressemble à une erreur de contenu. Rechargez l’éditeur, reconnectez la session et vérifiez l’horloge du serveur si le problème revient immédiatement.

Ne remplacez pas un nonce par une valeur fixe trouvée dans un exemple en ligne. Le nonce doit être généré côté WordPress et transmis par le mécanisme prévu. Contrôlez également l’URL du site et l’URL WordPress. Un domaine, un sous domaine ou un protocole incohérent peut empêcher le navigateur d’envoyer les bons cookies.

Si l’erreur ne touche qu’un utilisateur, une session ou un navigateur, commencez par vider les cookies du seul domaine et tester en navigation privée. Si tous les comptes échouent sur la même route, le problème se situe davantage dans la validation, le plugin ou le serveur.

Isoler un plugin, un formulaire ou WooCommerce

Les plugins de formulaire et de commerce appliquent des règles métier plus strictes que le cœur WordPress. Une adresse email invalide, un pays non configuré, un produit supprimé, un stock nul ou un champ obligatoire absent peut produire 422. Lisez le corps JSON avant de désactiver quoi que ce soit.

Utilisez le mode dépannage de WordPress sur votre session d’administrateur pour isoler les extensions sans perturber les visiteurs. Reproduisez l’action, puis réactivez les plugins un par un. Notez la version de l’extension, la route appelée et le champ qui fait réapparaître le statut.

Une mise à jour récente est un indice, pas une preuve. Comparez le changelog, la documentation et la configuration. Évitez de désactiver durablement une extension de sécurité pour faire disparaître le message. Une exception ciblée vaut mieux qu’un site sans protection.

# Rechercher les erreurs récentes dans un journal local
grep -iE '422|validation|rest_api|woocommerce' wp-content/debug.log | tail -n 40

Notre guide sur le mode debug WordPress explique comment journaliser sans afficher les erreurs aux visiteurs. Le journal doit rester inaccessible depuis le web et être supprimé ou protégé après le diagnostic.

Examiner le WAF, le proxy et les journaux serveur

Un pare feu applicatif peut répondre 422 lorsqu’il comprend le format de la requête, mais refuse son contenu. Ce cas arrive avec des chaînes longues, des balises HTML, des motifs ressemblant à une injection ou des fichiers encodés. Comparez les en-têtes Server, Via et les identifiants de requête.

Si WordPress ne reçoit aucune trace de l’appel, demandez à l’hébergeur ou au fournisseur CDN de rechercher l’heure exacte dans les journaux. Sur Apache, LiteSpeed et Nginx, la réponse peut être générée avant PHP. Modifier functions.php ne corrigera alors rien.

Ne désactivez pas le WAF pour tout le domaine. Testez une règle limitée à la route concernée, pour une durée courte, puis vérifiez les journaux. Une bonne exception conserve les contrôles d’authentification, de taille et de méthode HTTP.

curl -sS -D headers.txt -o body.json 
  -H 'Accept: application/json' 
  'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'

grep -iE 'HTTP/|server|request-id|content-type' headers.txt
head -c 1000 body.json

Ne pas confondre 422 avec 400, 401, 403 ou 500

Le statut observé guide la réparation. Une erreur 400 indique une requête mal formée. Une 401 concerne l’authentification. Une 403 correspond à un refus d’autorisation. Une 404 indique une route ou une ressource absente. Une 422 signifie que la requête est comprise, mais que ses données ne passent pas la validation. Une 500 pointe vers une erreur interne.

Pour comparer les diagnostics, consultez nos guides sur WordPress erreur 400, l’erreur REST API 401 et l’erreur REST API 403. Pour un délai côté proxy, voyez aussi WordPress erreur 408.

Un proxy peut masquer le statut original. Relevez le premier refus dans les journaux et ne vous fiez pas uniquement au titre de la page. Un changement de statut entre le CDN et WordPress est une information utile pour l’hébergeur.

Checklist de résolution en dix minutes

Reproduisez l’erreur une seule fois. Notez l’URL, la méthode, l’heure et le statut. Lisez le JSON retourné. Testez en navigation privée. Vérifiez le nonce et la session. Réduisez le payload à deux champs. Validez les types JSON. Comparez les versions des plugins. Testez le mode dépannage. Consultez les journaux du WAF, du serveur et de WordPress. Corrigez le champ ou la règle identifiée, puis rejouez le test avec une donnée saine.

Après la correction, contrôlez la création, la modification et la lecture de la ressource. Vérifiez aussi les intégrations qui utilisent la même route. Gardez une trace de la cause, du correctif et de la version concernée. Cette documentation évite de réintroduire une validation trop stricte lors de la prochaine mise à jour.

FAQ sur WordPress erreur 422

Pourquoi WordPress renvoie-t-il une erreur 422 ?

Le serveur comprend la requête, mais une donnée ne respecte pas les règles attendues. Il peut s’agir d’un champ obligatoire, d’un type JSON, d’un identifiant ou d’une règle de plugin.

Une erreur 422 vient-elle toujours de la REST API ?

Non. La REST API est fréquente, mais un formulaire, WooCommerce, un endpoint personnalisé ou un WAF peut aussi produire ce statut.

Comment corriger une erreur 422 dans l’éditeur WordPress ?

Rechargez la session, vérifiez le nonce, repérez la requête REST dans les outils réseau et testez avec un contenu minimal. Isolez ensuite le plugin qui ajoute la validation.

Faut-il modifier .htaccess pour supprimer un 422 ?

Non, pas avant d’avoir identifié une règle serveur responsable. Une modification aveugle peut supprimer une protection ou créer une erreur 500.

Le statut 422 empêche-t-il le référencement ?

Une erreur limitée à l’administration ne bloque pas forcément l’exploration. Si les pages publiques renvoient 422 aux robots, corrigez rapidement la validation ou la couche de sécurité concernée.

Sources et références

• MDN, statut HTTP 422 Unprocessable Content
• RFC 9110, définition des statuts HTTP
• Documentation officielle de la REST API WordPress
• Référence officielle WordPress pour les articles REST
• Documentation WordPress sur l’authentification REST
• Documentation officielle du débogage WordPress
• MDN, différence avec le statut HTTP 400

Si la route existe mais refuse les données, comparez avec ce guide sur WordPress erreur 404 et les permaliens.