Formidable, le générateur de formulaires

Un générateur de formulaires facilement configurable pour les non-informaticien·ne·s 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 :

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

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)

Discussion

751 discussions

  • 3

    Je cherche à ajouter un identifiant unique dans un champ visible dans un formulaire.
    Problème je ne sais pas du coup comment faire cela.
    Serait-ce possible d’ajouter l’ID de la réponse dans un formulaire ?

    Reply to this message

  • 1

    J’ai un problème d’affichage du bouton submit après mise à jour de Formidable 4.14.3 - stable à Formidable 4.15.0 - stable.

    Le style du bouton ’est plus pris en compte.

    <button type="submit" class="submit" name="submit" value="1">Envoyer</button>
    On voit juste “envoyer” sans style

    dd

    • Formidable en lui même ne style pas. C’est
      par contre ce qui est vrai c’est qu’on a remplacé un input par un button. peut être est-ce du côté de tes styles qu’il faut corriger (styles qui auraient du utiliser uniquement la classe).

    Reply to this message

  • 5

    Hello,
    Est-ce qu’il serait envisageable que l’option “Effacer régulièrement les résultats les plus anciens” affecte tous les résultats ?
    J’ai remarqué que les réponses au statut “proposé” ne sont jamais effacées ce qui peut poser problème pour la conservation des données personnelles, voire la taille de la base..

    merci.

    • je viens de regarder le code, et il n’y a rien qui test un quelconque statut des réponses. Donc tu dois avoir un autre problème chez toi.

    • J’essaie de trouver ce qui cloche.
      Ce qui est sûr c’est que cette incohérence se retrouve sur plusieurs sites (SPIP 3.2.11 [24473] / Formidable 4.14.4 - stable )

      Après rien n’est sûr .. :

      Est-ce que c’est géré par un cron ?
      Il y a sur la page ?exec=job_queue

      Tâche CRON formidable_effacer_enregistrements (toutes les 86400 s) | formidable_effacer_enregistrements(1618602334)

      Ce qui doit correspondre à 24h. Mais ce ne doit pas être ça puisque chaque formulaire peut avoir une config différente.
      J’ai dans ma config d’un formulaire : “Nombre de jours avant effacement : 365” et les réponses de plus de 2 ans sont toujours là.

      Je me souviens avoir eu un décalage du au délai de hashage des IP (qui du coup remettait le décompte à zéro), mais là c’est quand même étrange sur plusieurs années.

      dd

    • toutes les 24 heures on recherche les enregistrement trop vieux.

      regrde plutot du côté de mysql.log

    • Je n’ai rien dans les logs.
      Après quelques jours d’attente pour tests il semblerait que
      ticker “Ne pas conserver l’identifiant de la personne connectée.”
      et ne pas ticker “Enregistrer les IPs (masquées après un délai de garde)”

      permette l’effacement progressif des réponses au-delà d’un délai.

      Mais j’ai encore des réponses gardées bien au-delà du délai de 180 jours.

      dd

    • heu “ticker” ? connais pas ce verbe :p

      ca va être compliqué de dire ce qu’il en est en fait avec le peu d’info que tu nous fournis. Mais ce que je peux te dire c’est qu’on calcule l’age à partir du champ “maj”

    Reply to this message

  • 7

    Bonjour à tous, je suis sous Spip 3.2.11 et j’ai voulu mettre à jour Formidable : la version 4.14.3 m’a fait complètement planter mon site.
    J’ai mis du temps à trouver le plugin fautif, mais c’est bien Formidable.
    Heureusement, vous avez laissé les anciennes versions sur la page des plugins : je suis redescendu à Formidable 4.13.2 et tout refonctionne correctement.
    Lorsque j’activais Formidable 4.14.3 je me retrouvais avec une page blanche (y compris la page d’admin)
    Merci !
    Eric LM

    • oui, il y a visiblement un bug sur les vieilles versions de PHP, mais je n’arrive pas juste en lisant le code à comprendre quoi. Et impossible de reproduire.

      Si vous m’envoyer un accès à un site de test sur votre hebergeur, avec accèsftp, je pourrais regarder...

    • Si page blanche, ça veut dire erreur fatale PHP. Il faudrait activer l’affichage des erreurs sur un site qui a le problème pour déjà savoir ce que PHP en dit (quelle erreur dans quel fichier)

    • Oh là là... C’est un site que j’ai récupéré, et je n’ai pas la main sur la config PHP. Et effectivement, on est en 5.5 !!!
      Merci pour le retour. Je vois avec le client pour qu’il fasse évoluer cela dans son interface OVH.
      Bonne soirée !

    • Comme je disais, si j’avais un accès (en privé) à un site spip sur le serveur concernée, je pourais sans doute debuger (aussi : si on a les message d’erreur !!!)

    • Euh... le site est en fonctionnement, il n’est pas du tout en test. Je veux bien te passer tous mes codes d’accès, y compris FTP, mais je suis un peu hésitant...

    • non, non, ne le fais pas. C’est si jamais c’était simple pour toi de monter un autre site avec un compte ftp dédié, chez le même hebergeur.

      Mais sinon le plus simple reste encore d’envoyer le message d’erreur... https://www.spip.net/fr_article4453.html#Page-blanche

    • c’est corrigé dans la v4.14.4

    Reply to this message

  • 3

    Bonjour,
    J’utilise Formidable 4.9.0.
    Dans les traitements, j’ai un souci sur l’exclusion de certains champs dans les notifications.
    Si j’indique dans le champs “Champs à exclure du contenu du message” quelque chose comme ceci:

    radio_1,radio_2,explication_1,explication_2,fieldset_1,input_1

    ou encore

    radio_1

    le message de notification au/à la destinataire ne contient plus aucun champ, et seulement les parties communes à tous les courriels de notification aux destinataires.

    Lorsque j’indique ceci:

    input_1

    le champ qui correspond à “input_1” n’est plus interprété dans le courriel destinataire (je l’ai mis dans ’objet du courriel) ni dans le courriel expéditeur·ice, par contre, il est bien présent dans le corps du courriel destinataire de façon automatique.

    Qu’est-ce que je fais qui ne va pas pour avoir ces comportements là?

    Reply to this message

  • 2

    Bonjour,
    Lorsque l’on exporte les réponses d’un formulaire la colonne “adresse IP” est vide, par contre il y a bien l’entête de la colonne (donc les valeurs des colonnes suivantes sont décalées),
    ceci même si la case “Enregistrer les IPs (masquées après un délai de garde)” est cochée.
    Pour la page “Tableau des réponses” la colonne “adresse IP” n’apparaît pas du tout (c’est peut-être voulu).

    C’est un vil détail mais je ne comprenais pas les réponses avant de trouver le hic.

    • Hum, il y a plusieurs choses

      1. Tu dois avoir un souci au niveau de ton tableur, car normalement un champ vide en csv va bien produire une cellule vide, et tu ne devrais pas voir le décalage
      2. Par ailleurs, l’export des adresses IP n’est pas activée par défaut, pour des questions de confidentialités. C’est une option de config de formidable.

      Pour autant il y a quelques améliorations que je viens d’apporter:
      -  sur la branche master de formidable : si jamais on n’exporte pas les IP, ne pas afficher l’info “IP” dans l’entête
      -  sur la branche master de formidable_tablesorter : afficher les IP si jamais on a coché l’option formidable pour l’export des IP

      Je ne release pas maintenant car on me reproche de le faire trop souvent. Peut être le week-end prochain si rien ne tombe entre temps.

      Tu peux recuperer les zip des branches sur git.spip.net pour faire ta propre install (ou bien utiliser git

    • Merci cela fonctionne maintenant.

    Reply to this message

  • 7

    Bonjour,

    Je souhaiterai avoir un formulaire avec plein de champs qui s’affichent de façon conditionnelles. Il s’agirait d’une sorte de FAQ dont l’aboutissement pourrait être une réponse toute faite, ou bien la rédaction d’un courriel et envoi avec le bouton de validation du formulaire.

    Sauf que pour la réponse toute faite, l’idéal serait de ne pas faire apparaître le bouton de validation bien sûre.

    Y’a t-il également moyen avec formidable ou autre chose, de faire apparaître ce bouton de validation de façon conditionnelle?

    • 1. Il est possible de configurer les champs pour que leur affichage dépendent d’autres champs (onglet “affichage”)
      2. Une version de dev que tu peux télécharger ici permet également de conditionner le bouton globale https://git.spip.net/spip-contrib-extensions/formidable/archive/afficher_si_button.zip
      Il faut se rendre dans la configuration des options globales des saisies (tout en haut de l’interface d’édition des saisies).

    • C’est une bonne nouvelle tout ça. Je teste ça tout bientot. Un besoin de retours sur cette fonctionnalité?

    • Eventuellement. Mais ca devrait rouler relativement bien (enfin bon courage pour tous vos tests conditionnels !).

      La seule vrai question que je me pose c’est si je ne devrais pas en plus ajouter une option pour mettre un message si jamais le bouton est masqué, car un formulaire sans bouton c’est chelou.

    • Salut, des petits retours sur cette fonctionnalité ?

    • Salut!
      J’ai pas explorer à fond la possibilité qu’il y ait des effets indésirables. Mais en attendant, ça fait bien ce que ça doit faire.
      Grand merci à toi.

      — 
      Ludo

    • oki ! super !

      bon j’attend avis formelle des copains/copines sur la PR, et on valide.

    • C’est intégré dans la version 4.9.0 de formidable. Attention, j’ai un peu changer la manière de procéder, et il faudra aussi mettre à jour saisies.

    Reply to this message

  • 16

    Bonjour

    Un très soucis depuis quelques jours : les données des formulaires se mélangent d’une réponse à l’autre.

    J’utilise un formulaire pour que mes clients me fournissent des infos concernant leur projet. Et bien, les données du client précédent sont carrément affichées dans le formulaire du client suivant. Ce sont des données confidentielles. Mes clients perdent confiance et nous nous mélangeons les pinceaux dans les projets.

    C’est arrivé il y une semaine pour un client. Je pensais à un BUG transitoire et exceptionnel. Mais cela vient de se reproduire sur plusieurs clients.

    • Heu... peut être un bug de votre côté sur la manière dont vous appeler les formulaires en disant de reprendre les anciennes données lorqu’un client veut modifier ses données, mais il y a pas de raison que cela se produise.

      Donc deja

      1. Quel est la configuration du formulaire ?
      2. Comment l’apperlez vous

      Et surtout : avec vous mis à jour formidable récemment. Cela permettrait de detecter une éventuelle regression.

    • Merci pour l’aide

      La configuration :
      -  Enregistrer les résultats du formulaire dans la base de données
      -  modération a posteriori
      -  Modifiable : Les visiteurs peuvent modifier leurs réponses après coup.
      -  Identification : Par cookie (identifiant aléatoire, ne stocke aucune information personnelle)

      Appelé dans le texte d’un article :

      <formulaire|formidable|id=ficheprojet>

      J’étais sur la version 4.0.7. Je viens de faire la mise à jour vers 4.6.2.
      Donc très en retard, mais c’est inquiétant que le bug survienne subitement sans mise à jour préalable.

    • Donc tu étais sur la 4.0.7 au moment où tu avais le bug, et tu viens juste de passer en 4.6.2 ? ou bien tu étais en 4.0.7 et c’est en passant en 4.6.2 que tu as eu le bug ?

    • Le bug était avec la 4.0.7.

      J’ai mis à jour vers 4.6.2 en lisant votre message. Pour le moment, je ne peux pas dire si le bug est toujours présent ou pas. Il n’y a que mes clients qui peuvent me le dire. Je reviendrai ici si besoin.

    • Des nouvelles sur ce problème ?

    • Bonjour Maïeul, merci pour le suivi.

      Le bug ne s’est pas reproduit depuis.

      Vu l’étrangeté, je me demande si il n’est pas lié à un manque d’espace disque sur le serveur ? cela m’arrive régulièrement ; des logs et des caches qui grossissent jusqu’à saturer le disque. Cela provoque des trucs bizarres. Peut-être que APACHE s’embrouille dans les fichiers de sessions, faute de ne pouvoir en créer de nouveau. Du coup, mixe entre les visiteurs.

      Il se trouve que c’est arrivé à la même période.

      Ni SPIP, ni FORMIDABLE ne seraient en cause si cette hypothèse est avérée.

    • Bonjour Maïeul

      Le BUG se reproduit à nouveau, et de façon quasi-systématique. depuis plusieurs semaines.

      Je pensais initialement un espace disque insuffisant. Mais beaucoup plus d’espace depuis 2 mois. Donc c’est autre chose.

      Pour rappel :
      -  des clients qui accèdent à des données d’autre clients, dans leur formulaire pré-rempli
      -  des fiches qui disparaissent du back-office. Pourtant, on avait bien reçu copie des données via email.

    • bah heu là franchement c’est dur à dire. Tu es le seul qui a cela...

      Je ne reproduis cela nul part. Et les données qui disparaissent de l’espace privé > est ce que tu les a eu une seule fois dans l’espace privé ? que donnent les logs apache + formidable ?

    • et que donnent les logs mysql aussi ?

    • dis voir, dans ta structure de squelette, tu n’aurais pas par hasard des #INCLURE à la place de <INCLURE> ?

    • dis voir, dans ta structure de squelette, tu n’aurais pas par hasard des #INCLURE à la place de <INCLURE> ? est-ce que tu as des plugins qui jouent sur le cache ?

    • OUI j’ai de nombreux #INCLURE. J’ai toujours pensé que cela permettrait au serveur de répondre plus rapidement, quitte à avoir un cache plus volumineux.

      Faut-il que je passe sur <INCLURE> ?

    • oui, on évite les formulaires au sein des #INCLURE; il vaut mieux des <INCLURE>, ca peut poser des problèmes par ailleurs (mais c’est à niveau trop complexe pour moi pour savoir a priori si c’est la cause de ton souci !). En tout cas, essai, et revient après ces essais.

    • Même si ça ne résout pas ce point là, oui de toute façon il faut transformer en , la balise #INCLURE doit être utilisée avec beaucoup de parcimonie, et ça ne fait pas du tout pareil, notamment il ne peut y avoir de choses dynamiques à l’intérieur.

    • OK j’ai planifié le remplacement des #INCLURE.

      Et pour les #CACHE, c’est pareil, faut éviter, ou bien ?

    • Une personne experte en compilation et formulaire SPIP me murmure par IRC que oui, la cause du bug c’est à 99,9% de chance les #INCLURE parents.

    Reply to this message

  • 10
    essaillon

    Bsr,

    Comment mettre en forme les réponses d’un formulaire dans le mail transmis au contact ?
    Pour l’instant je reçois en colonne

    * Label 1
    * réponse 1
    * Label 2
    * réponse 2
    * Label 3
    * réponse 3

    au lieu de

    * Label 1 : réponse 1
    * Label 2 : réponse 2
    * Label 3 : réponse 3

    Merci

    • Si c’est juste pour cela, tu peux mettre dans mes_options.php

      define('_SAISIES_AFFICHAGE_COMPACT', true);

      pour d’autres mises en forme, il faut surcharger le gabarit d’email.

    • essaillon

      Merci pour la réponse rapide mais aucun changement, hélas.

    • Je viens de tester, et je confirme que cela marche cehz moi,

      Pouvez vous me partager votre mes_options.php ?

    • essaillon

      Voilà

      <?php
      define
      ('_SAISIES_AFFICHAGE_COMPACT'true);
      ?>

    • oui, docn c’est correcte. Quelle version du plugin saisies?

    • essaillon

      Saisies pour formulaires 3.46.1

    • essaillon

      J’ai peut-être oublié d’indiquer que je sous sur une mutualisation.
      https://agha.fr

    • hum, je ne sais pas niveau mutualisation comment ca se passe pour le mes_options.php...

    • essaillon

      Bjr,

      Je reviens sur le sujet.

      En fait,
      <?php
      define
      ('_SAISIES_AFFICHAGE_COMPACT'true);
      ?>

      a bien amélioré la présentation dans l’email, merci.

      Mais je reçois, dans le même email la présentation ancienne avec les mêmes données brutes en colonne. :(

    • heu...
      il faudrait vérifier votre install, Peut être un plugin ou squelette qui surcharge ?

      Ou bien peut être votre lecteur de mail vous fait voir la version html et la versio0n simple texte ?

    Reply to this message

  • 3

    Om me signale un bug difficilement comprehensible et reproductible. Un utilisateur se plaint régulièrement que lorsqu’il insère un lien [texte->lien], il perd les saisies entrées (et est obligé de reprendre depuis une sauvegarde yaml).

    J’avoue ne pas voir d’où cela pourrait venir. Une piste Rasta?

    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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite / PostgreSQL
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparait.

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.

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