Formidable, le générateur de formulaires

Un générateur de formulaires facilement configurable pour les non-informaticiens et facilement extensible pour les développeur⋅euses.

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 :

  1. #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 :

  1. #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.

  1. #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 destinataires
formulaire_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 :

  1. 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.

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)

updated on 2 October 2019

Discussion

674 discussions

  • 1

    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

  • 7

    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 :

      1. <title>[Envoi effectué] - Que pensez-vous du service de paiement en ligne ? </title>

      ou

      1. <title>[Erreur(s) à corriger - envoi impossible] - Que pensez-vous du service de paiement en ligne ? </title>

      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() et formulaires_formidable_traiter() dans les fichiers /squelettes/formulaires/formidable.html et /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 fonctions verifier() et traiter() si des erreurs étaient renvoyées. Si oui, je faisais dans ces fonctions un

      $_POST[’form_erreur’] = ’yes’

      et 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 :

      1. <title>[Envoi effectué] - Que pensez-vous du service de paiement en ligne ? </title>

      ou

      1. <title>[Erreur(s) à corriger - envoi impossible] - Que pensez-vous du service de paiement en ligne ? </title>

      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() et formulaires_formidable_traiter() dans les fichiers /squelettes/formulaires/formidable.html et /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 fonctions verifier() et traiter() si des erreurs étaient renvoyées. Si oui, je faisais dans ces fonctions un

      $_POST[’form_erreur’] = ’yes’

      et 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 title

      j’avais créé une composition pour ne pas surcharger inutilement tous les articles

      Dans le cas ou il y avait une erreur ça indique

      1. <title>erreur saisie formulaire - Contact - nom du site  </title>

      L’expert accessibilité avait validé cette solution

      Bonne journée

    Reply to this message

  • 2

    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

  • 4

    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

      error_reporting(E_ALL^E_NOTICE);
      ini_set ("display_errors", "On");

      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

      1. define('SPIP_ERREUR_REPORT',E_ALL);

      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

  • 3

    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

  • 7

    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

  • 9

    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

    • @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

  • 2

    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

  • 17

    Sur un site en 2 langues je n’arrive pas à faire afficher le texte du bouton de validation d’un formulaire :
    Si je mets <multi>[fr]Envoyer[en]Submit</multi> dans la config des options globales il m’affiche
    <multi>[fr]Envoyer[en]Submit</multi> texto sur le site public

    Pour les autres champs du formulaire j’ai bien le bon texte de langue qui s’affiche.

    • La version 3.37.8 corrige cela.

    • Merci. Est-ce voulu si le texte du bouton de validation par défaut est “Enregistrer” et non plus “Envoyer” ?

    • C’était “valider” avant et pas “envoyer”. C’est le passage en multi etape/la réécriture du code pour les options globales qui a provoqué ce chagement de chaîne de langue. Je ne sais pas si c’est volontaire ou pas, mais je trouve ca pas plus mal, perso.

    • Ah oui désolé, c’est dans ce commit dans ce fichier :
      https://zone.spip.net/trac/spip-zone/changeset/114460/spip-zone/_plugins_/formidable/trunk#file4

      Avec du coup une reprise du code de ce qui était depuis des années dans la génération automatique faite par Saisies (quand on ne déclare qu’en PHP), et qui n’avait jamais été reporté dans Formidable.

    • Question bête : comment utiliser la fonction multi-étapes ?
      J’ai lu avec intérêt la phrase d’explication et coché l’option

      Lorsque cette option est active, chaque groupe de champs de premier niveau est transformé en étape du formulaire.

      Néanmoins, je ne vois pas à quel endroit je peux déterminer le niveau d’un groupe.
      J’ai pourtant créé plusieurs champs (texte/email) dans cet ordre
      -  groupe de champs “page 1”
      -  champ 1
      -  champ 2
      -  groupe de champs “page 2”
      -  champ 3
      -  champ 4

      Et tous les groupes & champs s’affichent sur une seule page au lieu de deux

      D’avance merci

    • Tu as posé ta question dans un fil existant qui n’a pas de rapport, ce n’est pas très pratique.

      Mais ya rien de plus à faire, et en plus si tu vois l’option c’est bien que tu es à jour de Saisies et de Formidable à priori. Tu crées des groupes, tu mets des champs dedans, puis tu coches l’option, et hop c’est tout, le formulaire est alors en étape.

      Après t’es peut-être pas repassé par admin_plugin entre temps pour que ça mette à jour les utilisations de pipelines, après tes mises à jour…

    • Merci pour ta réponse.
      Si mon message apparaît dans un fil c’est indépendant de ma volonté : hier j’allais vraiment répondre à ce fil et avais préparé du texte sans cliquer sur “confirmer l’envoi”. Aujourd’hui je suis revenu sur la page et suis allé sur la case commentaire en bas de page (comme si j’allais débuter un nouveau fil) qui était pré-remplie : j’ai effacé ce texte et remplacé par du nouveau mais mon commentaire s’est inséré au mauvais endroit. Une fois publié je ne peux rien faire, même pas supprimer mon commentaire pour le recréer au bon endroit.
      Je bidouille depuis un temps certain pour comprendre et je pense avoir trouvé en utilisant “position du champ”. La fonctionnalité est super, néanmoins sa mise en oeuvre est laborieuse...

    • Déjà 1) le champ position sert juste quand t’as pas JS, t’as bien vu que tu pouvais déplacer les champs en drag-n-drop déjà ?

      Et 2) quand tu crées un champ (et donc y compris les groupes de champs) ils sont déjà de base à la racine du formulaire, donc au quoi yorait à jouer avec ça ? Si t’as crées des groupes, ils sont déjà au bon endroit par défaut (ils sont pas à l’intérieur d’un autre groupe quoi, ya pas d’imbrication).

    • ça c’est la théorie. J’ai fait comme d’hab, à savoir créer mes champs & groupes dans le bon ordre et le résultat était que tous les champs était sur la même page au lieu d’être en plusieurs étapes.

      Le drag & drop place un champ sous un autre alors qu’il faut qu’il soit en décalé. Voir la partie gauche de ma copie d’écran. pour la parti droite elle reproduit ce qu’on voit en partie publique

    • Non non, on peut parfaitement déplacer un champ à l’intérieur d’un groupe de champ en drag-n-drop. Le rectangle cible n’est pas le même et on doit bien voir qu’il est décalé à l’intérieur du groupe.

    • Certes, néanmoins la nuance n’est identifiable que si on le sait.
      Si j’avais le temps j’essaierais d’améliorer le “mode d’emploi”. Un jour...

    • bonjour,

      je reviens sur le coeur de ce message : le texte affiché par le bouton.
      Pour ma part, dans la plupart des cas “Envoyer” est vraiment plus adéquate que “Enregistrer”. Puis-je modifier ? Est-ce qu’il y a une fonction du plugin qui le permet ?
      En vous remerciant

    • Yes :)

      Va dans > Formulaires > ton formulaire > Configurer les champs > Configurer les options globales en haut à droite

    • Bonjour Guilaind,
      merci pour ta réponse rapide,
      ça le fait parfaitement en renseignant le champ par <:forum_envoyer:>

    • Ça fonctionne en effet.
      Si tu as beaucoup de formulaires différents, c’est infiniment plus simple de changer avec la méthode que je t’ai indiquée que de changer dans les squelettes ou dans le fichier de langue

    • Oui, j’ai utilisé ta méthode,
      en renseignant le bouton avec <:forum_envoyer:>, ce qui permet de bénéficier de beaucoup de langues traduites par défaut, ou de créer sa chaîne de langue personnalisée...
      merci encore !

    Reply to this message

Comment on this article

Who are you?
  • [Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom