Table of contents
- Introduction
- Interface utilisateur
- Appeler mon formulaire
- Afficher les résultats du formulaire
- Pré-remplir dynamiquement les champs d’un formulaire
- Pré remplir les champs depuis une ancienne réponse
- Champs oui-non et case unique
- Courriels de notification
- Conservation des IP
- Envoi de fichiers
- Mise en forme des saisies
- Voir aussi sur le wiki
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
L’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}}
Pré remplir les champs depuis une ancienne réponse
Si les réponses sont enregistrées, on peut passer en troisième argument un identifiant de réponse.
- #FORMULAIRE_FORMIDABLE{contact,'',23}
pour modifier la réponse 23.
Champs oui-non et case unique
Pour rendre obligatoire la réponse “oui” à un champ de type oui-non ou 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 :
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.
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 par date d’activité
675 discussions
J’observe une différence entre les 2 versions
Formidable 3.42.5 - stable
et
Formidable 3.43.0 - stable
Avec la dernière version sur la page ?exec=formulaire_edit&id_formulaire=x&configurer=traitements
J’ai coché les 2 lignes “Envoyer par courriel” et “Enregistrer les résultats”
et aucune des sous-options configurable ne s’affiche (cf capture)
Les modifications entre ces 2 versions du plugins n’affectent pas cette partie du plugin. Est-ce que par hasard tout tes autres plugins sont à jour? vide peut etre le cache navigateur.
Alors, j’ai fait quelques tests sur plusieurs sites en local et en production. Résultat :
Saisies pour formulaires 3.28.7 - stable + Formidable 3.42.5 - stable OK
Saisies pour formulaires 3.28.9 - stable + Formidable 3.42.5 - stable pas OK
Saisies pour formulaires 3.28.9 - stable + Formidable 3.43.0 - stable pas OK
Si besoin d’autres tests, me faire signe !
Reply to this message
Bonjour,
J’ai essayé formidable en local, cela fonctionne parfaitement sans aucune manipulation de la base de données.
Par contre chez l’hebergeur 1and1 (orthophonistesdumonde.fr), lorsque je veux créer un formulaire ou l’importer, j’ai un message :
Erreur SQL 1146
Table ’db330805263.odm_formulaires’ doesn’t exist (voir le détail en pièce jointe)
spip en version 3.2.5, squelettes basés sur Ahuntsic.
Merci de votre écoute et de votre aide car je suis vraiment novice en programmation.
tout se passe comme si l’installation c’était mal déroulé. Je vous conseille donc de desinstaller (je dis bien désinstaller, pas juste désactiver) le plugin, puis le reinstaller.
Reply to this message
Bonsoir,
J’ai lu attentivement la documentation sur les fonctions CVT (charger(), verifier() et traiter()) afin de pouvoir surcharger celles de Formidable, mais j’ai du louper quelque chose car je n’y arrive pas complètement !
J’ai tenté de réécrire ces fonctions sans le _dist dans config/mes_options.php : cela semble fonctionner pour les deux dernières mais pas pour la première charger(). Si je cherche à surcharger cette première fonction même en recopiant simplement le contenu de la fonction _dist, le formulaire ne s’affiche plus en ligne !
Pourriez-vous me repréciser comment surcharger proprement ces fonctions formulaires_formidable_charger_dist(), formulaires_formidable_verifier_dist() et formulaires_formidable_traiter_dist() ?
De plus, autre problème : lorsque je teste le formulaire en ligne et que je ne renseigne pas les champs obligatoires, je suis surpris que la fonction formulaires_formidable_verifier_dist() ne retourne pas d’erreurs alors qu’un message d’erreur est bien affiché en ligne pour m’indiquer que les champs obligatoires n’ont pas été saisis. Pour des champs obligatoires non complétés, pouvez-vous m’indiquer comment le renvoi d’erreurs est géré ? Quelle fonction s’en occupe ? Comment récupérer ces erreurs ? J’aimerais récupérer ces erreurs dans cette fonction formulaires_formidable_verifier_dist() !
Merci d’avance pour votre aide.
PS : je suis sous SPIP 3.0.20 et j’ai mis à jour les dernières versions stables de Formidable (3.42.5), Saisies (3.28.6), YAML (1.5.4) et SPIP-bonux (3.5.4).
Si avant de faire une surcharge (qui est quand même un gros gros choc) tu expliquais ton besoin?
Bonsoir Maïeul,
Mon besoin concerne l’accessibilité : je souhaite après soumission d’un formulaire que le contenu de la balise
<title> ... </title>de la page contenant le formulaire s’actualise pour indiquer si la soumission du formulaire a réussi ou échoué.Ex :
ou
Avant de vous solliciter hier, j’ai cherché sur le forum du plugin et j’avais trouvé ce commentaire de 2017 fait par un autre utilisateur de SPIP. Il me semble que le besoin exprimé est le même que le mien. Cependant, je n’avais pas trouvé de réponse qui pouvait m’aider.
Avec une ancienne version du plugin Formidable (2.9.14 !), j’avais réussi à mettre ceci en œuvre en surchargeant les fonctions
formulaires_formidable_verifier()etformulaires_formidable_traiter()dans les fichiers/squelettes/formulaires/formidable.htmlet/squelettes/formulaires/formidable.php(ce qui n’est peut-être pas la bonne pratique !!!). Aujourd’hui, comme je souhaite faire une mise à jour du plugin Formidable dans sa dernière version (3.42.5 -> je sais que j’ai pris un peu de retard !!!), je suis en train de réétudier ceci pour ne pas perdre cette accessibilité. Or, en me basant sur la dernière version de Formidable, je n’arrive plus à refaire ce que j’avais fait à l’époque et qui fonctionnait !! Certaines surcharges de fichiers ne fonctionnent plus !En résumé ce que j’avais réussi à faire : j’avais rajouté un
<input type="hidden" name="form_erreur" value="" />dans le squelette de formidable et je testais dans les fonctionsverifier()ettraiter()si des erreurs étaient renvoyées. Si oui, je faisais dans ces fonctions unet j’avais un squelette inclus dans la balise
<title>de la page qui testait si cette valeur était transmise. Si oui, j’ajoutais le message adéquat en début de la balise<title>et j’arrivais ainsi à personnaliser cette balise<title>après chaque soumission du formulaire.J’espère avoir été clair dans mes explications. Merci d’avance pour tous les conseils que vous pourrez m’apporter.
Bonsoir Maïeul,
Mon besoin concerne l’accessibilité : je souhaite après soumission d’un formulaire que le contenu de la balise
<title> ... </title>de la page contenant le formulaire s’actualise pour indiquer si la soumission du formulaire a réussi ou échoué.Ex :
ou
Avant de vous solliciter hier, j’ai cherché sur le forum du plugin et j’avais trouvé ce commentaire de 2017 fait par un autre utilisateur de SPIP. Il me semble que le besoin exprimé est le même que le mien. Cependant, je n’avais pas trouvé de réponse qui pouvait m’aider.
Avec une ancienne version du plugin Formidable (2.9.14 !), j’avais réussi à mettre ceci en œuvre en surchargeant les fonctions
formulaires_formidable_verifier()etformulaires_formidable_traiter()dans les fichiers/squelettes/formulaires/formidable.htmlet/squelettes/formulaires/formidable.php(ce qui n’est peut-être pas la bonne pratique !!!). Aujourd’hui, comme je souhaite faire une mise à jour du plugin Formidable dans sa dernière version (3.42.5 -> je sais que j’ai pris un peu de retard !!!), je suis en train de réétudier ceci pour ne pas perdre cette accessibilité. Or, en me basant sur la dernière version de Formidable, je n’arrive plus à refaire ce que j’avais fait à l’époque et qui fonctionnait !! Certaines surcharges de fichiers ne fonctionnent plus !En résumé ce que j’avais réussi à faire : j’avais rajouté un
<input type="hidden" name="form_erreur" value="" />dans le squelette de formidable et je testais dans les fonctionsverifier()ettraiter()si des erreurs étaient renvoyées. Si oui, je faisais dans ces fonctions unet j’avais un squelette inclus dans la balise
<title>de la page qui testait si cette valeur était transmise. Si oui, j’ajoutais le message adéquat en début de la balise<title>et j’arrivais ainsi à personnaliser cette balise<title>après chaque soumission du formulaire.J’espère avoir été clair dans mes explications. Merci d’avance pour tous les conseils que vous pourrez m’apporter.
Surcharger des fonctions entières, c’est le mal, car quand elles évoluent (ou simplement même que des bugs sont corrigés) c’est toujours ton ancienne version qui est utilisée. Ça doit se faire que quand vraiment on peut pas faire autrement et notamment qu’il n’y a pas de pipelines.
Or là tu es dans un formulaire CVT, donc tu as des pipelines pour chacune des étapes (cf doc du noyau). Tu devrais donc pouvoir faire tous les ajouts que tu veux dans les pipelines “formulaire_charger”, “formulaire_verifier” et “formulaire_traiter”. En veillant à bien passer après Saisies qui y fait déjà des choses (notamment la déclaration des champs justement, ainsi que leur vérification comme tu le demandais).
Bonjour RastaPopoulos,
Merci pour vos conseils. Je suis d’accord, c’est en effet un peu compliqué de devoir réadapter des fonctions entières de plugin à chaque nouvelle mise à jour !
Je n’ai jamais utilisé les pipelines et je ne vois pas trop comment les utiliser malgré quelques lectures sur le sujet !
Quelles pages de la doc du noyau me conseillez-vous de lire ?
Dans quels fichiers se déclarent ces pipelines ? Avez-vous un exemple complet d’utilisation de pipeline CVT pour que je m’en inspire ?
Merci encore pour vos conseils précieux que je vais tenter de mettre en œuvre.
A noter qu’il y une discussion global sur ce sujet.
https://core.spip.net/issues/4111
pour un exemple de pipeline autour de charger/verifier/traiter
https://programmer.spip.net/formulaire_charger
https://programmer.spip.net/formulaire_verifier
https://programmer.spip.net/formulaire_traiter
et pour comment declarer un pipeline
https://programmer.spip.net/Qu-est-ce-qu-un-pipeline
et plutot que de modifier post directement je conseillerait d’utiliser set_request()
Bonjour ,
Dans le cadre d’un audit accessibilité j’avais surchargé le fichier head/artile.html en ajoutant
[(#ENV{saisie}) saisie formulaire - ]dans la balise titlej’avais créé une composition pour ne pas surcharger inutilement tous les articles
Dans le cas ou il y avait une erreur ça indique
L’expert accessibilité avait validé cette solution
Bonne journée
Reply to this message
Bonjour,
J’ai un comportement parfaitement incompréhensible sur un formulaire relativement vieux, et qui a subi beaucoup de modifs :
lorsque j’ai voulu le modifier, il m’affiche sur la barre de gauche tous mes champs @xx@, et pourtant certains champs ne s’affichent pas pour pouvoir les modifier. Plus fou, la disposition des champs n’est pas la même et semble remonter à des années... Sur le site public s’affichent pourtant bien tous les champs @xx@ comme voulu.
J’ai fait un update des plugins, puis on m’affiche “Il n’y a pour l’instant aucun champ dans ce formulaire”. Je recharge la page, et de nouveau mon formulaire s’affiche, mais toujours le même problème...
Help !
1) fait deja un export yaml, par précaution
2) aussi une sauvegarde
3) puis supprimme tous les fichiers sessions dans tmp. Ca peut être un souci de cache au niveau du constructeur de formulaire.
Bonjour Maïeul,
c’était cela, les fichiers Sessions à effacer,
Merci !
Reply to this message
Pas de multi-étapes en Spip 3.1 ?
Bonjour.
Je tente de faire un formulaire multi-étapes (où j’ai bien coché la case « Activer la gestion multi-étapes ») mais tous mes groupes de champs apparaissent en une page, comme un formulaire classique.
Configuration : Spip 3.1.11, Formidable 3.42.5, Saisies 3.28.6, PHP 5.3.3-7.
Or, si j’exporte en YAML et l’importe vers un Spip 3.2.5 (même serveur, même PHP, mêmes versions de Formidable et Saisies), ça fonctionne parfaitement.
Y aurait-il une incompatibilité avec la 3.1 ? (Ou y aurait-il un truc que j’ai loupé, quelques détails – comme certains plugins installés – étant différents entre les deux Spip ?)
Merci d’avance pour vos réponses !
1138.
J’avoue que je n’ai pas testé, et ça fait longtemps que je n’ai plus de 3.1. Mais pourtant, l’API multi-étapes a été intégré à SPIP en… 3.0 même, depuis 2012. Avant c’était en plugin en 2.1. Donc bizarre… Il n’y a aucune erreur PHP nulle part ? Si t’actives l’affichage des erreurs évidemment.
Et comment fait-on pour afficher les erreurs PHP ? En ajoutant ceci à config/mes_options.php
comme indiqué sur cette page ?
Mais, si j’ai bien compris, ça affiche les éventuelles erreurs sur les pages publiques. Or, ce site est en prod. :-/
(C’est ma 3.2 qui est en dev…)
N’y a-t-il pas moyen de limiter cet affichage d’erreurs à l’espace privé, où l’absence de multi-étapes est également présente ?
Ça c’est à toi de voir, soit t’as le même site en local ou sur une instance de dev, pour tester (ce qu’on devrait toujours avoir), soit tu l’actives en prod (mise à part cet endroit là, t’es pas censé avoir des erreurs ailleurs non ? donc ya rien de plus qui va s’afficher ailleurs en théorie)
(Mauvais timing : j’ai basculé récemment ma dev en 3.2…)
Bon, j’ai essayé en mettant les options ci-dessus dans mes_options.php et je n’obtiens aucune erreur.
(Pour être sûr, j’ai aussi testé de mettre
et j’obtiens bien deux erreurs de variables non définies, mais pour des plugins de Giseh.)
Je ne vois pas non plus d’erreurs dans la console.
Reply to this message
Bonjour,
L’export au format .xls ne peut être correctement ouvert avec Excel 2016 que si on commence par ouvrir Excel, puis qu’on ouvre le fichier et qu’on configure via les boites de dialogue qu’il y a une ligne de titre et que le séparateur est le “;” (un double clic sur le fichier l’ouvre en format bouillie).
Et le format CSV n’est ouvrable qu’avec Libre Office ou Open Office, en devant préciser UTF-8 dans la boite de dialogue.
J’aimerais pour Excel proposer d’utiliser cette lib : http://opensource.box.com/spout/
Je l’ai utilisée avec succès dans SoyezCréateurs.
Ce serait d’ailleurs l’occasion de mettre cette lib en plugin indépendant que Formidable et SoyezCréateurs nécessiteraient.
Qu’en dites-vous ?
Reply to this message
Bonjour,
Pour info, les champs “Date” pourraient se voir attribuer un placeholder, ce qui pourrait être bien utile notamment pour l’affichage sur mobile (où l’optimisation de l’espace est très important...)
Merci pour ce formidable plugin et à ses concepteurs !
Alors non, le placeholder ne DOIT SURTOUT PAS servir à remplacer le label d’un champ, jamais. Ça n’a aucun rapport en terme sémantique, le label c’est le nom du champ, à quoi il sert, tandis que l’attribut placeholder sert uniquement à donner un exemple de remplissage valide (par exemple “XX/XX/XXX” pour une date). Un champ doit absolument toujours avoir un label.
En revanche il y est bien dans la saisie “input” et devrait donc être aussi ajouté dans la saisie “date” (et couleur etc toutes les variantes input)
Merci RastaPopoulos pour ta réponse rapide,
Pour autant, si ton conseil est probablement judicieux, il n’est pas très sûr que tu m’aies convaincu. A moins que tu ne proposes une technique pour que le label apparaisse dans le champ de saisie, le placeholder m’apparaît comme une bonne technique pour minimiser la taille des formulaires, notamment pour les mobiles !
Je ne vois pas en quoi le placeholder est une solution, l’accessibilité n’est pas une option, pour aucun site. Donc non, jamais ô grand jamais, on ne doit utiliser le placeholder comme remplacement à un label, ça n’a strictement rien à voir.
Toi tu parles uniquement de style graphique, et éventuellement de comportement javascript (masquer ou déplacer). Donc ça se fait… en CSS et en JS.
Tu peux très bien t’amuser à positionner ton label à l’intérieur du champ, et à le déplacer en plus petit en haut quand tu cliques dessus (c’est ce que fait Google sur certains de ses forms je crois).
Par contre c’est très mal de le masquer entièrement quand on est focus dans le champ (ce qui est le cas pour le placeholder aussi), puisque ça signifie qu’une fois dedans… on ne sait plus à quoi sert le champ, ergonomie pourrie.
Exemple de tutoriel plus accessible (mais il y en a plein d’autres sur le net) :
https://itnext.io/how-to-build-a-floating-label-input-field-f9b21669fe2f
Reply to this message
Bonjour,
Petit problème lors du remplissage des champs dans formidable pour les websites multilingues. On peut mettre des chaînes de langue (du genre <:form_oulala:>) mais impossible manifestement de les afficher correctement si on y place des caractères devant ou après la chaîne (du genre <:form_oulala:> oh oui).
Est-ce un bug ?
Peut-on corriger ce problème car il est très pénalisant...
Merci
c’est un peu étrange de mettre du contenu avant ou après, puisque ce serait un contenu invariant selon la langue, alors quela chaine de langue est prévu pour le multiling...
Salut Maïeul,
alors là, pas d’accord ;-) le comportement actuel n’est pas appréciable, car on peut vraiment avoir besoin de placer une chaîne de caractère (multilingue) et des paramètres fixes. Ex : liste déroulante -> type : 12h30|<:reservation:> 12h30
la version 3.27.2 du plugins saisies corrige cela sur un certain nombre de paramètres des saisies. S’il y en a qui sont encore “bugé”, le signaler.
Ton explicatio initial était pas clair. J’imaginais que tu pensais aux label, et autres.
Mais bref. Globalement : faut appliquer un filtre au bon endroit dans chaque squelette de saisie.
correction c’est la version 3.27.3 qui résoud le problème.
oui, c’est parfait, les chaînes de langue sont reconnues dans les champs, et s’affichent maintenant tout comme il faut, merci bien !!!
hum. en fait j’ai pas forcément corrigé de la bonne manière.
peux tu m’envoyer un export .yaml du formulaire qui marchait pas avant, pour que je comprenne. On va sans doute revenir là dessus en terme d’implementation.
Reply to this message
Bonjour,
Les formulaires semblent ne pas tenir compte du plugin Timezone. Quelle pratique utiliser pour associer ce paramètre de fuseau horaire au formulaire ?
En vous remerciant
Bonjour,
Peut être https://www.spippourlesnuls.fr/developper/dates-et-gestion-d-agendas,60/date-et-timezone,664.html
Cordialement.
@beno qu’entend tu par “Tenir compte”. Je vois pas où un formulaire serait concerné par le timezone...
Bonjour Maïeul,
Il peut être utile de proposer un décompte horaire à partir du résultat d’un formulaire (prise de RDV par exemple, ou horaire d’exposition pour un show, dans le cas présent).
Merci Pierre,
J’ai essayé cette méthode, mais elle ne fonctionne pas sur le site sur lequel j’ai essayé de mettre ça en place (voir https://cutt.ly/6wStiO8 , le décompte est calé sur l’Europe, et non le Laos, c’est ballot...)
Il me faudrait un exmeple concret de formulaire formidable faisant ce décompte horaire pour comprendre.
Bonjour Maïeul,
le formulaire a un champs #EVENT_OPEN. qui renseigne sur l’horaire d’un événement. Là dessus, j’ai un compteur qui affiche le temps restant.
A la base, je cherche à utiliser
data-end="[(#EVENT_OPEN|affdate{'Y/m/d H:i:00'})]en tenant compte du décalage horaire (plus 5 heures au Laos, voir la page mentionnée dans mon précédent message), ou bien (plus simple) de retirer les 5 heures à mon #EVENT_OPEN... une idée pour faire cela ?heu... tu est sur que c’est un formulaire formdiable ca :-). C’est pas un bete formulaire cvt ?
Bref, envoi moi le code de ton formulaire, j’y comprendrais mieux.
Et oui, tu as vu juste, pour l’instant c’est un champ extra rempli à partir d’un article, mais je cherche (développement local pour l’instant) à ce que cette fonctionnalité soit proposée par un formulaire via formidable...
en tous cas le problème est pas lié à formidable.
Mais grosso modo, il faudrait utiliser les fonctions de dates et heures de php, qui permettent d’additittoner/soustraire.
Merci Maïeul,
je pensais que cela serait plus facile, mais je me rends compte à quel point ça va être plus compliqué que je ne le pensais... je verrai pour mettre en ligne cette option de formulaire plus tard ;-) Merci encore pour ton aide !
Reply to this message
Je viens ici poster un message qui concerne la partie paiement du formulaire et accessible ici
Le mapping des champs nom/prénom/adresse en bas de page de configuration des traitements ne fonctionne pas.
inutile de poster à 36 endroits....
100% d’accord. Cependant mon précédent post sur le bon forum n’a jamais eu de réponse depuis plusieurs jours et surtout en sachant que la deadline est dans 7 jours
Reply to this message
Comment on this article
Follow the comments:
|
