Comprendre ce que signalent les deux alertes
Dans Outils, Santé du site, WordPress peut annoncer une erreur de l’API REST ou l’échec d’une requête de bouclage, souvent appelée loopback. Le site public continue parfois de fonctionner. Le résultat recherché est de rétablir le trajet concerné et les fonctions qui en dépendent, sans ouvrir les données privées ni désactiver toutes les protections.
L’API REST permet à WordPress et à des applications d’échanger des données. Un appel loopback part du serveur vers une adresse de son propre site. Les deux notions se recoupent dans certains contrôles : un test REST peut lui aussi être effectué depuis le serveur. Un navigateur qui affiche une page publique n’emprunte pas nécessairement le même trajet.
Ce guide traite ces alertes précises. Si seul l’enregistrement d’un article échoue, commencez aussi par conserver son texte et observer cette sauvegarde. Si des tâches sont en retard, leur file et leur exécution constituent un diagnostic distinct. Un contrôle de communication favorable ne prouve pas qu’un paiement, une publication planifiée ou une sauvegarde s’est achevé.
Relever le message avant de modifier le site
Avec un compte habilité, ouvrez Outils, Santé du site, onglet État. Attendez la fin des contrôles, dépliez le résultat en cause et notez son libellé, son code, l’adresse éventuelle et l’heure. Distinguez une erreur de transport, comme une connexion impossible, d’une réponse HTTP reçue mais inattendue.
Dans l’onglet Informations, relevez les versions de WordPress et de PHP ainsi que le thème et les extensions liés au début du problème. Si vous copiez les informations complètes pour un support, relisez-les avant transmission : chemins de serveur et détails techniques n’ont pas tous à être publiés. Gardez le relevé dans un dossier privé.
Indiquez aussi les changements récents : migration, nouvelle protection, modification DNS, changement de domaine ou mise à jour. Vérifiez si l’alerte persiste après un rechargement raisonnable de cet écran. Évitez de le rafraîchir en boucle sur un hébergement déjà saturé. Si le résultat est intermittent, plusieurs observations datées valent mieux qu’une capture isolée, notamment pour rapprocher la panne des journaux disponibles.
Comprendre les limites des contrôles natifs
Le contrôle REST actuel vise une route de type de contenu avec le contexte edit, depuis WordPress, en transmettant des éléments de la session. Il ne se contente pas de lire l’index public de l’API. Ouvrir cette même adresse dans un onglet ne reproduit pas forcément ses en-têtes et son jeton ; un refus ainsi obtenu peut être normal pour une demande non authentifiée.
Le contrôle loopback natif utilise une requête POST particulière vers wp-cron.php pour terminer sans lancer les tâches Cron. Son succès ne valide donc ni la durée d’une tâche réelle ni le traitement de toute une file. Ne remplacez pas ce test par l’ouverture répétée de wp-cron.php dans le navigateur, qui correspond à une autre demande.
Les contrôles peuvent être modifiés par du code et leur contexte diffère d’autres échanges. Notez toujours lequel est revenu à la normale après votre intervention. Si l’éditeur reste inutilisable malgré un écran Santé du site favorable, observez sa propre requête. À l’inverse, une interface qui semble fonctionner n’explique pas un échec de communication encore visible côté serveur.
Choisir le parcours selon l’indice disponible
Commencez avec les contrôles natifs, qui ne demandent pas de nouvelle extension. Une session ancienne ou une adresse manifestement incohérente justifie de vérifier le compte et le domaine. Un refus contenant le nom d’une protection ou d’un composant oriente plutôt vers son réglage et ses journaux. Une erreur de résolution, de certificat ou de connexion demande une comparaison depuis l’hébergement.
Avant toute modification de composants, préparez une copie avec base et fichiers sauvegardés. Neutralisez ses envois de courriels, paiements et synchronisations. Sa protection et son domaine peuvent différer de la production : un échec propre à la copie n’établit pas la cause de l’alerte du site actif.
Sur WordPress.com, utilisez les outils et droits disponibles dans votre offre ; ne supposez pas l’accès au terminal ou aux fichiers système. En multisite, identifiez le site exact et faites intervenir l’administrateur réseau pour les composants imposés. Une alerte sur un site ne justifie pas de désactiver une extension sur tout le réseau.
Reprendre le contrôle natif avec une session actuelle
Ce premier parcours convient lorsque l’alerte REST apparaît après une longue session, une reconnexion ou un changement de domaine. Il exige vos accès habituels. Préservez d’abord tout travail non enregistré dans les onglets ouverts. Le but est de refaire le contrôle avec une session actuelle sur la bonne administration, sans modifier les droits du compte.
Si l’alerte disparaît, vérifiez aussi la fonction qui était touchée, par exemple l’ouverture et l’enregistrement d’un brouillon de test. Si elle persiste avec le même message, gardez ce résultat pour la suite. Effacer tous les cookies ou changer de navigateur ne corrige pas à lui seul une connexion bloquée entre deux processus serveur.
- Ouvrez la connexion habituelle dans un autre onglet et vérifiez le domaine ainsi que le compte.
- Reconnectez-vous normalement si nécessaire, puis rouvrez Outils, Santé du site et attendez les résultats.
- Comparez le message et son adresse au relevé initial ; notez s’ils ont changé.
- Contrôlez une fonction représentative sans publier de contenu réel pour l’essai.
- Si vous avez utilisé un profil de navigateur distinct, fermez cette session de test et reprenez votre environnement habituel.
Vérifier l’adresse REST réellement utilisée
Utilisez l’adresse fournie par WordPress ou les informations de découverte de l’API. Le chemin fréquent /wp-json/ n’est pas universel : une installation sans réécriture peut employer une adresse contenant ?rest_route=/. Le répertoire de l’installation et celui de l’accueil public peuvent aussi différer. Un 404 sur un chemin deviné ne prouve pas que l’API entière est cassée.
Dans Réglages, Général, comparez les adresses WordPress et du site au domaine attendu. Ne les rendez pas identiques par principe : une installation en sous-dossier peut être volontaire. Si un ancien domaine est confirmé, préparez la méthode de retour avec accès aux fichiers ou à l’hébergement avant de corriger le seul champ concerné et d’enregistrer les modifications. Un champ grisé peut être imposé par une constante de configuration.
Pour une lecture de l’index public, regardez aussi le contenu reçu : une page de connexion ou un défi de sécurité peut arriver avec un statut 200. Cette lecture ne teste pas les permissions d’édition. Après une correction d’adresse, reconnectez-vous et reprenez le contrôle natif ; en cas de régression, rétablissez la seule valeur modifiée par le moyen de retour préparé.
Isoler une extension sur une copie sans nouvel outil
Cette approche convient si l’alerte suit l’activation ou la mise à jour d’une extension. Utilisez une copie où vous avez confirmé le même échec, avec les effets externes neutralisés. Relevez sa liste de composants et leurs états avant l’essai. Une désactivation sur copie permet de comparer ; elle ne décide pas à elle seule quelle fonction retirer du site public.
Si le test redevient favorable après une seule désactivation et échoue de nouveau après réactivation, vous obtenez un indice reproductible. Il reste à examiner la configuration et les interactions du composant. L’absence de changement invite à rétablir son état et à poursuivre un autre indice, sans multiplier les composants laissés inactifs.
- Dans Extensions, Extensions installées, retrouvez l’extension désignée par l’historique ou le message.
- Cliquez sur Désactiver pour cette seule extension ; ne choisissez pas Supprimer.
- Rouvrez Santé du site dans la même copie et relevez séparément les résultats REST et loopback.
- Réactivez l’extension, puis reprenez exactement le contrôle pour vérifier le retour éventuel du défaut.
- Rétablissez l’état initial après le diagnostic et notez la comparaison. Si une dépendance empêche la désactivation, analysez cet ensemble avec son responsable plutôt que de forcer son retrait.
Interpréter une comparaison sans perdre les fonctions utiles
Un composant qui restreint l’API peut appliquer une politique volontaire, mais une interdiction globale peut aussi empêcher une fonction nécessaire. Après attribution, ouvrez ses réglages documentés et recherchez la règle réellement responsable. Conservez sa valeur initiale et limitez l’autorisation au contexte légitime. Suivez le chemin documenté par l’éditeur pour la version installée, car les menus diffèrent selon le produit.
Ne rendez pas toutes les routes publiques pour satisfaire un voyant. L’authentification et les capacités WordPress restent nécessaires pour les données privées et les écritures. Une erreur de permission structurée n’a pas la même signification qu’une page HTML d’un intermédiaire. Pour un code personnalisé, faites relire le filtre concerné par son auteur au lieu d’ajouter un second filtre qui masque toutes les erreurs.
Si l’historique pointe le thème, comparez sur la copie avec un thème standard déjà installé, depuis Apparence, Thèmes, puis Activer sur ce thème. Gardez le thème initial installé et ne modifiez pas les modèles pendant cet essai. Reprenez les deux contrôles, puis réactivez le thème d’origine. Une amélioration ainsi obtenue oriente vers son code ou une interaction ; elle ne justifie pas de changer immédiatement la présentation du site actif.
Utiliser Troubleshooting comme aide facultative
Troubleshooting, de Marius L. J., permet de comparer des composants dans une session de dépannage. Au 3 novembre 2026, le répertoire affiche la version gratuite 1.0.2, WordPress 5.8 minimum et un test déclaré jusqu’à WordPress 7.1.4. Son API annonce PHP 7.1, mais le code et le fichier de présentation demandent PHP 7.2 : retenez au minimum cette exigence plus stricte et vérifiez votre environnement actuel.
Ce parcours demande les droits d’installation et reste préférable sur copie. Il ne corrige ni DNS, ni certificat, ni pare-feu externe. Le résultat attendu est une différence liée aux composants de la session, à confirmer ensuite avec les contrôles serveur normaux.
- Dans Extensions, Ajouter une extension, recherchez Troubleshooting et vérifiez l’auteur ainsi que le slug troubleshooting du répertoire.
- Si l’environnement est compatible, installez et activez, puis ouvrez Outils, Santé du site, onglet Troubleshooting.
- Lisez les indications et cliquez sur Enable Troubleshooting Mode. Si l’installation de son fichier nécessaire échoue, arrêtez ce parcours sans modifier les permissions globales.
- Dans le menu Troubleshooting Mode de la barre d’administration, réactivez le thème puis les extensions pour votre session, un élément à la fois. Après chacun, rouvrez l’onglet État de Santé du site et relevez les résultats.
- Quittez avec Disable Troubleshooting Mode, puis vérifiez que le contexte normal est revenu.
Respecter les limites de l’isolation par session
Le mode de dépannage n’est pas une copie de la base. Les réglages enregistrés, les données créées et les appels externes peuvent avoir un effet réel. Les extensions obligatoires de l’hébergeur et certains fichiers de cache restent aussi en dehors d’une simple désactivation des extensions ordinaires. N’effacez pas leur dossier pour obtenir une session plus vide.
Un appel serveur est une nouvelle requête, susceptible de partir avec une autre adresse source ou de ne pas conserver tout le contexte de diagnostic. Ne supposez donc pas qu’un résultat REST ou loopback correspond exactement aux composants visibles comme actifs dans votre navigateur. Une comparaison importante doit être confirmée sur la copie en fonctionnement normal, avec une modification ciblée de ses composants.
Les caches peuvent également brouiller cette isolation. Vérifiez une visite indépendante après avoir quitté le mode, puis traitez seulement la couche de cache identifiée si un affichage de dépannage persiste. En cas d’accès perdu, la déconnexion permet aussi de quitter la session de diagnostic. Ne supprimez pas les tables ou les réglages d’origine pour revenir à la normale. L’outil fournit des indices ; il ne certifie pas l’absence de conflit.
Comparer le trajet depuis le serveur avec curl
Ce contrôle avancé s’adresse à la personne disposant d’un terminal autorisé sur l’hébergement. Il compare l’accès à la racine publique REST depuis cette machine, avec une requête GET bornée. Remplacez l’adresse fictive par la vraie racine de votre installation, éventuellement avec son sous-dossier ou sa forme rest_route. N’utilisez pas la route context=edit pour attendre un succès sans authentification.
Sous Linux, la commande ci-dessous jette le corps reçu et affiche le statut HTTP ainsi que le temps total. Sous Windows, utilisez curl.exe et remplacez /dev/null par NUL. Aucun mot de passe ni cookie n’est ajouté. Le paramètre -q placé en premier évite la lecture de la configuration personnelle de curl. Les délais bornent cette observation, pas nécessairement le travail déjà commencé sur le serveur.
La commande ne suit pas les redirections ; si elle en indique une, vérifiez sa destination dans un relevé privé avant une autre demande. Conservez le message d’erreur éventuel et comparez une lecture depuis votre poste. Un succès depuis le terminal ne valide pas l’environnement PHP, ses certificats, son proxy ou les en-têtes du contrôle WordPress. Cette commande ne modifie pas de réglage et ne demande pas de retour arrière. Elle ne doit pas devenir une sonde répétée en continu.
curl -q --silent --show-error --connect-timeout 5 --max-time 15 --output /dev/null --write-out 'HTTP=%{http_code} total=%{time_total}s\n' 'https://exemple.invalid/wp-json/'Utiliser les résultats pour corriger la bonne couche
Une erreur curl 6 indique un échec de résolution du nom ; 7 signale une connexion impossible ; 28 correspond à un délai dépassé. Un message de certificat demande d’examiner la confiance et le nom couvert, pas de désactiver la vérification TLS. Un affichage HTTP=000 accompagne l’absence de réponse HTTP exploitable : ce n’est pas un statut envoyé par WordPress.
Un 401 invite à distinguer protection HTTP de l’environnement et authentification applicative. Un 403 peut venir de WordPress ou d’une protection intermédiaire ; rapprochez son contenu et son heure des journaux. Un 404 sur la racine REST exige de confirmer l’adresse et le routage. Un délai dépassé peut aussi résulter d’une capacité PHP saturée : le serveur attend parfois qu’un autre processus soit disponible pour répondre à son propre appel.
Si la demande atteint un pare-feu, relevez sa règle et son action avant toute exception. Faites corriger la règle démontrée responsable, avec sa configuration précédente conservée, puis refaites le contrôle natif. N’autorisez pas tous les chemins et toutes les adresses du serveur par commodité. Si aucun journal ne montre la demande à destination, poursuivez la résolution et le trajet réseau plutôt que d’accuser une extension sans preuve.
Traiter la préproduction protégée et les blocages locaux
Une copie protégée par une authentification HTTP peut refuser l’appel interne même lorsque vous êtes connecté à WordPress. Ce sont deux authentifications différentes. Les contrôles natifs prévoient de transmettre l’authentification HTTP lorsqu’elle est disponible dans les variables PHP attendues ; un proxy ou une configuration serveur peut empêcher cette transmission.
Faites vérifier ce trajet précis et son intégration avec la protection de la copie. Ne retirez pas le mot de passe de tout un environnement contenant des données privées, et n’inscrivez pas ses identifiants dans une commande destinée à être partagée. Une correction doit conserver la protection tout en autorisant le fonctionnement interne légitime, selon l’architecture de l’hébergement.
Examinez aussi les restrictions personnalisées de l’API HTTP. La constante WP_HTTP_BLOCK_EXTERNAL n’interdit pas par défaut le propre hôte du site ni localhost : la supprimer au hasard n’est donc pas une réponse générale à un loopback en panne. Des filtres locaux ou une destination devenue différente peuvent intervenir. Faites identifier la règle effectivement appliquée avant de la modifier. Les extensions obligatoires et les réglages de réseau doivent être traités par leur responsable, sans renommage global de leurs dossiers.
Confirmer la réparation et garder une trace exploitable
Après une correction ciblée, rouvrez Santé du site hors mode de dépannage et vérifiez séparément REST et loopback. Comparez les messages avec votre relevé initial. Contrôlez ensuite la fonction touchée dans un parcours limité : ouvrir l’éditeur et enregistrer un brouillon fictif, par exemple. Pour les tâches planifiées, vérifiez leur progression par leur outil normal sans relancer des opérations sensibles.
Retirez les seules exceptions temporaires devenues inutiles et rétablissez les composants employés pour le diagnostic. Si une règle reste nécessaire, documentez sa portée, son responsable et son retour arrière. Un voyant favorable obtenu en retirant une protection essentielle ou une fonction métier ne constitue pas une réparation complète.
Si le problème persiste, transmettez un dossier court : site concerné, message exact, heure et fuseau, route et méthode, changement récent, résultat sur copie et comparaison depuis le serveur. Joignez l’identifiant de règle ou de requête s’il existe, sans cookie, jeton, mot de passe ni exportation complète du trafic. Précisez également ce qui reste non testé. Ces éléments permettent de poursuivre au bon niveau sans refaire toutes les désactivations ni modifier la planification d’un problème qui relève encore de la communication.
Rejouer séparément les deux contrôles de Santé du site
Sur une copie WordPress, le même compte administrateur a exécuté les deux contrôles natifs. Le banc a d’abord vérifié le fonctionnement normal, puis simulé un refus de chaque trajet séparément. Les requêtes sont restées sur la boucle locale.
L’index REST public répondait 200. La route d’édition ouverte sans session renvoyait un refus normal. Pour comprendre une alerte sur votre copie, comparez donc l’index public avec le résultat natif dans votre session. Si seul le contrôle loopback échoue, relevez le résultat du POST de Santé du site et cherchez la règle ou le trajet qui le concerne.
Cas de test REST en édition Loopback
État initial 200 200
Refus de la route REST testée 403 200
Refus du POST loopback 200 403
Retour à l’état initial 200 200Vérifier que la correction reste ciblée
Après intervention sur la copie, reprenez les deux contrôles avec le même compte. Vérifiez qu’une lecture publique continue de fonctionner et que la route d’édition exige toujours les droits attendus. Dans le banc, le POST de contrôle s’est terminé sans lancer les tâches planifiées. Le retour à l’état initial a reproduit les deux résultats favorables.
Si le serveur journalise un refus, donnez au responsable le code, l’heure et la route concernée. Gardez les cookies et les jetons hors du relevé. Si la correction a déplacé l’échec vers l’autre contrôle, restaurez le réglage précédent avant de poursuivre l’enquête.
