Cette documentation est valable à partir de la version 6.1.0 de Formidable.
Introduction
Historiquement, deux plugins avaient déjà été développés précédemment pour gérer des formulaires :
- Forms &Tables, qui n’a pas été complètement porté pour SPIP 2.
- et spip-formulaire créé par artego mais qui n’était plus maintenu.
La question s’est donc posée : construire sur la base d’un des deux plugins ou repartir de zéro ?
Form &Table, très complet pour les utilisateurs, présentait l’inconvénient d’avoir un côté “fourre-tout” qui le rendait difficilement modifiable et difficile à personnaliser par les dévs.
Il a finalement été décidé de repartir de zéro pour proposer quelque chose:
- de plus facile à utiliser pour les utilisateurs d’une part,
- mais aussi de plus facile à personnaliser pour les développeur⋅euses.
Avec le parti pris de se baser de préférence sur plusieurs petits plugins spécialisés et de tirer parti de la nouvelle norme CVT.
Interface utilisateur
triceL’utilisation basique de l’interface est abordée dans ce screencast : Mon premier formulaire pas à pas : c’est Formidable !
Appeler mon formulaire
Vous devez appeler le formulaire ayant le nom “formidable”, en lui passant en paramètre l’identifiant de votre formulaire.
Dans un contenu
Utilisez le modèle <formulaire>
classique : <formulaire|formidable|id=34>
ou bien <formulaire|formidable|id=contact>
Dans un squelette
#FORMULAIRE_FORMIDABLE{34}
ou bien #FORMULAIRE_FORMIDABLE{contact}
Afficher les résultats du formulaire
Dans un contenu
Utilisez le modèle <formulaire_analyse|id_formulaire=34>
Pré-remplir dynamiquement les champs d’un formulaire
À noter, vous avez la possibilité de surcharger dans l’appel, les valeurs par défaut des champs de votre formulaire. Pour cela, vous devez passer un tableau de nom=>valeur
en deuxième paramètre. Vous pourrez trouver les noms de vos champs dans l’aide-mémoire situé sur la page de configuration des traitements.
Dans un contenu
Le tableau de valeurs dans un paramètre defaut sous forme d’une suite de chaînes “clé,valeur” séparée par des virgules :
<formulaire|formidable|id=contact|defaut=hidden1,valeur,input_5,autrevaleur>
Dans un squelette
Le tableau en deuxième paramètre :
#FORMULAIRE_FORMIDABLE{contact, #ARRAY{nom_du_champ, Ma valeur}}
C’est particulièrement utile pour remplir un champ caché avec une valeur dynamique venant du squelette :
#FORMULAIRE_FORMIDABLE{contact, #ARRAY{hidden_1, #ID_DOCUMENT}}
Autres options utilisable dans le squelette
Il est possible de passer des options comme troisième argument du formulaire, sous forme de tableau (#ARRAY
).
Nom de l’option | Fonction | Type |
---|---|---|
forcer_modif |
Permet de forcer la modification d’une réponse, même si non autorisé | Booléen |
id_formulaires_reponse |
Identifiant de la réponse à modifier | Entier |
no_ajax |
Désactiver l’ajax sur le formulaire | Booléen |
traiter_enregistrement_desactiver_modif_instituer_prop |
Permet de désactiver au cas par cas l’option de configuration « Lorsque l’internaute modifie la réponse, son statut redevient « proposée » » | Booléen |
traiter_email_destinataires |
Destinataires pour le traitement | Tableau (#ARRAY ) d’emails ou liste d’emails séparés par des virgules |
traiter_email_destinataires_methode |
Indique si traiter_email_destinataires doit remplacer les emails déjà configurés dans le traitement ou les ajouter |
Au choix 'remplacer' ou 'ajouter' (valeur par défaut) |
url_redirect |
Url de redirection | Chaine |
Exemple d’un formulaire Formidable dont l’identifiant est contact_libre et dont l’email destinataire est dans le champ email de la table de votre objet #EMAIL de la table spip_contacts …
.
<div class="ajax">
#FORMULAIRE_FORMIDABLE{contact_libre,'',#ARRAY{traiter_email_destinataires,#EMAIL}}
</div>
Case unique
Pour rendre obligatoire la réponse oui à une case unique (pour la validation de conditions d’utilisation par exemple), il faut simplement rendre le champ obligatoire.
Courriels de notification
Une option des traitements proposés permet d’envoyer un mail de notification automatiquement, à chaque saisie d’un formulaire.
Le squelette par défaut employé pour la mise en forme de ces mails est plugins/formidable/notifications/formulaire_email.html
. Vous pouvez le copier dans le répertoire ’notifications’ de votre squelette et l’y modifier à votre guise. Cette modification vaudra pour tous les formulaires.
Pour utiliser un squelette spécifique pour les mails de notification de l’un seulement des formulaires définis avec Formidable, il suffit d’ajouter son squelette dans le répertoire ’notifications’ de votre dossier squelettes, mais en ajoutant l’identifiant.
IDENTIFIANT étant l’identifiant du formulaire défini dans Formidable, les squelettes doivent se nommer :formulaire_IDENTIFIANT_email.html
pour le mail aux destinatairesformulaire_IDENTIFIANT_accuse.html
pour l’accusé de réception du visiteur
Conservation des IP
Les adresse IP des personnes répondant aux formulaires sont stockées en base de donnée. Depuis la version 1.5 (SPIP 3) / 0.7 (SPIP < 3), elle sont automatiquement hashé, de manière à ce que l’IP ne soit plus reconnaissable, au bout de 124 jours (environ 4 mois).
Pour changer ce délai, vous pouvez redéfinir la constante _CNIL_PERIODE
dans votre fichier mes_options.php
.
Par exemple :
define('_CNIL_PERIODE', 24*3600);
permet de hasher les IP toutes les 24 heures.
Si vous voulez désactiver le hashage, mettez la valeur à 0.
Envoi de fichiers
Lire l’article complémentaire : Envoyer des fichiers avec un formulaire Formidable.
Mise en forme des saisies
Le plugin ne prévoit aucun réglage de mise en forme des saisies : c’est à chaque squelette d’avoir ses styles. Il respecte cependant la convention d’écriture des formulaire SPIP. Il permet d’ajouter des classes spécifiques sur les saisies.
Affichage des réponses sous forme de tableau
Le plugin Formidable Tablesorter permet d’afficher sous forme de tableau les réponses, dans l’espace privé, avec possibilité de tri et de filtre.
Voir aussi sur le wiki
- Complément de doc et exemples sur les boucles et balises de formidable
- Exemples de stylage CSS d’un formulaire Formidable
- todoFormidable
- Formidable, présentation aux Grottes (2010)
Discussions by date of activity
837 discussions
toute petite remarque également pour avis, au sujet d’un plugin qui pourrait bien être incompatible avec formidable : le plugin “Recommander”
qui ajouterait une seconde remarque qui me semble avoir été déjà vue dans les commentaires : la présence de deux formulaires “formidable” sur une même page semble poser également des problèmes (mais pas les mêmes) : ils se synchronisent.
appel aux/à l’expert
de toutes façons : quelle merveille ce plugin in qui porte si bien son nom!
Cela veut dire quoi “ils se synchronisent” ?
et “qui pourrait bien être incompatible avec formidable : le plugin « Recommander »” : en quoi cela serait incompatible ?
bonjour Maîeul,
j’ai passé un bon moment pour comprendre ce qui mettait en rose la page publique dans laquelle j’avais placé un formulaire formidable, signalant 1 erreur dans le squelette sans trop comprendre ce qui était écrit en rouge. J’ai fait un certain nombre d’essais et j’allais même me demander si je n’allais pas être obligée de réinstaller le site.
j’ai décidé finalement de commencer par supprimer 1 à 1 les inclusions (inclure ..., et les ajouts pour voir lequel posait problème le cas échéant.
Le premier était l’inclusion de “recommander à un ami” (plugin recommander) #RECOMMANDER #TITRE,#URL_ARTICLE,#TEXTE avec ses accolades.
Résultat immédiat : plus de fond rose avec ses caractère rouge et le “1 erreur dans le squelette” avait disparu. Bingo!
Mais j’avais déjà eu un problème en ayant mis 2 formulaires formidable dans la même page (je ne me souviens plus si c’était ou non deux mêmes formulaires), du coup j’ai du les retirer et m’arranger autrement.
Il s’agissait de deux pavés côte à côte pour deux activités (de canoë) avec chacun un bouton de réservation faisant apparaître le formulaire de réservation.
et si on remplissait un de ces deux formulaires, l’autre suivait idem (pas très explicite mais je n’ai pas très envie de renouveler l’expérience ...)
du coup, j’en ai conclu qu’il valait mieux ne pas mettre deux formulaires dans la même page.
Pour le second point, c’est résolu avec les dernières versions de formidable
Et du coup pour le premier point, probablement que votre syntaxe d’inclusion était mauvaise, et que cela n’avait rien à voir avec formidable.
Reply to this message
Bonjour,
Avec un formulaire 7.1.0 sous SPIP 4.4, si on désire ne pas mettre de label à l’adresse email (juste un placeholder), cette alternative n’apparait pas quand on doit sélectionner le champ contenant l’adresse de la personne qui remplit le formulaire. Il faudrait soit afficher le placeholder si le label n’existe pas, soit rendre le label de l’email obligatoire...
Ne pas mettre de label est une mauvaise pratiqe en terme d’accessibilités. Nous n’encouragerons donc pas cette possibilité.
Pour aller plus en détail, le placeholder n’a pas de rapport avec le label, il ne sert pas à le remplacer. Il sert à y mettre *un exemple* de remplissage possible, mais pas à indiquer le nom du champ (qui ne doit pas disparaitre quand on est en train de remplir).
Bonjour à vous,
Merci pour votre réponse rapide, oui, je comprends très bien qu’il faille de préférence associer un label pour les champs, mais ce label n’étant pas obligatoire, on peut être tenté de ne pas le renseigner.
Ainsi, si on ne renseigne pas le label de l’email, on est confronté à un problème d’affichage des alternatives pour le traitement du formulaire, champ “contenant l’adresse de la personne”. C’est juste déroutant (on pense alors à un bug).
Ah oui. Bon bah ca apprendra aux gens à avoir des droles d’idées.
Bon j’ai ouvert une MR en ce sens, mais j’ai encore un peu de doute.
https://git.spip.net/spip-contrib-extensions/saisies/-/merge_requests/523
Reply to this message
bonjour
après de premeirs essais de formulaires simples type contact ou pétition, je veux créer un questionnaire (15 questions en 5 thèmes) et en faire une présentation soignée avec des images...
je vois qu’on peut ajouter des documents spip dans le questionnaire, mais mes essais sont infructueux, je crée un document, je choisis une image dans la médiathèque de mon site, mais il ne semble pas l’enregistrer ...
D’autre part, je me demande comment le positionnement d’une image peut être gérée en affichage... il faut entrer dans le css ?
existe-t-il une doc plus détaillée sur ce sujet ?
merci d’avance
Bonjour,
pour insérer une image au milieu d’un formulaire, il faut utiliser la saisie
explication
et insérer dans le texte de celle-ci le raccourci d’insertion d’image comme pour l’insertion d’une image dans un article (<docxx>
).Reply to this message
Bonjour,
Les formulaires Formidable ne fonctionnent pas depuis la webview de l’app Linkedin sur mobile (au moins IOS). À la soumission, le message d’erreur suivant apparait : “Impossible de prendre en compte votre message. Merci de le soumettre à nouveau !”
J’ai tenté plusieurs modes d’intégration (shortcode, balise, ajax désactivé) mais rien n’y fait.
Le problème est que le champ
formulaire_action_sign
est vide.Voici le log complet (généré à la soumission de https://reuseeconomyexpo.com/appel-de-paris/) :
Et voici comment le formulaire est intégré dans le squelette :
Quelqu’un aurait une idée de comment résoudre ce problème ?
Je ne sais pas ce qu’est le “webview de l’app Linkedin.” Mais effectivement ce n’est pas normal que le champ formulaire_action_sign soit vide et c’êst sans doute effectivement la cause du problème.
Mais je ne comprend pas pourquoi c’est vide chez vous. Normalement c’est quelque chsoe qui est generé automatiquement par SPIP.
je soupconne très fortement une surcharge maladroite de squelettes SPIP ou bien un plugin/un pipeline qui vient s’interferer dans le processus.
En tout cas je ne pense pas que l’appel soit en cause, même si je suis étonné de cet
{id_rubrique}
sur la boucle et de#IDENTIFIANT
. Mais sans doute avez vous quelque chose en interne qui gère cela.@maieul le plugin a une table de liaison donc on peut sortir les formulaires “liés à”… ce qu’on veut dont un id_rubrique, c’est SPIP qui fait la jointure comme il faut ensuite. Et #IDENTIFIANT bé c’est le champ de base de la table spip_formulaires pour ne pas utiliser les id SQL, ya rien de particulier.
@Maieul Concernant la “webview de l’app Linkedin” : lorsque l’on clique sur un lien depuis l’application mobile Linkedin, l’URL correspondante n’est pas ouverte dans le navigateur web du mobile, mais dans une “webview”, c’est à dire une fenêtre intégrée à l’appli, une sorte d’iframe. Cela permet aux applications d’éviter que les utilisateurs quittent l’application. Le problème ne vient pas d’une “surcharge maladroite de squelettes SPIP ou bien un plugin/un pipeline qui vient s’interferer dans le processus”, car le formulaire fonctionne très bien dans n’importe quel navigateur. Le problème vient de la manière dont est générée la valeur du champ
formulaire_action_sign
, qui est perturbée dans le contexte d’une webview.Bah ecoutez.
Si je me rend sur
https://reuseeconomyexpo.com/appel-de-paris/ et que je regarde le code source de la page (avec firefox) j’ai ca
avec donc un formulaire_action_sign vide, alors même que je suis sous firefox. Donc le problme de formulaire_action_sign vide n’est clairement pas lié à linkedin.
Bon cela étant, je viens de tester sous firefox et j’arrive bien à remplir effectivement (merci d’annuler ma signature à ce machin).
Donc sans doute effectivenent un problème spécifique à linkdedin, mais sans doute pas le formulaire_action_sign.
Dans tous les cas le problème semble plus large que formidable (qui ne s’occupe que de construire le formulaire, pas de la mecanique sous jacente des formulaires dans SPIP).
Il serait bon de poser la question sur discuter.spip.net
Il faudrait vérifier le log précis dans les fichiers de logs de spip.
cela permettrait de savoir précisement la cause de l’erreur et de creuser plus loin
Reférence sur les différents messages de log
https://git.spip.net/spip/ecrire/blob/4.4/public/aiguiller.php#L206
Effectivement formulaire_action_sign est géré par Spip et non Formidable, je vais poser la question sur discuter.spip.net. Désolé pour le dérangement !
Reply to this message
Bonjour,
Sur certains sites je vois un champ obligatoire dans la configuration des formulaire que je ne connais pas :
Dans la partie “Valeur unique d’un champ”
Vous pouvez choisir un champ dont la valeur sera unique parmi toutes les réponses : j’ai indiqué “aucun” :
Variable PHP (obligatoire) Nécessite une identification par PHP / Serveur non intégrée nativement dans SPIP.
Je ne sais pas quoi choisir.
Qu’est-ce qu’un “Serveur non intégrée nativement dans SPIP” ?
Et dans “Identification des réponses” j’ai :
Méthode d’identification : Par cookie (identifiant aléatoire, ne stocke aucune information personnelle)
Config :
Formidable 7.0.7
SPIP 4.4.3
merci
dd
C’est parce qur vous avez decoché la case permettant à une personne de répondre plusieurs fois au formulaire. en la recochant ces options ne devraient plus apparaitrent.
Bonjour,
La case permettant à une personne de répondre plusieurs fois était bien cochée.
Donc j’ai désactivé puis réactivé le plugin et c’est revenu dans l’ordre, (les champs indésirables obligatoires ne sont plus visibles).
Merci
dd
Reply to this message
Bonjour,
J’ai une page avec 3 formulaires quasi identiques (avec à chaque fois des inscriptions à un événement - ceci fonctionne bien merci pour ce plugin complémentaire à formidable !).
Mon souci : Un clic sur un label du second ou troisème formulaire ramène au champs du premier formulaire : les attributs “for” sur les labels fonctionnent mal.
Ici par exemple, j’ai le champs “input_1” dans chaque formulaire et je me retrouve avec 3 fois id=“champ_input_1”.
Ai-je la possibilité de choisir les nom des champs ?
Merci
Non ce serai trop compliqué à implementer (en tout cas à court terme).
Par contre on pourrait imaginer relativement facilement (je dis bien relativement) que les id sur tous les champs soit préfixés du hash generé automatiquement pour chaque formulaire.
Pourrais tu ouvrir un ticket au niveau du plugin saisies ? c’est là que cela se gère (car le problème se pose hors formulaire formidable)
ok, pour résoudre mon souci, j’ai donc créé 3 pages différentes pour les 3 formulaires.
Je vais faire le ticket sur saisie.
Merci Maïeul
Reply to this message
Problème de règle d’accessibilité des champs date de Formidable
Dans le cas d’un champ de formulaire de type “date” qui permet aussi de saisir aussi l’horaire, Formidable créé deux champs de formulaire ( date + horaire ) mais avec un seul libellé, malheureusement lié à aucun champ (à cause d’un
for=
générique). Formidable créé un code HTML du type (ici simplifié):Or les règles d’accessibilité qui permettent d’optimiser l’expérience des utilisateurs de technologies d’assistance, comme les lecteurs d’écran, préconisent que tout champ de formulaire
<input>
soit associé à un unique libellé<label>
. Par ailleurs, cela coute quelques points de pagespeed.voir Form elements must have labels
Sur mon site, j’ai en partie résolu le problème avec du javascript, mais cette soluce est loin d’être élégante.
Serait-il possible de conformer à l’avenir le formidable plugin Formidable avec cette règle d’accessibilité?
Par ailleurs, il existe pas mal de type de champ de formulaire lié aux dates:
<input type="date">
<input type="datetime-local">
<input type="month">
<input type="week">
<input type="time">
Or ces champs, comme le type
<input type="range">
ne semblent pas faire partie des choix possibles dans formidable. Ou bien ai-je raté quelquechose?bien Spipement,
Oui, cela fait partie des choses qu’on veut améliorer. Mais on n’a pas reussi à se mettred d’accord sur la manière dont doit se corréler le markup html et la vérification PHP...
Ok, message reçu. Et merci du retour.
Essentiellement, il faudrait que les
<input type="date">
ne soient pas du type<input type="texte">
comme c’est le cas actuellement...Je vais peaufiner mon javascript en attendant.
spipement,
Reply to this message
Bonjour,
J’essaie de faire un formulaire de contact qui permette de garder secrets les courriels des personnes de notre annuaire professeur (certains utilisent des adresses personnelles).
Les personnes inscrites n’ont pas toutes des comptes auteurs aussi ai-je enregistré les adresses de contact dans le champ “Description brève” de leurs fiches. L’idée est donc de transférer la valeur de cette Description brève dans un champ caché du formulaire et de l’utiliser comme adresse de destinataire.
J’ai intégré le formulaire dans le squelette des fiches de membres, avec l’appel
(j’ai mis PtoBR pour éviter le risque d’ajouts de balises HTML perturbatrices)
Sauf que je ne parviens pas ensuite à récupérer la valeur pour l’injecter correctement. J’ai même essayé en saisissant directement une adresse électronique lors de l’appel du formulaire. J’ai aussi essayé
Est-ce que cette manip n’est tout simplement pas faisable ? Ou, s’il faut manipuler un autre squelette, où puis-je le trouver ? Je n’ai pas réussi à trouver formulaire_contact dans les dossiers...
Merci de votre aide,
Alexis
Qu’entendez vous par “fiche” ?.
Par ailleurs je vous invite à relire la doc juste au dessus
1. Vous verrez que la première option d’appel au formulaire correspond aux valeurs par défaut des champs du formulaire. Or
a. Il n’y a pas de champ
courriel_cache
dans le formulaire (cf les noms de champs listé à droite lors de la config des traitements !)b. Quand bien même un tel champ existerait, votre appel revelerez publiquement les emails, en rajoutant leur nom dans le code html
2. Il existe la possibilité de passer un second tableau d’option, dont l’une des options est
traiter_email_destinataires
pour indiquer les destinataires lores du traitementemail
La fiche de membre est la rubrique qui lui est consacrée, avec un ou plusieurs articles de présentation. C’est dans le premier article, qui est obligatoire, que j’ai enregistré le courriel dans le champ “Description brève” (donc #DESCRIPTIF dans les boucles) afin de l’avoir en référence (parce que cet article, obligatoirement page d’accueil de la rubrique, n’a pas l’usage de DESCRIPTIF, me permettant d’en détourner l’usage).
Je n’ai pas bien saisi le comportement de “traiter_email_destinataires”, ce qui fait que je n’ai pas essayé de l’utiliser.
De ce que j’ai compris, il s’agirait donc d’intégrer
{traiter_email_destinataires, #DESCRIPTIF|PtoBR}
comme argument de l’appel du formulaire, mais ce que je ne parviens pas à trouver dans la documentation (ni dans l’interface d’édition du formulaire), c’est comment j’indique ensuite au formulaire de l’utiliser. Est-ce automatique et je cherchais comment l’intégrer pour rien ? Ou est-ce qu’il y a encore quelque chose qui m’échappe ?Bah dans formidable une fois qu’on a créé les champs d’un formulaire, on doit configurer des traitements. Parmis ceux-ci, il est possible de d’activer le traitement “Envoyer par email”. Si vous activez ce traitement, et bien ensuite tout les emails passé comme argument via
traiter_email_destinataires
seront ajoutés comme destinataires...Merci pour la confirmation.
En préparant ma réponse parce que ça ne marchait pas, j’ai constaté qu’un caractère vide était intégré dans mon code (le copier-coller affichait ceci :
ARRAY{-traiter_email_destinataires
, mais totalement invisible dans NotePad++), ce qui faisait bugger l’appel à cet argument.Maintenant que je l’ai retiré, ça marche en effet directement.
Merci beaucoup,
Alexis
Super. Pour l’avenir, peut tu utiliser la balise code ou les backsticks lors que tu cite du code ? cela évite de perdre les
}
et autres caractères spéciaux...J’essaierai d’y penser, oui. :-)
Reply to this message
Bonjour,
Je cherche à construire le tableaux de réponses à un formulaire.
Je suis en SPIP 4.4 et formidable 7.0.6.
Comme indiqué dans Complément sur Formidable, j’ai une boucle pour afficher les labels dans la ligne de tête :
Mais cette boucle ne me renvoie rien.
Si je mets #SAISIES dans la boucle, ça ne renvoie rien.
Quelle serait les bonnes balises pour afficher les labels ?
Merci.
La doc
complement sur formidable
n’a jamais vraiemnt été “approuvée” par les auteurs de formidable, Ce sont plus des essais fait par des gens et mis dans une doc pas forcément pensé de a à z.Il se trouve que depuis la rédaction de cette doc, formidable a modifié la manière de stocket en interne les saisies. Il faut remplacer
unserialize
parformidable_deserialize
et cela devrait marcher (/(sur ce point du moins).Merci Maïeul, ça fonctionne avec
formidable_deserialize
!Je dépose le code SPIP de mon tableau de résultats :
Reply to this message
Bonjour,
depuis la dernière màj de Formidable, les mails ne partent plus. J’ai systématiquement le message d’erreur du plugin.
Les mails partent bien à partir du test du Facteur (par SMTP, via un compte sur le domaine). Tout est à jour (Spip 4.4.2) et plugins.
J’ai ce problème chez Ionos et Infomaniak.
Je joins le yaml sur demande. Tout fonctionnait bien avant...
D’avance merci pour votre aide,
Rémy
Les plugins facteurs et le cas écheant mailshot sont-ils bien à jour ?
Bonjour,
Facteur 5.2.1 et Mailshot n’est pas installé.
Merci
Bon, je poursuis mes tests sur différents sites avec les mêmes versions de plugins. Certains sont sous Spip 4.3.8, d’autres en 4.4.2. Chez Hostinger, j’ai aussi le même souci : les mails ne partent pas. Les réponses s’enregistrent bien en base, Facteur fonctionne normalement. Les configurations sont identiques.
Hum. Donc oui c’est bon.
Je ne sais pas. Il faudrait que je puisse debuguer en live en disposant d’un accès au privé et des accès ssh... Chez moi ca marche TM.
Bonjour,
j’ai continué mes tests en comparant les réglages de chaque formulaire, quel que soit l’hébergeur. Je n’ai rien trouvé de ce côté. Les seules différences se situent au niveau du Facteur, avec plusieurs cas de figure (fonction mail php, smtp, Mailjet). Dans tous ces cas, les mails partent bien depuis le Facteur.
En installant Formidable (7.0.5) sur un site perso (4.4.2 / php 8.3) qui n’utilise pas le plugin, j’ai créé un formulaire et celui-ci fonctionne parfaitement (mail admin + internaute). C’est bien une nouvelle installation et non une màj.
J’ai donc fait le test suivant : exporter un yaml d’un formulaire, supprimer le formulaire, supprimer Formidable. Puis, j’ai réinstallé Formidable et importé le yaml. Malheureusement l’erreur est toujours présente. Sur ce même site, j’ai créé un nouveau formulaire : erreur également :-(
Je ne peux que constater que les versions après la 6.6.2 donnent tous la même erreur quand il y a eu màj.
Peut-on se caler pour essayer de résoudre le problème ?
Merci pour ton aide, parce que là j’ai les 2 pieds dedans...
Rémy
Essaie de me biper sur discord (dans l’idéal) ou à la rigueur IRC (mais je suis même réactif) dans la journée. On peut essayer de voir cela.
Merci pour ton temps. Je ne suis par sur Discord et je ne sais pas utiliser Irc...
Je serai plutôt dispo demain, si tu l’es également ?
Non je ne suis pas dispo demain, ni toutes les 2 prochaines semaines...
Ok, je peux être dispo maintenant pour maxi 30mn. Ok pour toi ?
Bah oui mais faut que tu me contacte...
Je t’envoie un mail, merci !
Eh bien, un GRAND MERCI à Maïeul pour avoir résolu le problème.
Il suffisait de décocher la case “Insérer l’adresse d’envoi dans le champ “From”” dans les traitements du formulaire pour que ça fonctionne.
J’ai testé sur plusieurs formulaires, avec des méthodes d’envoi différentes, chez plusieurs hébergeurs : c’était bien ça qui coinçait !
Si ça peut servir à d’autres :-)
Bon dimanche,
Rémy
Reply to this message
Add a comment
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Follow the comments:
|
