rest_invalid_param sur WordPress : corriger les données envoyées à l’API

Distinguer un argument refusé d’une API inaccessible

WordPress renvoie le code rest_invalid_param, généralement avec un statut 400 et le nom d’un ou plusieurs paramètres. La requête a rencontré un contrôle sur ses données. L’API peut être accessible et la route correcte, tout en refusant une valeur, une structure ou une condition attendue pour cette opération.

Ce résultat diffère d’un rest_no_route, qui concerne le chemin et la méthode, ou d’une réponse HTML reçue à la place du JSON attendu. Il diffère aussi d’un document JSON impossible à analyser. Ne changez donc pas les permaliens ou l’hébergement avant d’avoir lu le détail du refus.

L’objectif est de faire correspondre la demande au contrat du point d’accès : son adresse, sa méthode, ses arguments et leurs contraintes. Il ne s’agit pas de supprimer la validation pour accepter n’importe quelle donnée. Nous allons d’abord lire l’argument rejeté, puis examiner la demande réellement transmise et corriger son origine. Si un autre code explique un problème de droits, nous conserverons ce signal au lieu de modifier arbitrairement le contenu.

Lire params et details dans la réponse

Dans le panneau Réseau du navigateur ou dans le client d’API utilisé, ouvrez la réponse complète de la demande en échec. Le message général peut citer seulement le nom du paramètre. Les champs data.params et, lorsqu’ils sont fournis, data.details donnent des indications plus précises sur le contrôle qui échoue.

Relevez le nom exact, y compris celui d’une propriété imbriquée. Une valeur hors liste, un objet de mauvaise structure et un statut non autorisé ne demandent pas la même correction. Tous les points d’accès ne produisent pas exactement le même niveau de détail ; l’absence de sous-code ne démontre pas que le client est correct.

Dans Chrome, ouvrez le menu ⋮ > Plus d’outils > Outils de développement, puis l’onglet Network ou Réseau. Sélectionnez la requête : Headers ou En-têtes contient l’adresse et la méthode ; Response ou Réponse contient le corps retourné ; Payload ou Charge utile affiche les paramètres transmis. Si la requête n’a pas été enregistrée, préparez sa reproduction sans effet externe sur la copie avant de la relancer. Un filtre Fetch/XHR peut aider, mais retirez-le si la demande recherchée est une navigation.

Un champ obligatoire absent peut produire rest_missing_callback_param, et un JSON illisible rest_invalid_json : conservez leur code propre. Pour rest_invalid_param, les détails dépendent du contrôle qui a rejeté la valeur. Un message générique n’autorise donc pas à inventer une contrainte absente de la documentation.

1. Confirmez le code principal et le statut de la réponse.
2. Relevez les noms figurant dans params, sans copier les secrets ou données personnelles associés.
3. Lisez chaque détail disponible et distinguez type, valeur, propriété inconnue et restriction de droits.
4. Notez l’URL, la méthode et l’heure de la demande.
5. Conservez le relevé initial avant de modifier un champ. Le journal PHP peut rester vide si WordPress a simplement renvoyé une erreur de validation prévue.

Observer les données effectivement transmises

Une interface peut afficher une valeur lisible alors que le connecteur envoie autre chose : un texte traduit, un tableau converti en chaîne ou une ancienne valeur conservée dans un modèle de requête. Le formulaire visible ne suffit donc pas à décrire la demande reçue par WordPress.

Dans Réseau, ouvrez les paramètres de l’URL et la zone Payload ou les données de formulaire. Comparez le nom du champ, sa valeur et son emplacement. Dans un client externe, examinez sa requête finale ou son journal expurgé plutôt que la seule configuration de départ. Les exports complets peuvent contenir des identifiants, des contenus privés et des en-têtes d’authentification.

Pour une opération d’écriture, utilisez d’abord la trace existante. Les essais suivants doivent être préparés sur une copie privée avec paiements, courriels et automatismes externes neutralisés. Même si un refus de validation devrait interrompre l’action prévue, ne supposez pas qu’aucun effet n’a eu lieu dans tout le logiciel ou lors d’une tentative précédente. Vérifiez l’état de la ressource avant de répéter une demande qui pourrait la créer ou la modifier.

