Table of contents
Une fois le formulaire et les champs créés formidable propose de “configurer les traitements”. Cet article vise à préciser ou compléter quand ça semble nécessaire certains choix présents.
Les fonctions listées sont valable avec la version 4.4.0 du plugin.
Le premier choix consiste à savoir si on veut :
- “Enregistrer les résultats du formulaire dans la base de données”
- “Poster par courriel le résultat du formulaire à une liste de destinataires”,
- Les choix ne sont pas exclusifs.
Enregistrer les résultats du formulaire dans la base de données
Une fois cette case cochée, un certain nombre d’options s’affichent. Il est notamment possible de rendre les réponses au formulaire :
- Multiples : une même personne peut répondre plusieurs fois.
- Modifiables : les visiteurs peuvent modifier leurs réponses après coup.
Méthode d’identification
Dans le cas ou votre formulaire comprend des réponses modifiables ou uniques, un encart apparaîtra afin de définir une méthode d’identification des réponses :
- Soit par cookie. L’identification dépendra du navigateur sur lequel l’utilisateur rempli le formulaire. Si celui-ci n’autorise pas les cookies, l’identifiant de la personne authentifiée et la méthode d’identification par variable de connexion PHP seront utilisées à la place de cette méthode.
- Soit par identifiant de la personne identifiée. Utile pour les formulaires nécessitant la création d’un compte à priori. Si l’utilisateur n’est pas connecté, la méthode d’identification par cookie sera utilisée à la place de cette méthode, ou a défaut la variable de connexion PHP (sauf en cas d’anonymisation des identifiants).
- Soit par identifiant de la réponse passée explicitement lors de l’appel au formulaire dans un squelette. Cette méthode permet de forcer l’affichage d’une réponse particulière.
- Soit par variable de connexion PHP. L’identification dépendra d’une variable d’environnement fournie par l’utilisateur. Si celle-ci n’existe pas, l’identifiant de la personne authentifiée et l’identification par cookies seront utilisées à la place de cette méthode.
Protection des données personnelles
Il est également possible de paramétrer la protection des données personnelles des utilisateurs :
- En ne conservant pas l’identifiant de la personne connectée. Si la méthode d’identification est justement cet identifiant, celui-ci sera d’abord crypté avant d’être stocké en base).
- En demandant l’effacement des résultats les plus anciens de la table. Une fois la case cochée, il sera possible de définir le nombre de jours pendant lesquels on garde l’enregistrement avant d’effacer.
- En choisissant d’enregistrer ou non les IPs des utilisateurs. Ces IP seront hashés après un délai de garde.
Autres options disponibles
Elles concernent :
- La modération de l’enregistrement :
- à priori, les réponses sont modérées automatiquement, sauf pour les administrateur·trice·s (mais on peut ajouter une option pour modérer aussi pour ces personnes);
- à posteriori, les réponses sont à modérer manuellement.
- L’exclusion des champs de l’analyse des résultats proposée par formidable.
- Le rafraîchissement du cache à chaque enregistrement de réponses. Utile si les réponses sont publiques ou si on veut afficher publiquement le nombre de réponses.
Poster par courriel le résultat du formulaire à une liste de destinataires.
Une fois coché ce choix une série de champs est proposée, répartis en cinq groupes :
Destinataires du courriel
- Sujet du courriel
- Contenu du courriel
- Destinataires du courriel
- Expéditeur du courriel
- Accusé de réception
Sujet du courriel
Il est possible de personnaliser le Sujet du courriel avec les @raccourcis@ (sinon il sera construit automatiquement) et de choisir de n’y mettre que des Valeurs brutes si le mail doit être traité par un robot et non un humain.
Contenu du courriel
Possibilités de personnalisation:
- *Champs à exclure du contenu du message;
- * Faut-il “Joindre les fichiers dans le courriel”,
- * “Masquer les liens d’administration dans le courriel”
- * “Envoyer l’adresse IP de l’envoyeur aux destinataires”
- * Masquer les champs vide
Concernant les Champs à exclure du contenu du message, comme indiqué dans le placeholder les champs doivent être exclus sous la forme “input_3,selection_2”
Depuis la révision 110166 il est possible d’exclure les champs sous la forme @raccourcis@
Destinataires du courriel
Trois choix possibles : Destinataires, Destinataires supplémentaires, Destinataires en fonction d’un champ.
Le premier choix Destinataires ne pourra comprendre que des champs de type “hidden” ou “destinataires”. Le type de champ Destinataires permet de choisir parmi une liste de rédacteurs du site quels seront ceux qui sont informés du remplissage du formulaire.
Le champ Destinataires supplémentaires permet, comme son nom l’indique, d’envoyer un formulaire à un ou plusieurs destinataires en fournissant des adresses directement dans le champ.
Enfin, Destinataires en fonction d’un champ permet d’envoyer le formulaire à des interlocuteurs différents en fonction des choix. Attention toutefois pour que ça fonctionne bien il faut que soit proposé un mail pour chaque choix, ou, s’il y a des choix non définis ici, qu’un destinataire soit défini par ailleurs.
Expéditeur du courriel
Trois champs possibles Courriel de l’envoyeur, faut-il “Insérer le courriel de l’envoyeur dans le champ “From”” et le Nom de l’envoyeur
Courriel de l’envoyeur : ne pas oublier de renseigner ce champ si on utilise le message de confirmation ou accusé de réception
Accusé de réception
L’accusé de réception ne peut être demandé que si le courriel de l’envoyeur est préalablement renseigné. Alors il devient possible de cocher Envoyer aussi un courriel à l’adresse de l’envoyeur avec un message de confirmation.
Il est ensuite possible de définir le Sujet de l’accusé de réception, de préciser un Courriel de l’accusé de réception et de forcer un Nom de l’expéditeur de l’accusé de réception
Discussions par date d’activité
16 discussions
Bonjour,
Je débute avec ce plugin déjà bien sophistiqué. Mais, je n’ai pas trouvé dans la doc si le formulaire formidable
a ou non un mécanisme pour confirmer l’adresse du visiteur. Un peu comme pour l’inscription Spip.
Le mail de confirmation vers le mail du visiteur aurait un lien qui s’il est cliqué va valider alors l’insertion en bdd.
Ceci permet d’éviter l’accumulation de fausses adresses e-mail en bdd.
Est-ce déjà fait, ou est-ce faisable avec un peu de code ?
Merci
Non cela n’existe pas encore. C’est sans doute faisable avec un bout de code oui (tout est faisable avec des bouts de code, puisque c’est du logiciel libre). Le tout est d’avoir le temps de l’écrire ce bout de code, et de l’écrire proprement.
Merci beaucoup Maïeul,
Je ne suggérais en aucun cas qu’on le code pour moi :-)
Peut-être un champ extra à valider par une action avec un hash,
ou le champ statut de la table spip_formulaires_reponses
à mettre d’abord à non-verifié
puis à publier après clic sur le lien .
Je vais voir .
Jack
Dans tout les cas, fait un PR.
Je pense qu’un statut à part plutot que “proposé” serait mieux. Je crois que pour les auteurs c’est comme cela que ca marche, à moins que ce soit pour les petititions.
J’ai cru voir que formidable peut être associé à mailsubscribers qui a l’option double opt in.
Donc crée des listes épurées
Mais, ça oblige peut-être à utiliser mailshot. J’aimerais éviter et utiliser le mail de base.
Je ne vais pas faire de mailing newsletters.
Reply to this message
Bonjour, actuellement je voudrais traiter un formulaire différemment selon la réponse à un champ (oui/non, radio, ou etc...). Pour l’instant mon formulaire envoie par mail le contenu du formulaire , mais j’aimerais que les formulaires avec une certaine réponse à un champ ne soient pas traités.
est-ce que c’est aisément possible en faisant cela dans l’espace privé ? Si oui comment ?
Je vous remercie d’avance,
Je commente pour rafraichir la demande. Je serais très intéressé aussi par une possibilité de ce type. La RGPD nous impose une validation avant Validation des formulaires de contact et donc un traitement selon une case à cocher. En l’état on ne peut plus utiliser ’Formidale’ c’est bien dommage.
@Olivier si on peut très bien faire du Formidable conforme RGPD
La RGPD demande pas une case à cocher, elle demande un consentement explicite des gens sur le traitement des données. La case à cocher n’est qu’une manière de s’assurer du consentement. Mais ce qui compte pour la conformité c’est surtout l’explication sur ce que sera fait des données.
Tu met une case à cocher obligatoire autorisant le traitement des données, en expliquant par un champ de type “commentaire” ce qu’il en est. Si les gens cochent pas la case à cocher, bah il y a un message d’erreur, et rien n’est envoyé. Comme cela tu sais que le consentement est explicite.
Quel sens aurait-il du reste à envoyer un formulaire qui ne ferait aucun traitement ?
@Creirwy faudrait préciser ton besoin, mais les interfaces de config des traitements sont deja bien chargé...
Reply to this message
Bonjour,
Merci pour ce plugin qui m’a fait gagner du temps pour la conception d’un formulaire mais, j’en perds maintenant parce que les champs date et heure (arrivée et départ) s’affichent normalement en format français dans l’espace privé mais en format anglais dans l’espace public. Par ailleurs le si second accepte la saisie d’une heure mais il ne propose pas la liste déroulante des heures.
J’ai supprimé les champs date, puis recréé les champs date sans succès.
Le code source de la page de l’espace privé comporte les noms des jours et des mois en français
Le site n’est pas multilingue
Le reste du site fonctionne normalement.
Rien trouvé sur le net, ni sur la doc de Formidable.
Une idée où chercher encore ?
Merci
William
Le probleme venait de fichiers javascript (date_picker et time_picker) installés par dessus les javascript de SPIP par une template.
Suppression des fichiers , et tout va bien depuis
Reply to this message
Bonjour, depuis la dernière mise à jour du plugin, impossible d’afficher la page
ecrire/?exec=formulaire_edit&id_formulaire=12&configurer=traitements
Spip 3.2.7, avec les plugins suivants, installés et actifs :
Agenda 3.39.4, API de vérification 1.9.7, Big Upload 1.0.4, Centre image 0.10.7, Changement de langue 0.3.5, Citations bien balisées 0.1.6, Corbeille 3.1.2, Crayons 2.0.9, Enluminures typographiques 3.6.0, Facteur 3.7.2, Favicon 1.1.2, Formidable 4.4.6, Fulltext 1.2.0, Insérer Modèles 1.3.6, Le Couteau Suisse 1.10.19, Makicatta 0.3.1, Mini Calendrier 2.4.1, NoSPAM 2.1.6
Ortho-Typographie 1.5.1, Porte Plume Partout 1.0.11, Saisies pour formulaires 4.0.0, SCSS PHP 2.4.2, SkelEditor 2.7.11, Social tags 1.2.1, SPIP Bonux 3.5.4, SPIP Mentions Légales 1.70.5, Tiny Typo 2.1.1, YAML 1.5.4, Z-core 2.8.7
J’ai essayé de désactiver les plugins un par en me disant qu’il y avait peut-être un conflit, mais rien n’y a fait. En revanche, les pages “configurer le formulaire” et “configurer les champs” s’affichent normalement. Mon formulaire “12” est basé sur le formulaire “10” que j’ai légèrement modifié après l’avoir dupliqué. Je n’arrive plus non plus à configurer les traitements de mon formulaire initial depuis que le plugin a été mis à jour.
Quelqu’un saurait ce qui coince ?
Binjour,
vous avez fait quand la mise à jour? Vous avez la version “fantome” de saisie pour formulaire. La v 4.0.0 n’existe pas et n’a été diffusé que par erreur. C’est en fait une vieille version, et ca explique le plantage.
Donc
1. Desinstaller saisies pour formulaire v4.0.0
2. Aller dans gestion des plugins > depot : effacer et recreer le depot
3. Reinstaller saisies pour formulaire (3. quelque chose)
et ca devrait rouler.
Effectivement, c’était bien ça le problème. Il faut d’abord désinstaller “formidable” et “saisies” v. 4.0 puis installer “saisies pour formulaires” 3.38 tout seul... et seulement ensuite réinstaller “formidable”, sinon l’installation de “formidable” embarque avec elle “saisies pour formulaires” v. 4.0. et le serpent se mord la queue. Mais tout fonctionne parfaitement désormais, merci beaucoup !
Vous ne m’avez pas dit quand vous aviez fait la mise à jour. C’est important pour moi de savoir, pour comprendre ce qu’il en est de l’origine de cette version fantome chez vous.
Par ailleurs avez vous bien installé/désinstallé le flux de plugin?
Enfin, ii vous faudrait effacer saisie v4.0.0 (dans plugins/auto/saisies) pour s’assurer qu’il reviendra pas sur le devant de la scène,
Bonsoir, je ne saurais pas dire exactement quand j’ai fait la mise à jour, désolé d’être aussi imprécis, mais il me semble que ça ne fait pas très longtemps. Mon formulaire “10” datait de décembre 2019, je l’ai testé et tout allait très bien, j’ai reçu des réponses jusqu’à fin février. Quand j’ai fait le formulaire “12” cette semaine, ça ne fonctionnait plus, et c’est là que j’ai réalisé qu’il y avait un problème, y compris avec les anciens formulaires. J’ai bien mis à jour les dépôts, en les désinstallant et en les réinstallant, comme vous me l’avez conseillé. J’ai deux dépôts actifs : le dépôt “principal”, et le dépôt “external” (nécessaire pour utiliser l’interface de l’espace privé “Makicatta” que j’aime beaucoup).
Je ne le fais plus désormais, mais il m’arrivait de mettre à jour les plugins non pas depuis “gestion des plugins” mais depuis le couteau suisse (“mises à jour automatiques”), c’est peut-être de là que venait le problème, je ne sais pas.
Enfin, ce soir, “gestion des plugins” me proposait la mise à jour de “saisies”... J’ai eu peur que cela charge la fameuse version 4.0 mais j’ai quand même tenté. Tout s’est bien passé : c’est la version 3.38.2 qui s’est installée.
Merci encore pour votre aide.
Reply to this message
Bonsoir, j’ai installé le plugin Formidable en lieu et place du plugin Forms and table sur un site sous spip 3.2.7. Je constate que lorsque j’installe le plugin, une page s’affiche avec la mention “MAJ init” et la page des plugins ne s’affiche plus. Avez-vous une idée pour régler cela ? Merci
Reply to this message
Bonjour
J’ai crée un formulaire en français et un formulaire en anglais, à l’identique
J’ai ensuite insérer “formulaire|formidable|id=formcontact1” et “formulaire|formidable|id=formcontact2>”dans 2 articles
Sans doute pas le plus rapide mais je débute....
j’ai crée un squelette “contact” et une boucle sur ces 2 articles avec lang
Cela fonctionne
Par contre lorsque je fais un test le formulaire en français fonctionne mais celui en anglais renvoie l’erreur “There are errors in the fields below, please check your inputs”
J’ai tout vérifier et ils sont identiques dans les champs et dans les traitements
Je suis un peu perdue
Merci de votre aide
tu a les 2 formulaires qui s’affichent en même temps ? cela peut être la cause du problème. Est-ce que deja lorsque tu teste les formulaires, seuls, depuis l’espace privé ca marche?
Je me suis mal exprimée je crois
Dans la version française j’ai bien le formulaire français qui fonctionne et dans la version anglaise le formulaire en anglais s’affiche bien mais renvoie l’erreur après validation
certes, mais est-ce que les articles sont affichés ou pas en même temps?
Quid si tu essaie de soumettre le formulaire directement depuis l’espace privé.
non ils ne s’affichent pas en même temps
Cela dépend de la langue choisie sur le site
Ma boucle est
et j’ai créé un formulaire par article avec un nom différent
C’est peut-être plus parlant
Je n’ai pas su intégrer directement dans mon squelette le choix des langues avec
bon, bah vous avez répondu à une de mes questions. La seconde est : est-ce que le formulaire marche directement dans l’espace privé?
je viens de tester et non il ne fonctionne pas non plus
donc le problème se situe bien au niveau du formulaire. pouvez vous me l’envoyer en .yaml ?
Oui bien sur
id_formulaire: ’3’
identifiant: formcontact2
titre: ’Formulaire de contact’
descriptif: ’’
css: ’’
message_retour: “Thank you, your message has been sent.\r\nDross engineering’s team”
saisies:
-
options: label: Society, type: text, size: ’40’, autocomplete: defaut, nom: input_1
identifiant: ’@5d4d616c6456c’
verifier:
saisie: input
-
options: label: ’Last Name’, type: text, size: ’40’, autocomplete: defaut, nom: input_6
identifiant: ’@5d5fcbba5f854’
verifier:
saisie: input
-
options: label: ’First Name’, type: text, size: ’40’, autocomplete: defaut, nom: input_5
identifiant: ’@5d5fcbb3b8a05’
verifier:
saisie: input
-
options: label: Address, type: text, size: ’40’, autocomplete: defaut, nom: input_4
identifiant: ’@5d5fcbb215b01’
verifier:
saisie: input
-
options: label: City, type: text, size: ’40’, autocomplete: defaut, nom: input_7
identifiant: ’@5d5fcbc881bf4’
verifier:
saisie: input
-
options: label: Country, type: text, size: ’40’, autocomplete: defaut, nom: input_3
identifiant: ’@5d5fcbaa26cdc’
verifier:
saisie: input
-
options: label: ’Phone number’, type: text, size: ’40’, autocomplete: defaut, nom: input_2
identifiant: ’@5d5fcb9cb1ff0’
verifier:
saisie: input
-
options: label: ’email address’, type: text, size: ’40’, autocomplete: defaut, nom: email_1
identifiant: ’@5d5fcbd1e0743’
verifier:
saisie: email
-
options: label: Subject, type: text, size: ’40’, autocomplete: defaut, nom: input_8
identifiant: ’@5d5fcbd50f293’
verifier:
saisie: input
-
options: label: ’Text of your message’, rows: ’5’, cols: ’40’, nom: textarea_1
identifiant: ’@5d5fcbdcdb1ee’
verifier:
saisie: textarea
-
options: datas: “By checking this box, I agree that the information entered will be stored and used in the context of the business relationship that may result.\r\n”, choix_alternatif_label: ’Autre choix’, obligatoire: on, nom: checkbox_1
identifiant: ’@5d5fd1d6dd3f5’
verifier:
saisie: checkbox
-
options: texte: ’By submitting this form, I agree that the data entered will be used by Dross Engineering to respond to my request for information on Dross Engineering products and / or services.’, nom: explication_1
identifiant: ’@5d5fd33d79be1’
verifier:
saisie: explication
traitements:
email:
champ_sujet: ’’
champ_sujet_valeurs_brutes: ’’
exclure_champs_email: ’’
pj: ’’
masquer_liens: ’’
activer_ip: ’’
masquer_champs_vides: ’’
destinataires_plus: bcollet@dross-engineering.com
destinataires_selon_champ: ’’
champ_courriel_destinataire_form: ’’
champ_courriel: ’’
activer_vrai_envoyeur: on
champ_nom: ’@FORMULAIRE@’
activer_accuse: ’’
sujet_accuse: ’’
texte_accuse: ’’
masquer_valeurs_accuse: ’’
courriel_envoyeur_accuse: ’’
nom_envoyeur_accuse: ’’
public: non
apres: rien
url_redirect: ’’
statut: publie
date_creation: ’2019-08-14 21:36:28’
maj: ’2019-09-02 10:46:51’
composition: ’’
composition_lock: ’0’
Bonjour
J’ai testé le formulaire en effaçant un par un les champs
et il a fonctionné lorsque j’ai effacé le champ case à cocher et explication
J’ai ensuite recréé ces champs et il fonctionne
Je ne comprends bien pourquoi mais il fonctionne c’est le principal
Merci pour vos réponses
Bonne journée
Reply to this message
Bonjour,
J’ai fait un formulaire dans lequel j’ai un champ “destinataire” de type adresse email.
Le raccourci est @email_1@
Je voudais que l’email saisi dans le champ “destinataire” soit destinataire du mail de traitement.
Dans la partie “Configurer les traitements”, au niveau de “Destinataire”, je ne comprends pas où je peux insérer le raccourci @email_1@
Merci
Ce n’est volontairement pas possible. En effet, cela reviendrait à permettre à n’importe qui d’envoyer des emails à n’importe qui depuis votre site, et donc à en faire un vecteur de spam.
En revanche, ce qu’il est possible de faire c’est de prévoir un destinataire que vous connaissez deja, envoyé par l’email @email_1@, et d’envoyer un accusé de réception à l’expediteur de ce mail.
Bonjour,
Merci beaucoup pour votre réponse
Reply to this message
Bonjour,
Dans un formulaire, sur l’écran des traitements, dans la zone “Expéditeur du courriel”, liste déroulante “Courriel de l’envoyeur”, je n’ai pas le champ email existant dans mon formulaire ce qui fait que je ne peux pas choisir d’envoyeur et consécutivement pas d’accusé de réception.
Dans ce menu déroulant c’est un peu bizarre, j’ai 2 ligne blanches (non consécutives), et 2 lignes dont les titres correspondent aux 2 fieldset que j’ai dans le formulaire et c’est tout, aucun autre champ possible, c’est comme si cela ne ramenait pas la liste des champs.
En dehors de ça le formulaire (un peu compliqué) fonctionne, ça stocke bien en base, ça envoie bien l’email à une adresse désignée, mais jute impossible de faire cet accusé de réception ... c’est tout à jour 3.2.4, plugins à jour ...
Un second formulaire dans le même site a le même souci sauf que là j’ai bien le bon nombre de lignes d’options blanches et que avec un “examiner element” j’arrive à retrouver le champ email (value de l’option).
Une idée de ce qui pourrait causer ce phénomène ?
Merci par avance !
Pierre
Non, aiucune idée comme cela. Il faudrait m’envoyer par mail (monprenom@monprenom.net) un export yaml du formulaire qui pose problème...
Bonjour,
Ok je vous envoie ça ! J’ai continué à réfléchir, une piste que je subodore (par comparaison avec les autres formulaires nombreux que j’ai cité), ce site utilise le sélecteur d’événements qui vient avec Agenda ...
Pierre.
Ok, j’ai pu regarder rapidement.
VOus avieu deux groupes de champs
- “Toutes les formations Zedd”
- “Merci de remplir le formulaire (champs * obligatoires)”
Mais le second était une sous entrée du premier, au lieu de le suivre. Ce n’est sans doute pas ce que vous souhaitez, ce n’est pas bon en terme d’accessibilité d’avoir des fieldsest imbriqués, et pour implémenter cela au niveau du selecteur de champ, ce serait galère pour un interet limité.
Donc je vous propose de corriger cela. Editer le second groupe de champ, et modifier “position du champ”.
Par ailleurs, votre selecteur d’evenement devrait avoir un label (en terme d’accessibilité). Si vous n’avez qu’un champ dans un groupe de champ, alors autant supprimer ce groupe de champs.
Bonjour,
Ok je comprends (ça n’est pas moi qui ait créé le formulaire), donc la mauvaise imbrication des fieldset empêchait la création d’une liste cohérente de champs dans l’écran des traitements, ok assez logique. C’est vrai que les manips sur ces fieldset en glissé-déposé sont souvent un peu difficiles, on ne pense pas assez à utiliser “Position du champ”.
Pour le fieldset qui contient le sélecteur d’évènement, oui il n’y a qu’un seul champ à la construction du formulaire (le sélecteur d’évènement) par contre cela génère un paquet d’input checkbox sur le site public donc je préfère que ça soit regroupé dans un fieldset pour des raisons de css (en flex), ça me permet de présenter le formulaire en 2 colonnes.
Oui pour le label, on se contente du label du fieldset et on a ensuite des labels pour chaque input checkbox.
En tous cas grand merci pour avoir pris le temps de regarder, c’est cool !
Pierre.
Reply to this message
Limiter le nombre de réponses totales
Bonjour et tout d’abord grand merci pour ce formidable outil.
Je me posais la question de savoir s’il y avait moyen de fixer un nombre maximal de réponses pour un formulaire donné ? L’idée serait d’utiliser formidable pour simuler un système de réservation à une réunion où il y aurait par exemple une jauge d’accès de 20 places...
Et que ce passe-t-il si le total est atteint?
parce qu’il y a plusieurs manière de faire, Une solution simple serairt de mettre dans un modèle l’appel au formulaire, en affichant le formulaire en fonction du nombre total de réponse deja enregistré,
Merci Maïeul de ta réponse si rapide.
J’avais en tête ce contournement que je vais mettre en oeuvre.
En fait, ma question est venue en regardant ce qui existait comme solution SPIP et hors-SPIP. J’ai été regarder du côté de framaforms qui propose des formulaires vraiment très semblables à ceux de formidable et qui comportent un panneau de configuration proposant une limitation de soumissions. Du coup, comme je trouve les deux outils très voisins, je me demandais s’il y avait qqpart dans formidable un tiroir caché (hi, hi, hi) qui m’aurait échappé.
Merci encore
le problème c’est que le traitement “enregistré” est une possible parmi d’autres. Donc je serais réticent à mettre cela directement dans formidable.
Pour les cas où tu veux le même formulaire pour plusieurs occurences d’un même evenemnets, tu peux utiliser https://contrib.spip.net/Choix-d-evenements + https://contrib.spip.net/Formulaire-de-participation-a-un-evenement-avec
Reply to this message
J’ai créé un formulaire avec plusieurs cases à cocher. Est-il possible, avec FORMIDABLE que les mots cochés soient envoyés au groupe de mots-clés X et que ceux-ci deviennent des mots-clés?
Si OUI comment?
Bonjour,
formidable est conçu principalement pour des formulaires de contact. Cette fonctionnalité n’existe pas dans formidable. Il serait éventuellement possible de dévelloper un plugin pour faire cela, mais il faut des connaissances PHP.
Reply to this message
Ajouter un commentaire
Follow the comments:
|
