Un e-mail de confirmation de contact, puis un second, identique à quelques secondes d’intervalle. C’est le signalement remonté par le support client d’un site institutionnel traduit avec Polylang, quelques jours après une mise à jour de Gravity Forms. Le comportement touchait uniquement les visiteurs qui soumettaient le formulaire depuis une version traduite du site, jamais depuis la version française d’origine.
Ce cas ne concerne pas la traduction des libellés du formulaire lui-même, un sujet déjà traité par ailleurs et qui se règle simplement via l’outil de traduction de chaînes de l’extension multilingue : il porte sur un comportement de duplication d’envoi propre à la structure de formulaires dupliqués par langue.
Symptôme : deux e-mails, une seule soumission
Sur ce site, chaque formulaire existait en plusieurs exemplaires, un par langue, une pratique courante avec Gravity Forms sur les sites multilingues qui n’utilisent pas de mécanisme de traduction dynamique des champs de formulaire mais dupliquent purement et simplement le formulaire par langue, chaque exemplaire étant inséré via un bloc ou un shortcode différent selon la page. Après la mise à jour de Gravity Forms, une notification configurée sur le formulaire source (en français) s’est mise à se déclencher également pour les soumissions effectuées sur le formulaire traduit associé, en plus de la notification propre à ce formulaire traduit.
Diagnostic : une condition de notification devenue trop permissive
La cause identifiée après investigation tenait à une condition de déclenchement de notification (fonctionnalité de Gravity Forms qui permet de n’envoyer une notification que si certains champs remplissent une condition donnée) configurée sur un champ caché commun aux deux formulaires, un champ utilisé pour identifier la langue de soumission via une valeur par défaut différente selon la langue. La mise à jour de Gravity Forms avait modifié légèrement l’évaluation de cette condition dans un cas de valeurs vides ou non initialisées, ce qui faisait basculer la condition du côté « vrai » pour les deux formulaires simultanément dans certains scénarios de soumission rapide.
Concrètement, la notification du formulaire français, censée ne se déclencher que si le champ caché valait fr, s’est mise à se déclencher également quand ce champ restait temporairement vide au moment de l’évaluation de la condition, un cas de bord que l’ancienne version de Gravity Forms ne rencontrait jamais dans ce contexte précis.
Le correctif
La première réparation, immédiate, a consisté à durcir la condition de notification pour qu’elle ne se déclenche que sur une valeur explicitement égale à la langue attendue, jamais sur une absence de valeur, en utilisant l’opérateur is plutôt qu’une condition implicite de non-vide :
// Réglage de la condition de notification dans Gravity Forms
// Avant : "Langue" n'est pas vide → trop permissif après mise à jour
// Après : "Langue" est égal à "fr" → strictement explicite
La seconde réparation, plus structurelle, a consisté à ne plus faire reposer la distinction de langue sur un champ caché à valeur par défaut, mais sur une valeur injectée explicitement par PHP au chargement du formulaire, via le filtre gform_pre_render de Gravity Forms, qui garantit que le champ est toujours renseigné avant toute évaluation de condition :
add_filter( 'gform_pre_render_12', function( $form ) {
$lang = function_exists( 'pll_current_language' ) ? pll_current_language() : 'fr';
foreach ( $form['fields'] as &$field ) {
if ( 'hidden_lang' === $field->inputName ) {
$field->defaultValue = $lang;
}
}
return $form;
} );
Prévention à la prochaine mise à jour
Le point de vigilance à retenir pour tout site combinant Gravity Forms et une structure de formulaires dupliqués par langue est de considérer toute mise à jour majeure de Gravity Forms comme un déclencheur de vérification systématique des conditions de notification sur les formulaires multilingues, en environnement de recette d’abord, jamais directement en production. Un test de soumission complet sur chaque langue, avec vérification du nombre d’e-mails effectivement reçus, reste le moyen le plus fiable de détecter ce type de régression avant qu’un client ne s’en plaigne.
- Ne jamais faire reposer une condition de notification sur une valeur potentiellement vide
- Injecter la langue via un filtre PHP explicite plutôt qu’une valeur par défaut de champ
- Tester systématiquement chaque formulaire multilingue après une mise à jour majeure de Gravity Forms
- Compter le nombre réel d’e-mails reçus lors du test, pas seulement la présence d’un e-mail
En résumé
Une notification dupliquée après mise à jour n’est presque jamais un hasard : c’est le signe qu’une condition de déclenchement, pensée pour un cas précis, se comporte différemment face à une valeur de champ absente ou mal initialisée. Sur un site multilingue où les formulaires sont dupliqués par langue, ce risque augmente mécaniquement, ce qui justifie un test systématique après chaque mise à jour de l’extension de formulaires.