Comparer les arguments du bon point d’accès

Le schéma décrit les données acceptées, leur type et certaines contraintes. Utilisez la documentation de la route et de la méthode réellement appelées, dans la version installée. Les arguments d’une lecture de collection ne sont pas automatiquement ceux d’une création ou d’une modification.

La découverte REST et les informations de route peuvent aider à retrouver les arguments exposés. Certaines descriptions sont filtrées ou incomplètes ; pour un composant personnalisé, le mainteneur doit alors confirmer l’enregistrement effectif. Ne copiez pas les règles d’une autre extension simplement parce que les deux objets portent le même nom dans l’interface.

Sur un réseau multisite, consultez le contrat du sous-site ciblé ; ses composants peuvent différer d’un autre site du réseau. Sur une plateforme gérée ou WordPress.com, confirmez aussi quelle API le connecteur doit utiliser. L’accès aux fichiers serveur n’est pas requis pour corriger un argument produit par un client déjà configurable.

1. Confirmez la racine, le namespace, le chemin et la méthode de la demande.
2. Ouvrez la référence correspondant à cette opération et à sa version.
3. Recherchez le paramètre cité par l’erreur, ses valeurs autorisées et ses conditions.
4. Comparez ces informations avec les données observées dans la requête finale.
5. Si le client et le serveur décrivent des contrats différents, conservez leurs versions et recherchez leur combinaison compatible avant de modifier le schéma.

Corriger une valeur hors liste sans traduire son identifiant technique

Certains arguments n’acceptent qu’une liste de valeurs précises. Par exemple, la lecture des articles du cœur propose des clés techniques pour le tri. Une interface française peut afficher « date » ou « titre », mais le client doit envoyer la valeur technique attendue, pas une traduction improvisée ou le nom d’une colonne d’une autre API.

Si la réponse indique que orderby ne fait pas partie des valeurs autorisées, comparez sa liste avec la référence de cette collection. Pour les articles du cœur, date est une valeur de tri documentée. Ce choix n’est pas universel pour toute route d’extension : utilisez son propre contrat si vous interrogez une autre ressource.

Dans le connecteur, corrigez le réglage de tri ou son modèle de requête à l’endroit qui produit cette valeur. Sauvegardez d’abord sa configuration privée et ne changez pas simultanément la source de données, le compte et l’adresse. Si le logiciel génère lui-même une valeur invalide sans réglage utilisateur, conservez la demande et les versions pour son éditeur ; remplacer manuellement chaque requête ne corrige pas le mécanisme qui les recrée.

Valider une petite lecture conforme avant le parcours complet

Le contrôle ci-dessous lit un seul article public, trié par date, depuis le point d’accès habituel du cœur. Remplacez l’adresse par la racine REST réellement découverte pour votre installation ; un site en sous-dossier ou à permaliens simples demande une adresse adaptée. Cette commande ne cible pas une route personnalisée à votre place.

Lancez-la avec curl déjà disponible, ou curl.exe sous PowerShell Windows. Les paramètres sont encodés séparément, la durée est limitée et aucun identifiant n’est fourni. Une liste vide peut être normale. L’important pour ce contrôle est de distinguer une réponse de collection valide d’un nouveau refus de route, de droits ou d’argument.

Un succès montre que cette petite lecture conforme fonctionne. Il ne valide pas automatiquement l’ensemble du connecteur, son écriture ni ses champs personnalisés. Si l’erreur initiale porte sur une autre propriété, appliquez la même comparaison au schéma de cette propriété plutôt que de conclure à une réparation globale. Conservez la trace avant et après, puis revenez au parcours initial sur la copie préparée.

L’option --include affiche aussi le statut et les en-têtes avant le corps. Une redirection n’est pas suivie automatiquement : examinez sa destination et corrigez la base appelée si nécessaire. Gardez cette sortie privée et expurgez d’éventuels cookies avant transmission. Un refus de protection sur la copie doit être traité avec son accès prévu, sans rendre cette copie publique.

curl --include --max-time 20 --get --data-urlencode 'per_page=1' --data-urlencode 'orderby=date' --data-urlencode '_fields=id,date' 'https://votre-site.example/wp-json/wp/v2/posts'

