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)

updated on 5 April 2020

Discussion

730 discussions

  • 6

    Bonjour,

    Existe-t-il une “formule” pour forcer le remplissage d’une date ultérieure au jour présent ?
    Si on a 2 dates (typiquement arrivée / départ), comment peut-on forcer la date de départ à être ultérieure à la date d’arrivée ?
    Merci pour votre aide.

    • Non, à part en ajoutant du javascript soi-même. Je crois me souvenir que la lib qui gère le sélecteur de date le permet peut-être, mais ce n’est qu’un vague souvenir (faut vérifier dans le fichier dans le noyau de SPIP), mais dans les Saisies, c’est pas prévu. Si la lib du noyau le permet, ça pourrait être ajouté.

    • Non en fait je ne vois rien en ce sens dans “inc-dateur”…

    • Bonjour RastaPopoulos,

      Merci pour ta réponse rapide. Bon, dommage (car je pense qu’il y a utilité pour de nombreux cas), mais on attendra que ce soit intégré, prochainement j’espère ;-)

    • Bonjour,
      Est-ce qu’il est maintenant possible de vérifier si une saisie de date est supérieure ou égale à une date d’un autre champ du formulaire ?
      J’ai été regarder du coté du plugin https://contrib.spip.net/Affichage-conditionnel-de-saisie-syntaxe-des-tests mais il s’occupe uniquement de l’affichage, pas de la vérification de la saisie.

      Merci !

    • Bonjour,

      non ce n’est pas possible pour l’heure.

      Techniquement cela impliquerait :
      -  de modifier les vérifications pour vérifier un champ par rapport à un autre > pas si simple que ca, notamment en terme de syntaxe
      -  d’implémtenter les comparateurs de date, bon ca c’est facile à faire en php.

    • OK merci.
      Et en fait je n’avais pas vu mais maintenant lorsque l’on choisit une première date, la suivante se modifie pour prendre la valeur de la 1e (et ensuite on peut la changer).. Donc c’est cool cela évite une bonne partie des erreurs.

      dd

    Reply to this message

  • 1
    Fifouille

    Bonjour, j’ai installé le plugin Formidable. Auparavant j’utilisais le plugin forms and table.

    L’importation des formulaires se fait correctement.

    Cependant, je ne peux plus accéder à la gestion des plugins. La page affiche “MAJ init”.

    Avez-vous une idée du problème que je rencontre ?
    Merci

    Reply to this message

  • 9

    Bonjour,

    J’ai un site qui tournait sous spip 3.0.8 avec formidable 1.3.5, tout fonctionnait bien. J’ai mis à jour le spip et formidable, dans la liste des formulaire il me dit qu’il n’y en a pas (alors qu’ils sont bien dans la db), dans /ecrire, sur un article je vois bien mon formulaire s’afficher et sur le site publique les formulaires ne s’affichent plus.

    Afin de voir de nouveaux s’afficher la liste des formulaire, j’ai du remplacer la ligne 21 du fichier formidable/v4.3.0/prive/objets/liste/formulaire.html

    avant :

    1. <BOUCLE_formulaires(FORMULAIRES){objet?}{id_objet?}{id_formulaire?}{statut?}{compteur_left formulaires_reponses}{tri #ENV{par,titre},#GET{defaut_tri},session_tri_formulaires}{recherche?}{pagination #ENV{nb,10}}>

    apres :

    1. <BOUCLE_formulaires(FORMULAIRES){tout}{tri #ENV{par,titre},#GET{defaut_tri},session_tri_formulaires}{recherche?}{pagination #ENV{nb,10}}>

    J’ai aussi testé avec la 3.49.1 et c’est pareil, rien dans la liste, rien sur le site publique, mais ok quand on est dans l’article dans spip...

    Je ne comprends pas.... :’(

    • hum

      c’est étrange. Sans doute un bug de migration.

      Je regarde cela.

    • Sympa, merci !

      A noter qu’une fois la mise à jour faites, si je crée un nouveau formulaire tout bête pour tester, il n’apparait pas non plus dans la liste.

    • Bon,

      je reproduit pas.

      Ce que j’ai essayé de faire
      1. Installer php 5.6 pour piuvoir faire tourner un vieux spip 3.0.8
      2. Installer formidable 1.3.5 depuis les tags
      3. Créer un formulaire
      4. Mettre à jourspip vers 3.2.3
      5. Mettre à jour formidable vers 4.3.0
      6. Regarder la liste des formulaires : cela apparait.

      Je soupconne très vaguement un problème lors de la mise à jour des tables, mais alors quoi ?

      Voilà la structure de la table

      CREATE TABLE `spip_formulaires` (
        `id_formulaire` bigint(21) NOT NULL,
        `identifiant` varchar(200) DEFAULT NULL,
        `titre` text NOT NULL,
        `descriptif` text,
        `css` varchar(255) NOT NULL DEFAULT '',
        `message_retour` text NOT NULL,
        `saisies` longtext NOT NULL,
        `traitements` text NOT NULL,
        `public` enum('non','oui') NOT NULL DEFAULT 'non',
        `statut` varchar(10) NOT NULL DEFAULT '',
        `maj` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
        `apres` varchar(12) NOT NULL DEFAULT '',
        `url_redirect` varchar(255) DEFAULT NULL,
        `date_creation` datetime NOT NULL DEFAULT '0000-00-00 00:00:00'
      ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

      Qu’en est-il de votre côt é ?

    • Bonjour,

      Merci de vous pencher sur mon problème... c’est sympa.

      Voici avant la mise à jour :

      CREATE TABLE `spip_formulaires` (
        `id_formulaire` bigint(21) NOT NULL AUTO_INCREMENT,
        `identifiant` varchar(200) DEFAULT NULL,
        `id_rubrique` bigint(21) NOT NULL DEFAULT '0',
        `id_secteur` bigint(21) NOT NULL DEFAULT '0',
        `titre` text NOT NULL,
        `descriptif` text NOT NULL,
        `message_retour` text NOT NULL,
        `saisies` text NOT NULL,
        `traitements` text NOT NULL,
        `public` enum('non','oui') NOT NULL DEFAULT 'non',
        `chapo` text NOT NULL,
        `texte` text NOT NULL,
        `merci` text NOT NULL,
        `ps` mediumtext NOT NULL,
        `lang` varchar(10) NOT NULL DEFAULT '',
        `langue_choisie` char(3) DEFAULT 'non',
        `date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
        `maj` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
        `apres` varchar(12) NOT NULL DEFAULT '',
        `url_redirect` varchar(255) DEFAULT NULL,
        `type` enum('une_seule_page','plusieurs_pages') NOT NULL DEFAULT 'plusieurs_pages',
        `limiter_invitation` enum('oui','non') NOT NULL DEFAULT 'non',
        `limiter_applicant` enum('oui','non') NOT NULL DEFAULT 'non',
        `notifier_applicant` enum('oui','non') NOT NULL DEFAULT 'non',
        `notifier_auteurs` enum('oui','non') NOT NULL DEFAULT 'non',
        `statut` enum('hors_ligne','en_ligne') NOT NULL DEFAULT 'hors_ligne',
        PRIMARY KEY (`id_formulaire`)
      ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

      Et apres :

      CREATE TABLE `spip_formulaires` (
        `id_formulaire` bigint(21) NOT NULL AUTO_INCREMENT,
        `identifiant` varchar(200) DEFAULT NULL,
        `id_rubrique` bigint(21) NOT NULL DEFAULT '0',
        `id_secteur` bigint(21) NOT NULL DEFAULT '0',
        `titre` text NOT NULL,
        `descriptif` text NOT NULL,
        `css` varchar(255) NOT NULL DEFAULT '',
        `message_retour` text NOT NULL,
        `saisies` text NOT NULL,
        `traitements` text NOT NULL,
        `public` enum('non','oui') NOT NULL DEFAULT 'non',
        `chapo` text NOT NULL,
        `texte` text NOT NULL,
        `merci` text NOT NULL,
        `ps` mediumtext NOT NULL,
        `lang` varchar(10) NOT NULL DEFAULT '',
        `langue_choisie` char(3) DEFAULT 'non',
        `date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
        `maj` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
        `apres` varchar(12) NOT NULL DEFAULT '',
        `url_redirect` varchar(255) DEFAULT NULL,
        `type` enum('une_seule_page','plusieurs_pages') NOT NULL DEFAULT 'plusieurs_pages',
        `limiter_invitation` enum('oui','non') NOT NULL DEFAULT 'non',
        `limiter_applicant` enum('oui','non') NOT NULL DEFAULT 'non',
        `notifier_applicant` enum('oui','non') NOT NULL DEFAULT 'non',
        `notifier_auteurs` enum('oui','non') NOT NULL DEFAULT 'non',
        `statut` enum('hors_ligne','en_ligne') NOT NULL DEFAULT 'hors_ligne',
        `date_creation` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
        PRIMARY KEY (`id_formulaire`)
      ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

      Donc à part css et date_creation, pas beaucoup de différences... :/

    • Hum, deja cette différence est pas normale. Etes vous bien passé après la mise à jour sur la page d’administration des plugins ?

    • Oui, mise à jour spip via spip_loader, mise à jour formidable via gestion des plugins, je suis même aller sur la page de configuration de formidable apres.

      Je peux dupliquer l’environnement et vous donner un acces si vous voulez.

    • Hum, je sais pas si cela aiderait. De toute facon il est évident qu’il y a eu un souci. Et remonter tout l’historique du code pour comprendre pourquoi dans ce cas la migration chez vous s’est mal passée...

      enfin donnez toujours les infos de mysql.log, on sait jamais.

      Comme vous avez l’air de vous débrouillez, je dirais plutôt que l’idéeal serait que vous reproduisiez via PHP my admin la nouvelle structure des tables. Vous la trouverez décrite dans formidable/base/formidable

    • C’est gentil :D je suis dev web depuis 13 ans :D lol

      Bref, j’ai fais, et du coup c’est encore pire... plus d’id_rubrique dans la table formulaire du coup spip n’aime pas...

      Je m’arrache les cheveux dessus depuis hier...

    • mais, nul part dans le code actuel formidable ne réclame de l’id_rubrique....

      t’aurais pas du cache qui trainerait encore en fait ?

    Reply to this message

  • 2

    Je viens de constater une problème handicapant : quand je clique sur “Configurer le formulaire”, ce qui est censé ouvrir l’url /ecrire/?exec=formulaire_edit&id_formulaire=24&configurer=formulaire, une surfenêtre s’affiche avec le message

    Vous avez choisi d'ouvrir :
    qui est un fichier de type : application/x-httpd-php (0 octets)
    à partir de : https://monsite.tld
    Que doit faire Firefox avec ce fichier

    J’utilise beaucoup de plugins :
    Formidable 4..2.3
    Formulaires de paiement 1.2.3
    Banque et paiement 4.3.4
    Saisies pour formulaire 3.36.2
    SPIP 3.2.7 [24473]
    Ubuntu avec version php 7.1.29 et MySQL 5.5.62. Je peux passer php en 7.2 si besoin.

    J’ai essayé sur plusieurs navigateurs, j’ai essayé en saisissant la bonne url, etc.. J’ai vidé le cache, désactivé/réactivé les plugins, réinstallé formidable, mais rien n’y fait

    Je ne sais pas précisément quand est survenu le problème car je n’ai aucune raison d’aller modifier un formulaire qui fonctionne. Mes formulaires fonctionnent bien mais j’ai besoin d’en modifier un et suis coincé.

    Avez-vous une piste ?

    • Je ne reproduis pas. Il ne s’agirait pas plutôt d’un problème de ton hébergement ? Est-ce que tu as la même chose sur un site en local ? Et surtout avec uniquement les plugins nécessaires pour tester sans rien d’autre.

    • Merci pour la réponse.
      C’est la seule url sur ce site SPIP qui pose problème. J’avais déjà vu ça une fois ou deux il y a super longtemps et ça avait disparu comme c’était apparu.
      Sur le serveur il y a d’autres sites en spip ou autres mais aucun ne pose problème. J’hésite à passer le php en 7.2 pour voir si ça règle le problème car la dernière fois que j’avais tenté la 7.2 SPIP clignotait de partout.
      Dès que j’ai 2 ou 3 heures, je duplique pour pouvoir faire des tests dans tous les sens. Je suis déjà en train de faire d’autres tests sur mon environnement de dév.

    Reply to this message

  • 7

    Bonjour

    Je rencontre un souci avec un formulaire. Pour la partie traitement, j’ai coché “modifiable” et “id_auteur” comme méthode d’authentification :

    traitements:
      enregistrement: { 
         moderation: posteriori, multiple: '', modifiable: on, effacement: '', effacement_delai: '', identification: id_auteur, variable_php: '', unicite: '', message_erreur_unicite: '', anonymiser: '', ip: '', invalider: on, resume_reponse: '', analyse_exclure_champs: '' }

    et pourtant, certaines personnes ne retrouvent pas leurs réponses lorsqu’ils reviennent sur la page.

    Quelle pourrait en être la cause ?

    Merci de votre aide

    • Si les personnes ne sont pas connectées, elles ne peuvent pas trtrouver effectivement. C’est précisment l’interet de la méthode par cookies de permettre de revenir sur la page.

      Il faudrait plus de contexte.

      Mais comme je disais sur un ticket, à mon avis il faudrait proposer un autre système de modif de formulaire.

      Je t’invite à poster ici https://git.spip.net/spip-contrib-extensions/formidable/issues/6 tes éventuelles réflexions sur les besoins en terme de modification de formulaire.

    • En effet, j’ai oublié de préciser le contexte.

      Il y a une authentification BASIC faite sur le serveur Apache. Les gens qui accèdent à la page sont donc bien identifiés.

      Dans les réponses au formulaire, j’ai bien un id_auteur non nul pour chaque réponse :

      id_formulaires_reponse id_formulaire date id_auteur cookie statut maj
      2978 22 2020-04-22 20:19:31 85 1895457005ea08ab358acd6.80513477 publie 2020-04-22 20:19:31
      2869 22 2020-04-21 20:15:15 85 15059760815e9f38336e0f06.95112002 publie 2020-04-27 14:50:15
      2997 22 2020-04-24 14:17:46 90 5084607325ea2d8eae3e609.20276163 publie 2020-04-24 14:18:39
      2936 22 2020-04-22 12:45:34 90 20943758845ea0204e7baa91.67317318 publie 2020-04-27 14:51:12
      2937 22 2020-04-22 12:45:37 90 13240001215ea020518c33a9.88813610 publie 2020-04-27 14:51:16
      2980 22 2020-04-22 23:41:06 146 9125659695ea0b9f28001c7.70077820 publie 2020-04-22 23:41:06
      2838 22 2020-04-21 18:24:25 146 16077315065e9f1e3952d697.08847832 publie 2020-04-27 14:52:04
      2996 22 2020-04-24 14:14:12 185 19344344165ea2d814805811.61659040 publie 2020-04-24 14:14:12
      2893 22 2020-04-22 08:06:12 185 18001428435e9fded43d04d5.82023248 publie 2020-04-27 14:52:41
      2843 22 2020-04-21 18:33:57 1117 1340426165e9f20759a4ce2.40291134 publie 2020-04-21 18:33:57
      2699 22 2020-04-20 19:00:15 1117 17366461345e6f7a5261c7b5.33523604 publie 2020-04-27 14:52:52
      2941 22 2020-04-22 13:12:45 1346 4067873165ea026ad881d84.01839630 publie 2020-04-22 13:12:45
      2940 22 2020-04-22 13:12:42 1346 6309738135ea026aa2b0924.98738113 publie 2020-04-27 14:53:18
      2950 22 2020-04-22 14:31:57 1443 6376937585ea0393d89b2c2.04816316 publie 2020-04-22 14:32:05
      2949 22 2020-04-22 14:31:51 1443 2446928545ea0393766eac8.70269727 publie 2020-04-27 14:53:49
      2951 22 2020-04-22 14:39:06 1482 14632554215ea03aea20abf7.53478682 publie 2020-04-22 14:40:32
      2889 22 2020-04-22 01:13:19 1482 4140442105e9f7e0f471119.91679153 publie 2020-04-27 14:54:35

      Ce qui est étrange, c’est que pour ce formulaire, on a eu 220 réponses, et seules 9 personnes ont été concernées par le problème. Les autres ont pu modifier leurs réponses.

      Ce n’est pas la première fois que j’utilise cette fonctionnalité, mais c’est la première fois que je rencontre le problème.

      Je note aussi l’URL à laquelle faire remonter mes suggestions

    • Hum, difficile dire, surtout si cela n’arrive qu’à certaines personnes.

      Cela étant je vois que pour un même formulaire, plusieurs personnes sont identifiés. Est-ce que cela ne serait pas là le problème ?

    • Je pense que c’est l’inverse : la réponse n’a pas été trouvée, alors la personne a pu enregistrer une 2e réponse... Mais pourquoi, alors que la personne est bien identifiée (même id_auteur) formidable n’a pas réussi à reconnecter l’auteur à sa réponse ?

      Je sais malheureusement que les problèmes intermittents sont les plus difficiles à débuguer...

      J’espérais qu’il y aurait un élément flagrant dans ma config qui aurait fait tilt chez les développeurs.

    • Malheureusement là je vois pas, surtout vu le coté intermittent.

      COmment appel tu le formulaire?

      est tu sur qu’on a bien une session pour l’auteur et que le pb se situe pas en amont ? Comment se passe le lien authtenification BASIC / Authentification SPIP

      (tout ce joue dans la fonction formidable_verifier_reponse_formulaire() et dans formidable_trouver_reponse_a_editer de inc/formidable.php

    • J’ai un modèle formidable_avec_identification.html qui contient :

      [(#SESSION{id_auteur}|non)#FORCE_AUTH]
      [(#SET{email, [(#SESSION{email}|strtolower)]})]
       
      #FORMULAIRE_FORMIDABLE{#ENV{id}, #ARRAY{#ENV{email}, #GET{email}, #ENV{nom}, #SESSION{nom}}}

      Cela m’appelle le formulaire avec les champs nom et email de préremplis (et en lecture seule pour les utilisateurs).

      Ma balise #FORCE_AUTH permet de forcer l’identification SPIP avec ce qu’il y a dans les variables PHP :

      function balise_FORCE_AUTH_dyn($static) {
              if (isset($GLOBALS['auteur_session']['id_auteur']))
                      return;
       
              $auth = charger_fonction('auth', 'inc');
              $save = $GLOBALS['meta']["ldap_statut_import"];
       
              $res = $auth();
              verifier_session(true);
       
              $GLOBALS['meta']["ldap_statut_import"] = $save;
      }

      J’ai eu besoin de mettre en place cette balise pour que les personnes identifiées via le BASIC d’Apache aient la balise #SESSION remplie sans avoir à passer par l’interface privée.

      Les personnes qui ont eu le problème ont les champs noms et email de remplis. Comme ces champs sont en lecture seule et qu’ils sont remplis via le contenu de #SESSION, cela tend à prouver qu’ils sont bien identifiés dans spip ?

    • mouais,
      je sais pas trop. Dur à dire. Ca donne quoi surtout au niveau de #SESSIONid_auteur en fait. C’est ca la question.

    Reply to this message

  • 2

    Bonjour, je suis directeur d’école et je viens de créer mon premier formulaire (donc N° 1) pour réaliser une enquête de rentrée de déconfinement auprès des parents.
    Je l’ai tout paramétré et je l’ai appelé “Déconfinement” , Id “1105” (voir la photo jointe).
    J’aimerais le faire apparaître à l’écran; en lisant l’aide sur la page https://contrib.spip.net/Formidable-le-generateur-de-formulaires, il me semble avoir compris qu’il faut l’appeler dans le corps d’un article (mais peut-être qu’en fait je n’ai rien compris !).
    J’ai donc créé un article dans le corps duquel j’ai inséré : baliseformulaire|Déconfinement|id=1105/balise (j’ai écrit balise car si je mets les < > ici, ce qui est entre les deux ne s’affiche pas) , mais malheureusement, lorsque j’enregistre mon article, rien n’apparaît.
    Alors peut-être que je dis et fais des bêtises, c’est pourquoi je viens solliciter un peu d’aide de la part de quelqu’un qui maîtrise le sujet.
    Merci beaucoup par avance pour votre réponse !
    J-J

    • Hello,
      le modèle que tu indiques mettre dans ton article n’a rien à voir avec ce qui est décrit dans la documentation plus haut.

      Tu dois copier ce que dit la doc, et mettre en argument “id” soit l’identifiant numérique SQL (1) soit l’identifiant humain textuel (que tu as mis “1105”). Sauf que tu ne peux pas utiliser 1105 parce que c’est un nombre, et que quand c’est uniquement un nombre ça cherche un formulaire suivant l’identifiant SQL. Il faut plutôt mettre “deconfinement” ou “deconfinement1105” comme identifiant textuel.

      Pour écrire du code dans les textes, il faut utiliser la syntaxe de code (il y a un bouton pour ça dans la barre du champ) :

      <formulaire|formidable|id=1>
      <formulaire|formidable|id=deconfinement>
    • RE,
      un grand merci pour ton aide (très rapide) qui m’a permis d’y arriver.
      Le formulaire est fonctionnel et en page d’accueil du site.
      J’ai compris les explications, du coup, il me semble que pour aider un profane comme moi, ça serait peut-être bien d’indiquer qu’il faut absolument écrire “formidable” en titre (car j’ai cru que c’était le titre donné au formulaire dans l’exemple), et pour la même raison, expliquer qu’il ne faut pas que des chiffres dans l’identifiant (il ne me semble pas avoir vu une explication là-dessus, ou alors je l’ai loupée).
      Encore merci et bravo pour ce plugin aux multiples possibilités !
      J-J

    Reply to this message

  • 1

    Bonjour,

    Merci pour ce plugin.

    J’ai fait un fomulaire de contact pour un site. SPIP 3.2. et Formidable 4.2.3.
    Au niveau de la saisie du courriel de la personne qui contact, en mettant : monmail@monsite, le mail part alors que j’ai mis le type de vérification à mail et le mode à “Vérification la plus conforme aux standards disponibles”. De plus, le mail est obligatoire.

    Une piste pour que la vérification soit effective ?

    Merci d’avance pour toute aide.

    Gilles L.

    • Il n’y a aucun problème, la vérification est parfaitement correcte, c’est celle là qui est la plus correspondant aux standards RFC officiels.

      Un nom de domaine n’a pas du tout forcément d’extension. Par exemple si tu es dans un réseau d’entreprise, un intranet (et on peut parfaitement faire un SPIP dans un intranet), les adresses en interne peuvent parfaitement être “robert@notresuperintranet”, “jean-michel@localhost”…

    Reply to this message

  • 6

    bonjour à tous,

    je tenais à vous féliciter pour les modules extras que je découvre encore après tant d’années.

    Je suggérais une forme de remplissage d’’options spéciale pour donner à l’utilisateur le choix de plusieurs offres, chaque offre étant dans un article par ex. (le navigateur d’articles ne répond pas à la question)

    et je suggérai une écriture possible du style , pour Liste des choix possibles d’un bouton radio par ex :

    choix408|[->art408]
    choix406|[->art406]
    choix222|[->art222]

    évidemment le titre de l’article désigné s’affiche devant le bouton radio.
    à moins que cela existe déjà mais cela ne s’écrit pas ainsi ? Merci d’avance !

    • c’est bien déjà le cas et avec déjà cette écriture là pour les boutons radios non ?

    • Oui sauf que dans l’exemple,

      choix408|[->art408]

      n’affiche ni le titre de ni le lien vers l’article 408

    • Effectivement les textes “simple ligne” comme ça (label, explication, etc), ne passent jamais dans propre() qui gère la syntaxe légère de SPIP, et c’est voulu car c’est tout ou rien. Si on l’accepte c’est tout, or la syntaxe de SPIP permet de générer plein de choses, y compris des éléments de type “blocs”, qui n’ont rien à faire à l’intérieur d’un label, d’un span, etc.

    • Au passage, avoir des liens sans les contrôler vraiment en détail dans des éléments de formulaire, c’est très dangereux car si les gens cliquent, ça change de page et ils perdent tout ce qu’ils avaient commencé à remplir.

    • Je vais dans le sens de Rastapopoulos. Ouvrir l’inteprétation des raccourcis dans les arguments seraient la boîte de pandore, avec des conséquences difficile à imaginer.

      Ce que je conseillerait en revanche, pour un besoin particulier, serait que vous créeiez votre propre saisie, capable de lister des articles en radio, en mettant aussi des liens (ouvrant vers une nouvelle fenete, cf la dernière remarque de Rastapopoulos)

    • Bonjour à tous,

      merci bien , j’avoue que vous avez raison: les gens vont se perdre à cliquer et aller ailleurs, c’était juste une suggestion mais pas adaptée c’est un fait.

      J’ai fait une brève qui donne un lien vers un mot clé qui regroupe la liste des articles, et la breve appelle en dessous un formulaire formidable avec des radios au titre fixe" (copie coller des titres des articles) avec un paiement Bank vers Slide (merci à vous) : une vraie merveille ! Comme cela, une fois parti dans le formulaire, on y reste.
      bonne journée !

    Reply to this message

  • 5

    Bonjour
    depuis aujourd’hui (au moins), les personnes qui envoient un formulaire recoivent ce message d’erreur :
    Fatal error: Call to undefined function saisies_lister_par_etapes() in /apps/web/crbpo/site/plugins/auto/formidable/v4.2.3/formulaires/formidable.php on line 226

    Cordialement

    • merci beaucoup
      fait et ca marche

    • I love SPIP

      Bonjour,

      La surcharge formulaire_4_accuse.html fonctionne pour le formulaire ID 4
      En revanche pas celle formulaire_4_email.html

      elles sont toutes les deux dans squelettes/notifcations
      formulaire_4_accuse.html
      formulaire_4_email.html

      Qu’est-ce que je fais mal ?

      Avec mes remerciements,

    • Ben déjà ce que t’as fait mal, c’est de faire une nouvelle question en réponse à un fil existant. :D

      Sinon je vois pas comment ça peut marcher déjà pour le premier, vu que c’est l’identifiant que tu dois utiliser, pas l’ID SQL.

    • I love SPIP

      Toutes mes excuses pour le poste au mauvais endroit. J’ai pas bien l’habitude.
      Merci pour la réponse je n’avais pas saisie la différences entre les identifiants.
      Merci pour tout Rastapopoulos et encore toutes mes excuses.

    Reply to this message

  • 2
    MacIndian

    Je viens de faire la migration d’un vieux SPIP de 1.9.2 vers 3.2.
    J’utilisais auparavant Formulaires & Tables.

    J’ai installé Formidable 3.2.7 mais j’obtiens une erreur lorsque j’accède à la page “Configurer les traitements” :
    Fatal error: Call to undefined function saisies_lister_par_() in /plugins/auto/saisies/v4.0.0/inc/saisies_lister.php on line 138

    J’utilise PHP Version 5.4.45

    Cela survient sur un formulaire qui existait déjà et également sur un nouveau formulaire que je viens de créer.
    Je n’ai pas trouvé de publications sur le web au sujet de cette erreur.

    Reply to this message

Ajouter un commentaire

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