Identifier à quel moment la soumission se bloque
Vous cliquez sur Envoyer dans Contact Form 7. L’indicateur reste visible et aucun message de résultat n’apparaît. Pour trouver la cause, suivez une tentative depuis le clic jusqu’à la réponse, puis jusqu’à son affichage. Ce parcours permet de distinguer un script qui ne lance jamais la requête, une requête en attente et une réponse correcte que la page ne montre pas.
Dans une soumission Ajax, le navigateur envoie un POST à l’API REST de WordPress. Le chemin habituel contient contact-form-7/v1/contact-forms, l’identifiant numérique du formulaire, puis feedback. Relevez l’adresse exacte dans le navigateur. Elle peut notamment inclure un sous-dossier ou passer par le paramètre rest_route. La requête de schéma ou la réponse de l’index REST ne démontre pas que le POST de soumission fonctionne.
Contact Form 7 renvoie un résultat applicatif si la requête atteint le traitement. Le statut HTTP décrit la réponse au niveau du transport. Le champ status dans le JSON distingue notamment validation_failed, spam, mail_failed et mail_sent. Une réponse HTTP 200 peut porter chacun de ces résultats. La couleur du message et son texte peuvent varier selon le thème et les traductions. Le champ status et la trace de la requête constituent de meilleurs repères.
Si une confirmation s’affiche mais que la boîte reste vide, relevez mail_sent ou mail_failed et orientez le diagnostic vers le courrier. Si le champ vaut spam, isolez le filtre qui a rendu ce verdict. Un indicateur bloqué avec un JSON déjà reçu demande d’examiner aussi le JavaScript de la page. Gardez ces pistes séparées pour éviter de modifier le SMTP quand le navigateur a reçu une page HTML de pare-feu.
Préparer une copie qui puisse recevoir des tentatives fictives
Identifiez une recette privée avec sa propre URL, sa base et son cache. Reprenez la configuration et les versions nécessaires pour reproduire le défaut. Relevez les versions de WordPress, de Contact Form 7, de PHP et du thème, le constructeur utilisé et l’identifiant du formulaire. Si le problème dépend d’une règle de CDN ou de proxy qui n’existe pas en recette, gardez ce point dans les limites du test. Les traces de production déjà disponibles pourront compléter la comparaison en lecture seule.
Avant d’ouvrir la page, neutralisez sur la copie les transports de courrier réels et les appels sortants liés au formulaire. Retirez les secrets de production, vérifiez la configuration des add-ons, des tâches différées, du CRM et des webhooks. Réservez le profil navigateur à la copie et bloquez les destinations externes inutiles côté navigateur aussi. Le bouton peut déclencher des traitements annexes qui ne passent pas par le transport de WordPress.
Dans Contact → Formulaires de contact, ouvrez le formulaire de recette et conservez le texte de ses réglages dans un emplacement privé. Pour une vérification limitée au trajet navigateur et au traitement CF7, ajoutez temporairement skip_mail: on dans Réglages additionnels. Cette option demande à CF7 de sauter le courrier. Les extensions et actions annexes peuvent encore s’exécuter et un statut mail_sent obtenu ainsi correspond à une simulation. Le blocage des transports et intégrations de la recette reste nécessaire.
Utilisez un nom et un texte synthétiques ainsi qu’une adresse de test en domaine réservé, acceptée par la validation locale si le champ l’exige. Vérifiez les deux onglets de courrier, y compris le second modèle s’il est actif. Si l’environnement garde un accès vers des destinataires réels ou un système tiers, poursuivez avec les journaux existants et préparez une copie mieux isolée avant toute soumission.
Capturer un POST et son résultat sans multiplier les essais
Sur la copie, ouvrez le formulaire dans un profil anonyme distinct de votre profil administrateur. Ouvrez les outils de développement. Dans Réseau, activez la conservation du journal si vous devez observer une redirection. Laissez le panneau Console visible ou relevez séparément la première erreur JavaScript de l’instant. Commencez sans pièce jointe si le formulaire le permet, puis réintroduisez un fichier fictif quand la comparaison l’exige.
Videz le journal du navigateur, saisissez le jeu de test et cliquez une fois. Relevez l’heure avec fuseau, la méthode, le chemin, le statut HTTP, l’adresse finale, le type de contenu et le temps observé. Filtrez d’abord sur feedback. Si rien ne correspond, élargissez à toutes les requêtes et cherchez une navigation de type document. Le résultat peut être un POST classique suivi d’un rechargement. Un bouton grisé par la validation ou le consentement produit encore un autre cas.
Dans la réponse, cherchez le champ status si le corps est un objet JSON. Pour du HTML, identifiez le type de page d’après son titre ou les premiers éléments, par exemple une page de connexion, un défi de sécurité ou une erreur de passerelle. Évitez de partager des exports réseau bruts. Les données de formulaire, cookies, jetons CAPTCHA, en-têtes et URL signées peuvent être inclus dans la trace.
Si le POST reste en attente, prenez un relevé et corrélez-le au journal du proxy ou de l’hébergement, au lieu de cliquer plusieurs fois. Un navigateur qui a cessé d’attendre ne prouve pas que le serveur a abandonné le traitement. En production, une reprise en aveugle peut créer des doublons même si aucune confirmation n’a été visible.
- Ouvrir le formulaire de recette et noter l’URL attendue de sa page.
- Soumettre une fois un jeu fictif. Relever l’existence du POST et sa destination.
- Noter une seule classe de résultat observée. Sans POST, en attente, HTTP en erreur, HTML inattendu ou JSON applicatif.
- Associer la trace navigateur à l’entrée serveur correspondante si elle existe.
Sans POST, vérifier les scripts et le montage du formulaire
Si le clic ne produit aucune requête, commencez par l’état du bouton et des champs. Vérifiez le consentement requis, un champ invalide et un éventuel calque qui intercepte le clic. Si la page se recharge, la soumission se fait peut-être en mode classique. Cette piste est distincte d’un POST REST qui échoue. Un navigateur avec JavaScript désactivé, un script absent ou une erreur de chargement peut expliquer ce comportement.
Dans Réseau, affichez les fichiers JavaScript et relevez l’échec le plus proche du chargement du formulaire. Un script répondu en HTML, un refus CSP ou un fichier bloqué par une extension du navigateur demande un correctif différent. Comparez avec un profil sans extension sur la copie. Dans Console, examinez le premier message pertinent et le fichier associé. Les erreurs suivantes peuvent être des conséquences d’une dépendance qui a échoué plus tôt.
Sur une page privée de la copie, insérez le bloc Contact Form 7 ou le shortcode fourni par le formulaire de recette. Comparez ce montage simple à la page construite, avec le même formulaire et les mêmes champs. Si la page simple fonctionne, vérifiez un bloc imbriqué, une fenêtre modale, un chargement à la demande ou un balisage de formulaire imbriqué. Si la même version échoue partout après une mise à jour, comparez les prérequis de la version installée et les versions de la pile avant tout changement.
Si le spinner démarre sans POST, consultez aussi les mécanismes antispam ou personnalisations chargés dans la version installée. Le code frontal consulté contient un chemin de soumission bloquée qui maintient l’état de chargement avant le POST. Ce cas demande de vérifier le composant et la version qui produisent ce comportement. L’indicateur seul ne permet ni d’attribuer la cause à cette branche ni d’établir un verdict serveur. Conservez les protections et écartez toute modification du drapeau dans la console.
- Comparer la page originale de recette à une page privée avec le formulaire inséré une seule fois.
- Si la page simple passe, exclure temporairement un seul script CF7 de l’optimisation suspecte dans la recette ou restaurer le réglage de chargement antérieur sur cette copie.
- Rejouer le même clic et vérifier que le script charge, qu’un seul POST part et que la confirmation est visible.
- Si la différence n’est pas reproductible, remettre le réglage initial et examiner le prochain candidat à partir de la console.
POST bloqué ou dévié, examiner la route et la couche qui répond
Si le POST reçoit 401 ou 403, identifiez l’émetteur à partir des en-têtes, du type de corps et des journaux. La route publique de soumission déclarée par CF7 est distincte des routes d’administration. Une authentification volontaire de la recette, une règle WAF ou un plugin de restriction peuvent intervenir avant le traitement. Si une règle de sécurité est soupçonnée, demandez l’identifiant de règle et corrélez-le avec le POST. Conservez les garde-fous et ne testez qu’un ajustement ciblé de recette, autorisé par le responsable de la règle.
Un 404 avec rest_no_route peut refléter un chemin ou une méthode incorrecte, une route indisponible ou un réacheminement. Comparez le chemin réel et la méthode. Vérifiez l’identifiant du formulaire et le sous-dossier. Un GET manuel vers feedback ne teste pas le POST, et un index REST accessible n’atteste pas qu’une règle laisse passer la soumission. Un 404 en HTML provient peut-être d’une couche différente. Une redirection vers la connexion, vers un autre domaine ou vers une autre forme de l’URL doit être relevée étape par étape.
Si le serveur répond 413 avec une pièce jointe, comparez le même parcours sans fichier quand le formulaire le permet. Relevez les limites du proxy et celles de PHP, ainsi que le type et la taille permis par le formulaire. Un 429 appelle un examen des limites de fréquence et des clics multiples. Un 500, 502 ou 504 impose de retrouver l’événement correspondant côté hébergement. Si le corps est en HTML avec un 200, cherchez une page de défi ou des avertissements PHP mêlés à la réponse.
Pour une requête en attente, corrélez le temps avec la phase navigateur et les traces serveur. Déterminez si l’origine a vu le POST et où la durée augmente. Un appel de vérification antispam, un traitement de fichier ou un add-on peut prolonger le traitement. Ne montez pas un délai global sur un seul essai. Un réglage ciblé sur la copie doit ramener une réponse JSON exploitable et maintenir les règles des autres routes.
JSON reçu, retrouver la confirmation masquée ou interrompue
Quand la réponse est bien du JSON, notez son status puis observez la zone .wpcf7-response-output et la console. Si le texte existe dans la zone mais reste invisible, inspectez les styles calculés et les parents. Une hauteur nulle, un panneau replié ou une règle d’affichage du thème peut expliquer le défaut. Comparez la même réponse avec le style minimal de la recette. Vérifiez au clavier et contrôlez le message associé au résultat.
Si le JSON porte une réponse mais que la zone est vide, recherchez une erreur après le POST. Un script de redirection, de suivi ou de fenêtre modale peut réagir au résultat, remplacer le formulaire ou tenter d’accéder à un élément disparu. Sur la copie, retirez un seul comportement suspect à la fois puis rejouez. Le correctif doit laisser le message accessible aussi lorsque la validation échoue, pour que l’utilisateur sache quoi corriger.
Si le réseau a répondu mais que vous ne savez pas si CF7 a traité le résultat, observez l’événement dans la console de la copie. Dans l’inspecteur, relevez l’identifiant du conteneur .wpcf7 qui entoure précisément le formulaire étudié. Remplacez ID_DU_CONTENEUR par cet identifiant. L’écouteur se retire au premier événement émis dans ce conteneur. Sur une page à plusieurs formulaires, un écouteur sur document pourrait capter le résultat du mauvais formulaire. Rechargez la page pour retirer un écouteur resté en attente. Gardez le détail de l’événement hors des journaux, car il peut contenir les champs soumis.
L’événement wpcf7submit indique que le script a reçu un résultat Ajax. Le code le déclenche avant la mise à jour du message visible. Il ne prouve aucune livraison de courrier. Son absence peut aussi résulter d’une soumission classique ou d’une erreur antérieure. Relisez toujours la réponse réseau. Si vous avez activé skip_mail, le résultat positif est attendu pour l’exercice de rendu et doit rester consigné comme une simulation.
const conteneur = document.getElementById('ID_DU_CONTENEUR');
if (conteneur?.matches('.wpcf7')) {
conteneur.addEventListener('wpcf7submit', (event) => {
console.info('CF7 — événement reçu', event.type);
}, { once: true });
}Vérifier la frontière avec l’antispam et le courrier
Si le JSON dit validation_failed ou signale une acceptation manquante, corrigez les champs ou vérifiez l’affichage des erreurs de validation. Le serveur a traité la demande. Si le JSON dit spam, notez le verdict et l’heure, puis recherchez la règle ou le module antispam. Évitez de modifier l’adresse expéditrice pour corriger ce verdict. Ces résultats peuvent coexister avec un défaut d’interface qui empêche leur affichage.
Le statut mail_failed donne une piste vers le traitement du courrier par WordPress ou vers le transport configuré. Consultez les journaux déjà disponibles et le validateur de la configuration du formulaire. Vérifiez les destinataires des deux modèles, le domaine de l’adresse From et les champs utilisés dans Reply-To. L’examen de la configuration peut être fait sans déclencher de courrier. Dans la recette, un transport simulé peut établir qu’une demande lui a été remise.
Quand le statut est mail_sent, vérifiez si le courrier était simulé. En fonctionnement normal, un résultat positif de wp_mail() ne prouve pas la réception dans une boîte. Recherchez dans les journaux existants un identifiant de message, un refus, un retard ou un classement par la messagerie destinataire. Cette analyse ne nécessite pas un nouvel envoi réel. Séparez dans votre rapport l’état de Contact Form 7 et le dernier événement connu du transport.
Si la confirmation a disparu mais que les journaux indiquent des traitements déjà aboutis, évitez toute relance sur le site public. Identifiez les résultats du test à l’aide d’un identifiant synthétique sur la recette. Si l’échec n’apparaît qu’avec une intégration réelle que vous ne pouvez pas simuler, consignez la limite et faites examiner les journaux du composant concerné.
Valider le correctif et remettre la copie à son état de référence
Préparez deux entrées de recette. Pour le témoin positif sans accès externe, choisissez un scénario avec une protection locale active qui admet cette entrée, ou une réponse simulée dans la recette autorisée. Conservez le courrier en simulation. Si le verdict dépend d’un moteur distant indisponible et que vous ne disposez pas de double autorisé, notez « validation distante non réalisée » et limitez les conclusions aux éléments effectivement observables.
La seconde entrée contient une erreur de validation volontaire. Lorsque le scénario le permet, vérifiez en anonyme et, si le défaut dépendait du rôle, avec le profil de recette concerné. Pour chaque tentative Ajax, les critères sont un POST unique, un JSON cohérent avec l’entrée choisie, la disparition du spinner et l’apparition d’un message distinct, visible et accessible.
Conservez la preuve minimale. Pour chaque essai, notez la page, le formulaire, les versions, la modification unique, l’heure, le statut HTTP et le résultat applicatif. Le test de rendu ne suffit pas à valider la livraison du courrier. Une réponse valide sur la copie ne suffit pas non plus à déclarer la cause prouvée sur la production si son proxy ou son cache diffère.
Annulez sur la copie les exceptions et exclusions temporaires qui n’ont pas expliqué le défaut. Remettez les réglages de la recette, retirez les écouteurs de console en rechargeant et supprimez du dossier de partage les traces détaillées non nécessaires. Pour revenir à l’état de départ, restaurez la configuration de recette et gardez les blocages des transports actifs. Retirez l’option skip_mail seulement après avoir vérifié que la copie reste isolée, si sa configuration initiale ne la contenait pas.
Si le défaut disparaît pendant les essais mais revient après restauration du réglage, reproduisez ce contraste une fois sur la copie et transmettez le changement minimal. Si les résultats divergent à réglages identiques, joignez les observations disponibles et qualifiez le diagnostic d’intermittent. La correction retenue doit rendre la réponse intelligible sans affaiblir les contrôles qui protégeaient le formulaire.