Préserver les types et les structures attendus

Une chaîne, un nombre, un tableau et un objet ne représentent pas la même structure. Un connecteur peut transformer un tableau d’identifiants en texte séparé par des virgules, ou envoyer un objet imbriqué comme une chaîne contenant du JSON. L’écran paraît alors correct, mais le serveur ne reçoit pas la forme prévue.

Comparez le contrat à la structure réellement envoyée. Les conversions acceptées dépendent du point d’accès et de ses fonctions de nettoyage ; il serait faux d’affirmer que toute valeur numérique entre guillemets est toujours rejetée par WordPress. Ne fondez pas le dépannage sur cette règle générale. Conservez plutôt un exemple minimal qui passe et la différence exacte avec celui qui échoue.

Pour une propriété attendue comme objet, vérifiez ses clés et leurs types au niveau approprié. Pour un tableau, vérifiez le type de ses éléments et les limites annoncées. Dans le client, utilisez son mode de saisie ou son mappage adapté au format, au lieu de concaténer manuellement plusieurs fragments. Si une conversion automatique est nécessaire, faites-la dans le composant producteur et testez aussi les valeurs vides et les cas limites prévus.

Distinguer le format JSON et le contenu validé

Un document peut être du JSON syntaxiquement valide tout en contenant des données refusées par l’API. À l’inverse, une virgule manquante ou des guillemets incorrects peut empêcher l’analyse avant la validation des champs. Le cœur dispose d’un code distinct, rest_invalid_json, pour signaler ce type de défaut lorsque le corps est interprété comme JSON.

Vérifiez aussi le type de contenu annoncé par le client et son mode d’envoi. Un corps construit comme formulaire ne devient pas automatiquement un objet JSON parce qu’un en-tête a été renommé. Dans un connecteur existant, choisissez le format documenté puis examinez la requête finale pour confirmer que l’outil l’a bien produit.

Ne collez pas de contenu privé dans un validateur public pour résoudre un problème de syntaxe. Utilisez un éditeur ou un contrôle local de confiance et une copie expurgée. Une validation de syntaxe réussie ne teste ni les permissions ni le schéma du point d’accès. Après correction, relisez le nouveau code de réponse : le passage d’une erreur de parsing à un argument refusé indique une étape différente, qui doit être analysée séparément.

Éliminer une valeur contradictoire dans plusieurs sources

Un même nom peut apparaître dans le chemin, l’URL, les données de formulaire et le corps JSON. WordPress possède un ordre de priorité pour retrouver les paramètres, et cet ordre peut être personnalisé. Corriger la valeur visible dans l’URL ne suffit donc pas si une autre source continue à fournir le même nom avec une valeur différente.

Dans la configuration du client, recherchez les paramètres hérités d’un profil, d’un modèle ou d’une variable d’environnement. Inspectez ensuite la requête finale plutôt que de supposer qu’un champ supprimé à l’écran a disparu du transfert. Un ancien corps sauvegardé dans le logiciel peut encore intervenir.

1. Recherchez le nom refusé dans toutes les sources de données de la requête observée.
2. Identifiez la source prévue par la documentation du client et de l’API.
3. Sur la copie, retirez seulement les doublons de configuration que vous avez identifiés comme contradictoires.
4. Renvoyez une demande maîtrisée et vérifiez la valeur finale ainsi que la réponse.
5. Si rien ne change, restaurez le profil initial et faites examiner le mappage effectif. Ne changez pas l’ordre global de priorité du serveur pour masquer un défaut local du client.

Isoler une propriété ajoutée par un composant

Une extension peut ajouter des propriétés ou modifier la manière dont un client construit sa demande. Un objet peut alors contenir un champ que le schéma actif n’accepte pas. La règle sur les propriétés supplémentaires dépend du schéma ; tous les arguments inconnus de toutes les requêtes ne sont pas nécessairement rejetés de la même façon.

Si le détail cite une propriété non autorisée, identifiez le composant qui l’ajoute et celui qui définit le contrat. Comparez leurs versions et la chronologie de l’apparition du problème. Le nom de la propriété peut orienter la recherche, mais sa présence ne démontre pas à elle seule quel produit est fautif.

