Situer le refus avant de changer une limite
Contact Form 7 peut afficher une erreur sur le champ de fichier, recevoir un refus HTTP sans résultat du formulaire ou terminer son traitement alors que la pièce manque dans le courrier. Commencez par retrouver la première différence observable. Le même document peut respecter le plafond du champ et dépasser la taille du corps accepté par le proxy. Un formulaire accepté peut aussi avoir un modèle de courrier qui ne référence jamais ce fichier.
Récupérez un relevé existant de l’incident. Notez l’heure et son fuseau, la page, l’identifiant du formulaire, le nom technique du champ et la taille exacte en octets. Conservez l’extension et le type de document déclaré, sans prendre le document du visiteur. Si vous avez une trace réseau existante, relevez seulement la méthode, le chemin, le statut HTTP et le résultat applicatif. Une erreur de validation peut arriver dans une réponse HTTP réussie.
Pour une soumission Ajax, identifiez le POST de soumission de Contact Form 7, dont la route contient généralement feedback. Un JSON validation_failed avec une erreur associée au champ oriente vers les règles du formulaire ou le traitement PHP de ce fichier. Une réponse 413 ou une page HTML de passerelle demande d’identifier l’émetteur du refus. Un résultat spam décrit un filtrage différent. Une trace de courrier sans pièce jointe oriente vers le modèle de courrier, un add-on ou le transport.
Utilisez le signal le plus ancien de la chaîne. Si aucun POST n’est visible dans le relevé, commencez par le champ, le script ou le montage de la page. Si la trace s’arrête après le transfert, localisez la couche qui a reçu le corps. Si la pièce est seulement absente du courriel déjà reçu, examinez la liaison entre le nom du champ et sa balise de courrier. Ce tri évite une hausse globale des limites à partir d’un seul message d’erreur.
Préparer une copie et des documents d’essai
Identifiez une copie privée qui possède son propre domaine, sa base et son stockage. Relevez la version de WordPress, de Contact Form 7 et de PHP, ainsi que le thème, le constructeur et les extensions de téléversement qui entourent le formulaire. Comparez en lecture seule ces éléments à la configuration attendue. Un proxy absent de la copie, une version différente du plugin ou un dossier temporaire recréé changent la portée du résultat.
Avant toute édition, gardez le contenu des onglets Formulaire et Courrier dans un emplacement privé. Sur la recette, configurez le transport vers le collecteur local prévu par votre environnement et contrôlez les destinations des deux modèles. Retirez les secrets de production et neutralisez les webhooks, CRM et autres sorties réelles. Le courrier capturé doit rester consultable uniquement par l’équipe de test. Une option qui saute le courrier permet d’observer le formulaire, mais elle ne valide pas la remise de la pièce au transport.
Préparez des documents synthétiques distincts, sans données de visiteurs. Un petit PDF valide sert de témoin accepté si le formulaire annonce PDF. Un véritable fichier texte permet de contrôler un type interdit. Une paire de PDF de tailles différentes, de part et d’autre de la limite retenue, permet de vérifier le plafond. Notez la taille exacte en octets et un repère de contenu propre à chaque fichier. Sélectionner un document dans le champ ne prouve pas que le serveur l’accepte. Si un add-on téléverse dès cette sélection, l’isolation doit être prête avant d’ouvrir le sélecteur.
Commencez par les traces historiques et le validateur de configuration pour choisir la correction. Après cette correction, exécutez les essais synthétiques décrits plus loin sur la recette autorisée. Ne rejouez pas un POST enregistré et n’activez pas de journal global des corps. Si une intégration antispam distante est indispensable, utilisez sa configuration de recette et son accès de test autorisé, ou un double prévu par votre environnement. Sans moyen de franchir cette étape, le transfert complet reste à vérifier : consignez cette limite précise au lieu de présenter la lecture des réglages comme un essai réussi.
Approche 1 — Vérifier le champ, le type et le plafond du fichier
Dans Contact → Formulaires de contact, ouvrez le formulaire de recette et repérez la balise dans l’onglet Formulaire. file désigne un champ facultatif et file* un champ requis. Vérifiez le nom technique. Sur la page de recette, comparez-le au name de l’élément input de type file et au formulaire réellement affiché. Un ancien shortcode, un modèle de page mis en cache ou deux champs avec le même nom peuvent brouiller cette comparaison.
Spécifiez les formats nécessaires avec filetypes et le plafond avec limit. Contact Form 7 accepte des extensions ou des types MIME et sépare les valeurs par une barre verticale. Dans le code de CF7 6.2.4.1, les valeurs MIME servent notamment à dériver des extensions admises. L’attribut accept guide le sélecteur, et les règles du formulaire encadrent les types acceptés. Utilisez un véritable document synthétique dans le format voulu. Renommer un fichier ne change pas son contenu. Gardez séparé tout contrôle de contenu ou d’innocuité imposé par le site.
L’exemple ci-dessous demande un PDF et fixe 2 097 152 octets, soit 2 Mio. L’unité en octets rend la valeur sans ambiguïté. La documentation indique que la forme à suffixe attend un nombre entier. Une écriture décimale peut être ignorée. Si vous omettez les options, vérifiez les valeurs effectives pour la version utilisée plutôt que de supposer que le comportement par défaut autorise le PDF.
Si le problème ne concerne qu’une extension légitime, comparez la règle actuelle à la politique du site avant d’ajouter ce format. Si le fichier est trop grand pour le besoin prévu, annoncez la limite sur la page ou utilisez un document moins lourd. Sur la copie, enregistrez uniquement la modification retenue. L’état attendu est une balise valide, un nom unique, une aide visible et une restriction de type cohérente. Le retour arrière consiste à remettre le texte sauvegardé dans l’onglet Formulaire.
- Confirmer le formulaire réellement affiché et le nom du champ.
- Comparer l’extension, le format et la taille en octets du document fictif à la balise.
- Recharger la page de recette et vérifier que le champ généré correspond à la configuration.
[file* justificatif filetypes:pdf limit:2097152]Approche 2 — Comparer les plafonds de la requête et de PHP
Inventoriez les limites dans l’ordre du trajet. Un proxy ou le serveur web peut refuser le corps avant l’exécution de PHP. upload_max_filesize fixe une limite par fichier pour PHP. post_max_size porte sur l’ensemble des données du POST. La limite du champ Contact Form 7 intervient à son tour lorsque le plugin traite le fichier. Vérifiez les réglages effectifs du site de recette et de son service PHP web. Les valeurs d’un PHP lancé en ligne de commande peuvent être différentes.
Dans un formulaire multipart, le corps contient les fichiers, les autres champs et les séparateurs. Deux fichiers admis séparément peuvent dépasser le plafond total. Par exemple, deux documents fictifs de 2 097 152 octets occupent déjà 4 194 304 octets avant le reste du corps. Une limite exactement égale à cette somme est insuffisante. Comparez des valeurs exprimées dans la même unité et gardez une marge pour le reste du formulaire en suivant le plafond de votre hébergement.
Si une trace montre un 413 émis par NGINX, la directive client_max_body_size est une piste à confirmer dans le contexte du serveur ou de la route concernée. Si Apache a émis le refus, vérifiez plutôt LimitRequestBody dans le contexte applicable. Un CDN ou une règle de sécurité peut aussi produire ce statut. Si le serveur a transmis la requête à PHP mais que le corps dépasse post_max_size, les tableaux de champs et de fichiers peuvent être vides. L’erreur visible côté WordPress peut alors ressembler à un champ manquant plutôt qu’à un 413.
Comparez la taille relevée à la limite effective de chaque couche et cherchez la première qui explique les traces. Si un ajustement est justifié, faites-le uniquement sur la recette et dans le périmètre convenu. Conservez l’ancienne valeur et validez la configuration avec la procédure de l’hébergeur. Une hausse locale du plafond de PHP n’aura aucun effet si le refus est déjà décidé par le proxy. Remettez le réglage précédent si la première couche en défaut n’est pas celle que vous avez changée.
Lire les erreurs PHP et vérifier les deux espaces temporaires
Une erreur remontée par le champ peut provenir de PHP avant la vérification de la taille ou du type par CF7. Les codes PHP distinguent notamment un plafond de fichier dépassé, un transfert partiel, un fichier absent, un dossier temporaire introuvable et un échec d’écriture. Les libellés UPLOAD_ERR_INI_SIZE, UPLOAD_ERR_PARTIAL et UPLOAD_ERR_NO_TMP_DIR distinguent respectivement la limite PHP par fichier, un transfert incomplet et un dossier temporaire absent. Dans les journaux privés existants, cherchez le code ou le message corrélé à l’heure et à la route. Un message générique du formulaire ne permet pas d’attribuer à lui seul l’erreur au type.
PHP reçoit d’abord le fichier dans son espace temporaire. Après les contrôles, Contact Form 7 déplace les fichiers acceptés dans son propre répertoire de travail. La documentation donne comme emplacement par défaut un dossier wpcf7_uploads sous le chemin des téléversements WordPress, souvent wp-content/uploads. Un chemin personnalisé peut expliquer une différence. L’absence de fichier dans ce dossier après une demande ancienne est attendue dans le déroulement normal, car le plugin nettoie les fichiers à la fin.
Dans la copie, faites vérifier l’espace libre, le quota, le chemin résolu et les droits du compte du service PHP, ainsi que les éventuelles restrictions de chemin. L’utilisateur SFTP et le processus PHP peuvent avoir des droits différents. Distinguez le dossier temporaire PHP du dossier de travail CF7. Un dossier présent ne garantit ni la capacité d’écrire ni le bon propriétaire. Évitez de rendre le répertoire accessible publiquement ou inscriptible par tout le monde.
Si une trace confirme un chemin erroné ou un droit manquant, corrigez seulement le répertoire de recette identifié, selon les règles de l’hébergeur. Préservez le propriétaire et les droits précédents avant modification. Validez le chemin et la capacité du service sans déposer de fichier de visiteur. Un contrôle local des droits et du quota apporte une preuve de configuration. Le transfert effectif reste à valider séparément.
Approche 3 — Vérifier le rattachement au modèle de courrier
Si le champ est accepté selon les traces existantes et que le courriel arrive sans pièce jointe, ouvrez l’onglet Courrier du formulaire concerné. Dans Pièces jointes, recherchez la balise qui correspond exactement au nom du champ. Pour le champ justificatif de l’exemple, il s’agit de [justificatif]. Insérer cette balise dans le corps du message ne configure pas la pièce jointe. Si le formulaire comporte plusieurs fichiers, associez chaque champ nécessaire selon le modèle prévu.
Vérifiez quel modèle a servi au courriel étudié. Courrier (2), quand il est activé, peut être un accusé de réception avec ses propres paramètres. Une pièce prévue pour l’équipe peut être exclue de ce second modèle par choix. Ne recopiez pas automatiquement les pièces dans un message qui repart vers le visiteur. Lorsque le champ est facultatif, un message sans pièce peut correspondre à une soumission sans fichier.
Même si la balise est correcte, vérifiez le filtre entre Contact Form 7 et wp_mail(). Dans la version 6.2.4.1, CF7 résout le chemin sous le répertoire de contenu WordPress. Il écarte une pièce hors du répertoire autorisé, qui ne correspond pas à un fichier ou qui est illisible. Il écarte aussi la pièce dont l’ajout ferait dépasser 25 Mio cumulés de fichiers retenus pour ce modèle. Vérifiez le chemin, la lisibilité pour le service PHP, la somme des tailles et les avis déjà présents dans les traces privées.
Le courrier transmis à wp_mail() peut donc être accepté alors qu’une pièce a déjà été écartée. Comparez le plafond cumulé de CF7 à part de celui du corps du POST et de la taille du message MIME après encodage. Le transport ou la messagerie destinataire peut appliquer ses propres limites. Le statut mail_sent renseigne sur le traitement de l’application. Pour attribuer l’absence de la pièce, utilisez la dernière étape documentée dans les traces.
Appliquez, si nécessaire, la correction minimale dans le modèle de recette et vérifiez les avertissements du validateur. Pour revenir à l’état antérieur, restaurez la section Pièces jointes du bon modèle. Le résultat attendu à cette étape est un lien exact entre balise et champ, avec un destinataire prévu pour ce contenu. Gardez le transport de recette isolé.
- Identifier le modèle de courrier correspondant à la trace existante.
- Vérifier la balise dans Pièces jointes et contrôler séparément Courrier (2).
- Relever les avertissements de configuration, puis vérifier la pièce dans le courrier capturé lors de l’essai de recette décrit plus loin.
[justificatif]Vérifier la correction avec des fichiers synthétiques
Gardez la modification limitée à la couche identifiée : règle du champ, plafond du corps, chemin temporaire ou modèle de courrier. Avant le premier clic, vérifiez que le transport pointe vers le collecteur local et que les traitements annexes restent isolés. Si skip_mail: on a servi au diagnostic, retirez-le du seul formulaire de recette après ce contrôle, afin que CF7 remette effectivement le courrier et ses pièces au transport capturé. Conservez sa valeur initiale pour le retour arrière.
Ouvrez la page de recette dans un profil navigateur distinct, puis le panneau Réseau. Le premier témoin doit contenir tous les champs requis et un petit fichier admis. Cliquez une seule fois. Relevez le POST feedback, le statut HTTP, le champ status et le message visible. Pour une réponse mail_sent, ouvrez ensuite le message correspondant dans le collecteur local à partir de son heure et du marqueur synthétique. Vérifiez la présence de la pièce, son nom, son nombre d’octets et son contenu fictif. Ce contrôle établit la remise au collecteur de recette, sans promettre une livraison dans une boîte réelle.
Pour un type ou une taille interdits, faites une nouvelle tentative avec un seul paramètre modifié. Le rejet doit correspondre à la couche visée : erreur associée au champ pour la règle CF7, ou code et trace de la couche qui limite le corps si ce plafond est volontairement testé. Vérifiez qu’aucun message de cette tentative rejetée n’apparaît dans le collecteur. Un blocage local du sélecteur ne démontre pas à lui seul le rejet serveur. N’élargissez pas les limites pour faire passer le témoin qui doit rester refusé.
Si le courrier est capturé sans pièce malgré un champ accepté, revenez au bon modèle, au nom de balise, au chemin lisible et au cumul des pièces. Si la réponse est mail_failed, inspectez le transport de recette. Si elle est spam, traitez le filtre séparément. Un résultat ambigu reste incomplet : il ne justifie pas une hausse simultanée des plafonds. Contrôlez enfin que l’aide visible du champ annonce les formats, unités et limites réellement vérifiés.
- Noter l’état initial du formulaire et le réglage de transport local ; confirmer l’isolement des intégrations.
- Soumettre une seule fois le petit fichier admis avec des données synthétiques et relever le résultat réseau et CF7.
- Retrouver la même tentative dans le collecteur local et ouvrir sa pièce jointe pour comparer taille et contenu.
- Soumettre séparément un témoin de type interdit et un témoin dépassant la limite utile ; constater leur rejet et l’absence de courrier capturé.
- Revenir au fichier admis pour vérifier que le parcours positif fonctionne toujours après les témoins refusés.
- Consigner les résultats observés, puis restaurer les réglages temporaires et supprimer les fichiers et courriers de test selon la politique de recette.
Documenter les preuves et préparer le retour arrière
Remettez une fiche de diagnostic avec le formulaire, le champ, la version, les octets du document fictif et l’ordre des couches. Pour une trace historique, notez l’heure, le code HTTP, le type de réponse, le motif expurgé et la couche qui a répondu. N’y incluez ni document du visiteur, ni contenu multipart, ni courriel brut. Si les traces existantes donnent des résultats différents, notez la divergence.
Un contrôle de configuration est concluant quand le champ, le plafond et la balise sont cohérents avec le besoin. La validation du parcours va plus loin : elle doit montrer un document admis dans le courrier capturé, des témoins interdits refusés par la couche prévue et un message compréhensible pour le visiteur. Notez séparément ce qui a été lu, soumis et reçu par le collecteur. Si une étape n’a pas pu être exécutée, indiquez laquelle et la condition manquante. Le transport externe de production reste un périmètre distinct.
Si une modification n’explique pas le symptôme, restaurez le texte d’origine de Formulaire et Courrier ou la limite précédente de la couche visée. Remettez le réglage temporaire skip_mail à son état initial, en conservant le transport local et l’isolement de recette. Vérifiez le retour de la valeur effective, puis retirez les documents et messages synthétiques. Gardez seulement les résultats expurgés nécessaires au diagnostic dans l’emplacement privé prévu.
Pour une remise à l’hébergeur, donnez le domaine de recette, l’heure, la route et la taille, puis demandez quelle couche a rejeté le corps ou empêché l’écriture. Pour une remise au responsable éditorial, indiquez le champ et le modèle concernés. Une seule proposition de modification appuyée par le signal observé est plus facile à vérifier et à annuler qu’une hausse simultanée de toutes les limites.
