Se connecter Parlons de vos besoins Accéder à CntX
Dépannage et support 8 min

Résoudre les problèmes de publication WordPress

Diagnostiquez et corrigez les échecs les plus courants de connexion, d'authentification et de publication WordPress lorsque vous poussez du contenu depuis CntX.

Aperçu

La publication WordPress dans CntX repose sur quatre couches qui doivent fonctionner ensemble : des identifiants d’intégration corrects (URL du site, nom d’utilisateur, Application Password), une REST API joignable, des capacités utilisateur appropriées dans WordPress, et un état d’élément de contenu valide (corps présent, destination mappée, garde-fous éditoriaux pris en compte). Les échecs se manifestent généralement par des erreurs de test de connexion, un statut CMS failed sur l’élément, ou un succès silencieux pointant vers le mauvais environnement.

Ce guide déroule des vérifications rapides par ordre de fréquence — la plupart des incidents se résolvent par une faute de frappe dans l’URL, un Application Password révoqué, des plugins de sécurité bloquant `/wp-json/`, ou des destinations de stratégie pointant vers l’intégration d’un autre Workspace. Les avertissements d’approbation éditoriale sont intentionnels ; ils ne bloquent pas la publication, sauf si votre processus choisit d’attendre.

Gardez le statut éditorial et le statut CMS distincts pendant le diagnostic. Corriger WordPress ne change pas le fait qu’un brief ait été approuvé en interne, et une approbation interne ne prouve pas que l’article a atteint le CMS.

Quand utiliser cet article

Utilisez ce guide de dépannage lorsque :

  • Le Test connection échoue dans Paramètres → Intégrations.
  • Les actions de publication renvoient 401, 403, 404 ou CMS failed.
  • Les articles apparaissent sur le mauvais site (préproduction et production, ou le domaine d’un autre client).
  • Le contenu se publie mais les catégories, méta SEO ou le formatage sont incorrects ou absents.
  • La REST fonctionne dans les tests navigateur depuis votre poste mais échoue depuis CntX (pare-feu de l’hébergeur, géo-blocage, protection anti-bot).

Si vous n’avez pas encore connecté WordPress, complétez d’abord Connecter CntX à WordPress.

Avant de commencer

  • Identifiez quel Workspace détient l’intégration et l’élément de contenu.
  • Disposez d’un accès admin WordPress pour vérifier les articles et la liste des Application Passwords.
  • Sachez si des plugins de sécurité, des règles CDN ou une authentification HTTP basique protègent le site.
  • Copiez le message d’erreur exact depuis le toast CntX ou le champ de statut CMS avant de modifier les réglages.

Vérifications rapides

Parcourez cette liste avant d’entreprendre des changements de configuration en profondeur :

  1. Format de l’URL du site — doit être `https://domaine.com`, sans `/wp-admin`, sans slash final sur un chemin erroné, et sans incohérence http/https. Les incohérences entre HTTP et HTTPS peuvent empêcher la connexion à l’API.
  2. Validité de l’Application Password — régénérez-le s’il a été renouvelé, révoqué ou copié partiellement. WordPress ne l’affiche qu’une seule fois, à la création.
  3. Capacités de l’utilisateur de publication — l’utilisateur doit pouvoir publier des articles (Editor/Administrator). Les comptes de niveau Subscriber renvoient un 403 à la création.
  4. Joignabilité de la REST — ouvrez `https://votresite.com/wp-json/` dans un navigateur. Attendez-vous à du JSON, pas à une page de connexion HTML, un 404 ou un challenge de pare-feu.
  5. Intégration du bon Workspace — la destination de la stratégie doit référencer l’intégration du Workspace que vous éditez, et non la connexion WordPress d’une autre marque.
  6. Élément de contenu prêt — titre et corps renseignés ; canal mappé sur la destination WordPress.
  7. Catégories toujours existantes — des catégories WordPress supprimées mais mappées dans CntX peuvent provoquer des erreurs de publication selon la rigueur de l’API.
  8. Avertissement éditorial pris en compte — CntX peut vous avertir en cas de publication avant le statut Approved ; vérifiez que vous n’avez pas annulé l’action par erreur.

Symptômes courants et correctifs

401 Unauthorized ou 403 Forbidden

Causes probables : mauvais nom d’utilisateur, mauvais Application Password, mot de passe révoqué, ou rôle insuffisant.

Correctif :

  1. WordPress → Utilisateurs → Profile → Application Passwords : révoquez l’ancien mot de passe `CntX`, créez-en un nouveau.
  2. Mettez à jour l’intégration dans CntX Paramètres → Intégrations ; lancez le test de connexion.
  3. Vérifiez que le rôle de l’utilisateur inclut `publish_posts`.
  4. Si vous utilisez des plugins de double authentification ou de SSO, assurez-vous que les Application Passwords restent activés pour les utilisateurs API.

404 sur `/wp-json/` ou les routes REST

Causes probables : structure des permaliens, plugin de sécurité bloquant la REST, ou WAF de l’hébergeur.