Sur une copie sauvegardée, reprenez une configuration compatible documentée ou isolez uniquement le composant confirmé dans cette construction. Préservez les contenus et réglages liés à ce champ avant tout retrait. Si le défaut vient d’une version précise, recherchez son correctif officiel et validez-le sur la copie. N’effacez pas toutes les métadonnées en base et ne modifiez pas le cœur pour accepter la propriété : ces actions peuvent supprimer des données ou affaiblir le contrat sans traiter la cause.

Respecter un détail qui signale une restriction de droits

Le code principal peut être général alors que son détail décrit un statut ou un contexte interdit au compte utilisé. Dans ce cas, envoyer un texte mieux formé ne donnera pas automatiquement le droit d’obtenir ou de modifier la ressource. Lisez donc le sous-code et la condition signalée avant de décider que le schéma doit être assoupli.

Vérifiez le compte réellement reconnu par l’intégration et l’opération qu’il est censé effectuer. Un accès public en lecture ne permet pas de demander les mêmes informations qu’un compte de maintenance. Corrigez le périmètre de la demande ou l’autorisation légitime selon le besoin, sans attribuer systématiquement le rôle administrateur.

Aucune nouvelle extension n’est nécessaire pour examiner une réponse et corriger un mappage. Un outil qui force l’acceptation des arguments ou désactive les contrôles d’accès peut masquer l’erreur tout en produisant un résultat incorrect. Si les indices pointent vers l’authentification ou les capacités, utilisez le guide correspondant et conservez le relevé de paramètre pour le contexte. Le but reste une opération autorisée et conforme, pas seulement une réponse sans message d’erreur.

Valider la donnée obtenue et l’effet attendu

Une réponse sans erreur ne garantit pas que le client a envoyé le sens attendu. Une valeur retirée peut avoir été remplacée par une valeur par défaut, ou un mauvais champ peut avoir été ignoré. Vérifiez donc le résultat fonctionnel : tri retenu, ressource sélectionnée ou donnée enregistrée selon l’opération.

Pour une écriture sur la copie, utilisez un contenu de test et contrôlez ses valeurs après la demande. Vérifiez qu’il n’existait pas déjà et qu’aucun événement n’a été déclenché deux fois. En production, reprenez uniquement selon le mécanisme de maintenance validé pour cette intégration, en conservant la preuve de l’intervention.

1. Renvoyez la demande corrigée dans le contexte préparé.
2. Relisez le code, le statut et les détails éventuellement encore présents.
3. Contrôlez la valeur réellement retournée ou enregistrée, pas seulement la disparition du message.
4. Essayez un autre cas représentatif déjà prévu par le contrat, sans introduire une nouvelle opération métier.
5. Archivez la différence du client, les versions et le résultat. Si un nouveau paramètre est refusé, traitez-le séparément plutôt que de retirer progressivement tous les champs jusqu’à obtenir une réponse vide.

Annuler le changement et documenter le contrat retenu

Si le réglage modifié produit un résultat incorrect, restaurez le mappage ou le profil initial du client. Pour un composant mis à jour sur la copie, utilisez sa sauvegarde cohérente et sa procédure de retour prévue. Ne restaurez pas toute la base de production pour annuler une simple valeur d’argument dans un logiciel externe.

Conservez un exemple minimal expurgé qui fonctionne et la règle qu’il vérifie : valeur autorisée, structure d’objet, format de transfert ou source de paramètre. Associez-le à la version du point d’accès et du client. Le même exemple peut devenir invalide si le contrat change ; il ne doit pas être présenté comme une autorisation permanente de contourner les contrôles.

Pour transmettre un défaut restant, fournissez la route, la méthode, les versions, le nom refusé, le sous-code et la structure expurgée de la demande. Précisez si la petite lecture témoin fonctionne et ce qui diffère du parcours complet. Cette information aide l’éditeur ou le mainteneur à reproduire le défaut sans recevoir vos secrets ni vos données de visiteurs. Une correction durable doit agir sur le producteur de la demande ou sur une évolution justifiée du contrat, puis être vérifiée dans le parcours réel.