[Résolu] Pbm Formidable suite mise à jour de sécurité saisies 5.1.11

Bonjour,
Dans un spip 4.3.6 complètement à jour avec un formulaire de réservation de panier suivi d’enregistrement, envoi de mail et paiement, j’ai une erreur fatale suite à la mise à jour de Formidable (7.0.3) + Saisies (5.1.11). L’erreur se produit à la soumission du formulaire, cela n’affiche plus le bouton de paiement, l’erreur semble liée à l’envoi de mail:

Fatal error: Uncaught TypeError: traiter_email_envoyer_destinataires(): Return value must be of type bool, array returned in /home/eplocfr/public_html/plugins/auto/formidable/v7.0.3/traiter/email.php:884 Stack trace: #0 /home/eplocfr/public_html/plugins/auto/formidable/v7.0.3/traiter/email.php(65): traiter_email_envoyer_destinataires() #1 /home/eplocfr/public_html/plugins/auto/formidable/v7.0.3/formulaires/formidable.php(514): traiter_email_dist() #2 /home/eplocfr/public_html/ecrire/public/aiguiller.php(288): formulaires_formidable_traiter_dist() #3 /home/eplocfr/public_html/ecrire/public.php(104): traiter_formulaires_dynamiques() #4 /home/eplocfr/public_html/spip.php(20): include('...') #5 {main} thrown in /home/eplocfr/public_html/plugins/auto/formidable/v7.0.3/traiter/email.php on line 884

Il y a une ou 2 bidouilles javascript pour reporter dans un input contenant le total à payer d’un choix entre 2 valeurs (une 20€ et une 30€) et une bidouille pour cacher le bouton de validation si la case à cocher d’acceptation des CGV n’a pas été cochée, mais d’après l’erreur ci-dessus et de par le fait que je peux valider, je ne pense pas que ce soit la cause …

La mise à jour a été faite depuis la v6 de Formidable donc je ne sais pas si le pbm vient de Formidable ou du nouveau Saisies, je pencherai pour Formidable puisque j’ai vu que cette maj avait pour but de justement rendre possible de configurer le traitement « envoyer par email » de sorte à 2 envoyer deux emails : un au moment de la soumission du formulaire, l’autre au moment de la validation. … par contre je ne vois pas ou gérer cette possibilité, donc pas sûr de comprendre si c’est quelque chose que je dois régler et qui peut être la cause de mon pbm …

Je n’ai pas de traitements spécifiques, pipelines ou autres, donc je ne m’étais pas inquiété, par contre j’ai le même genre de process sur un autre site sans problème donc je cale. Celui qui a le pbm utilise Facteur + Brevo, l’autre juste Facteur + SMTP …

Donc j’ai basculé le site à pbm sur Facteur + SMTP et bingo ça remarche …
Il semble qu’il y ait un pbm entre Formidable v7 et l’envoi par Brevo (pas testé Mailjet) … Votre avis ?

Bonjour,

encore une fois lorsqu’il s’agit de debug formidable, un export yaml permet d’y voir nettement plus claire.

Donc : peux tu envoyer l’export .yaml de ton formulaire?

Par ailleurs

Il y a une ou 2 bidouilles javascript pour reporter dans un input contenant le total à payer d’un choix entre 2 valeurs (une 20€ et une 30€) et une bidouille pour cacher le bouton de validation si la case à cocher d’acceptation des CGV n’a pas été cochée, mais d’après l’erreur ci-dessus et de par le fait que je peux valider, je ne pense pas que ce soit la cause …

Alors pour ce genre de choses (dont je ne pense pas qu’il y ait un lien avec ton problème) tu as

  1. Le plugin « saisie calcul » qui s’occupe de cela très bien et en toute sécurité pour s’assurer que personne ne truande le total
  2. Une option livrée nativement avec formidable qui permet de ne pas afficher le bouton de validation selon des conditions afficher_si (dans les options globale du formulaire au moment où tu édite les champs) + tu peux rendre obligatoire une case à cocher de sorte que la personne ne puisse pas valider pour autant si le js est descativé)

J’ai fait un message direct pour le yaml, je regarderai pour le javascript, ce formulaire date d’avant ces fonctions …
Merci !

petite précision : pour tout formulaire qui envoi un truc à payer, il convient par précaution d’activer l’option « Valider les valeurs acceptables » dans la config general des saisies. SInon n’importe qui peut tricher.

Ah mais j’avais pas vu cela.

Alors je ne pense pas que ce soit directement un problème de formidable avec Brevo.

Ce sont deux problèmes différents qui se combinent

  1. D’une part du peu que je vois dans le code de facteur/mailshot il se peut qu’en cas d’erreur dans la fonction envoyer_mail, celle-ci renvoi autre chose qu’un booleen, en dépit de la doc. Hors formidable s’attendait à recevoir un booleén, D’où le message que tu obtenais.
  2. Par ailleurs tu a peut 'etre un problème de configuration d’envoi de maik par brevo : tu a fait un test dans la config de facteur au moment où c’était réglé ainsi.

Quoi qu’il en soit j’ouvre un ticket chez facteur.

Ah non c’est l’inverse : c’est en cas de succès que l’envoi de mail par brevo envoi un tableau, alors que la doc général indique que c’est censé envoyé un booléen.

Et c’est bien cela le problème. Donc le souci se trouve au niveau de mailshot, pas de formidable.

Merci beaucoup pour les investigations et le diagnostic.

Cela se situe ou ? si je vais dans la gestion des plugins sur Saisies/Configurer la seule option que j’ai c’est Charger le javascript et les CSS sur toutes les pages, dans la balise <head>.
Ou alors je dois chercher dans Formidable sur mon formulaire ?

quoi donc ?

Tu as dit « il convient par précaution d’activer l’option « Valider les valeurs acceptables » dans la config general des saisies. », je ne vois ou ça se trouve …

Ah oui c’est la configuration des saisies au niveau du formulaire.

Lorsque tu règle les saisies du formulaire, tout en haut tu as un bouton « Configurer les options globales ». Dans l’onglet « Technique » cliquer sur « Vérifier les valeurs possibles ».

ATTENTION : si tu a des valeurs calculés dynamiquement par JS (hors saisies calcul qui prend en compte cela) cela peut planter.

Ok merci je vois ou c’est maintenant, je vais regarder.

La version de mailshot 3.4.2 qui vient de sortir corrige le problème.

Merci !

@Pierr0t Attention cette version 3.4.2 ajoute d’autres problèmes. Met à jour vers 3.4.3, et met à jour facteur.