AUTH311 : Route REST manquante
Ce que cela signifie
La route de la boutique WCPOS est indisponible.
Demandez à l’administrateur du site de vérifier si une extension de sécurité ou de proxy supprime les en-têtes de requête de WCPOS.
Que faire
Un changement de réglage est nécessaire avant que cela fonctionne. Réessayez après avoir effectué la modification ci-dessus ; réessayer sans elle échouera de la même manière.
Vos données
Aucune donnée de commande ou de produit n’est affectée. Si le problème persiste, adressez-vous à la personne qui gère votre site WordPress.
Dépannage
- Confirmez que WCPOS est actif sur le site : WP Admin → Extensions.
- Testez les deux formes REST prises en charge dans un navigateur : l’adresse /wp-json/ de votre boutique et /index.php?rest_route=/. Ne concluez à un blocage REST que si aucune des deux adresses ne renvoie du JSON.
- Si aucune des deux formes REST ne fonctionne, demandez à l’administrateur du site si une extension de sécurité, un proxy ou un CDN supprime les en-têtes de requête de WCPOS ou bloque les requêtes REST — les règles de pare-feu et les options de durcissement désactivant l’API REST en sont les coupables habituels.
- Chez certains hébergeurs, réenregistrer les permaliens (Réglages → Permaliens → Enregistrer) rétablit les routes REST manquantes.
Où chercher
Lorsque WCPOS peut enregistrer cette erreur, elle est consignée sur l’appareil qui l’a déclenchée. Ouvrez État de la boutique → Journaux (l’icône en forme de cœur avec pouls, en bas du tiroir de navigation), repérez l’entrée portant ce code et dépliez-la : la ligne dépliée indique la raison en langage clair ainsi que le contexte capturé au moment de l’échec. Pour une requête vers la boutique, ce contexte peut inclure le code d’erreur propre au serveur (serverCode), le status HTTP ou l’endpoint ; les champs affichés dépendent de l’endroit où l’échec s’est produit. Pour signaler un problème, utilisez Copier les infos de débogage en haut de l’écran Journaux (Partager les infos de débogage sur téléphone et tablette) plutôt que des captures d’écran : cela regroupe la version de l’application, l’état de la connexion et les erreurs les plus récentes. Les journaux sont conservés 30 jours au maximum ; collectez-les donc pendant que le problème est récent. Copiez également toute erreur de la console du navigateur apparue avant que le POS n’ait pu écrire sa propre entrée de journal.
Au-delà du journal intégré à l’application, cet échec peut laisser des traces dans :
- Inspecteur réseau (web et bureau) : ouvrez les outils de développement — appuyez sur F12 dans le navigateur, ou Avancé → Afficher/Masquer les outils de développement dans le menu de l’application de bureau — puis sélectionnez l’onglet Réseau. Suivez d’abord les consignes de nouvelle tentative de cette page ; ne reproduisez l’action que lorsque ces étapes indiquent que c’est sans risque. Une requête en échec affiche le statut HTTP et le corps brut de la réponse, y compris les pages d’erreur qui n’atteignent jamais le journal du POS.
- WooCommerce → État → Journaux : sur le site WordPress, consultez le fichier
fatal-errors-*.logle plus récent pour repérer les plantages PHP, ainsi que toute source de journal portant le nom d’une extension impliquée dans l’échec. Une erreur de classe 500 renvoyée par la boutique y laisse presque toujours sa cause.
Détails
- Code :
AUTH311(REST_ROUTE_MISSING) - Gravité : erreur
- Introduit dans : WCPOS 1.10.0