Correctif :

  1. WordPress → Paramètres → Permalinks → enregistrez la structure Post name (cela vide les règles de réécriture).
  2. Plugin de sécurité : autorisez la REST API / désactivez les options « Disable REST API ».
  3. Panneau de l’hébergeur : mettez `/wp-json/*` en liste blanche du mode anti-bot (Cloudflare, Sucuri, etc.).
  4. Vérifiez que le site n’est pas cloisonné en mode maintenance pour les requêtes anonymes.

Le test de connexion réussit mais la publication échoue

Causes probables : mappage de catégories, incompatibilité de type de contenu personnalisé, validation de payload, ou plugin rejetant le HTML du contenu.

Correctif :

  1. Publiez un brouillon avec un corps minimal pour isoler les problèmes de contenu.
  2. Retirez les embeds ou shortcodes problématiques ; réessayez.
  3. Consultez Site Health de WordPress et les journaux d’erreurs (`debug.log` s’il est activé).
  4. Désactivez temporairement les plugins SEO ou de filtrage de contenu conflictuels pour procéder par dichotomie.

Publication dans le mauvais environnement

Causes probables : URL de préproduction dans un Workspace de production, ou intégrations en doublon.

Correctif :

  1. Comparez l’URL de l’intégration dans CntX avec le domaine public visé.
  2. Renommez clairement les intégrations (`WP Production`, `WP Staging`).
  3. Auditez les destinations de canaux de la stratégie après correction de l’URL.
  4. Supprimez les brouillons erronés sur le mauvais site pour éviter les URLs SEO en doublon.

Titre ou méta description Yoast SEO manquants

Causes probables : les méta Yoast ne sont pas exposées à la REST, ou le mappage de champs CntX est incomplet pour votre version de Yoast.

Correctif :

  1. Vérifiez la prise en charge de la REST API par votre version de Yoast.
  2. Renseignez les métadonnées manuellement dans wp-admin après la publication du brouillon, jusqu’à confirmation du mappage.
  3. Inspectez la réponse REST à la recherche de `yoast_head_json` ou des champs méta lors du diagnostic avec le navigateur ou curl.

Statut CMS bloqué ou obsolète

Causes probables : erreur API transitoire, délai d’attente dépassé lors du traitement d’un contenu HTML volumineux, ou modifications manuelles dans WordPress désynchronisant l’état.

Correctif :

  1. Relancez la publication depuis CntX — l’article existant est mis à jour lorsque son ID est stocké.
  2. Ouvrez la liste des articles WordPress pour comparer l’état réel au badge CMS de CntX.
  3. Réconciliez l’URL externe sur l’élément de contenu si le slug a été modifié manuellement dans wp-admin.

Erreurs SSL ou de certificat

Causes probables : certificat expiré, chaîne incomplète, version TLS bloquée par l’hébergeur.

Correctif : renouvelez le certificat ; testez avec SSL Labs ; assurez-vous que les redirections HTTPS ne bouclent pas.

Résultat attendu

Après correction, le Test connection réussit dans Paramètres → Intégrations. La publication d’un élément témoin passe en CMS draft ou CMS published, affiche le lien externe, et crée un article visible dans l’admin WordPress avec le titre et le corps attendus. Une nouvelle publication met à jour le même article au lieu de le dupliquer.

Les plugins de sécurité restent activés avec des règles d’autorisation REST plutôt que désactivés globalement. L’équipe documente quel Application Password correspond à quel environnement.

Conseils

  • Un mot de passe par environnement — ne réutilisez jamais les identifiants de staging sur l’intégration de production.
  • Diagnostic en brouillon d’abord — validez toujours par une publication en brouillon avant un push en ligne lors du test d’un correctif.
  • Conservation des traces — capturez les toasts d’erreur ; les horodatages du `debug.log` WordPress aident le support en cas d’escalade.
  • WordPress multisite — les chemins REST et les comptes utilisateurs diffèrent ; vérifiez les recommandations de l’admin réseau pour les Application Passwords sur les sous-sites.
  • Auth HTTP sur staging — une authentification basique devant un staging bloque l’API sauf si CntX gère les en-têtes d’auth dans votre version ; utilisez un staging publiquement joignable ou des listes d’IP autorisées.
  • Ne désactivez pas la REST globalement — d’autres intégrations en dépendent ; privilégiez des règles d’autorisation ciblées.

Prochaine étape

Retestez l’intégration, publiez un brouillon, vérifiez dans l’admin WordPress, puis passez à Publier un contenu en brouillon ou en ligne pour le processus courant. Si les erreurs persistent après ces vérifications, utilisez Contacter le support et signaler un problème de sécurité en indiquant l’ID du Workspace, l’URL de l’intégration (masquez le mot de passe) et le texte exact de l’erreur.

Prérequis

Articles connexes

Prérequis

Articles liés

Prêt à l'essayer dans CntX ?

Ouvrez le produit et appliquez ce guide à votre espace de travail.

Accéder à CntX Retour au centre d'aide