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
- Affichage des réponses sous forme de tableau
- 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 :
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)
Discussions par date d’activité
729 discussions
Hello
On me demande construire un formulaire un peu spécial.
L’idée est que l’utilisateur remplit un premier champ et dès que ce champ est rempli les autres champs se remplissent automatiquement à partir d’un tableau CSV (si la première valeur est trouvée dans le tableau, bien sur).
Ensuite il modifie les valeurs inexactes ou pas, il indique s’il a fait des modifs et il valide.
Le but est de faire vérifier des infos de contact.
Possible ou pas ? Le problème est de récupérer la valeur par défaut dans le fichier CSV.
Bonjour Jean Christophe.
Oui, c’est possible, en passant par une saisie input personnalisée qui peuplerait les champs voisins avec un bout de javascript.
Tu as un exemple fonctionnel dans le plugin FFE data, qui récupère les infos depuis un webservice pour faciliter l’inscription.
Dans ton cas, il faut adapter pour boucler sur le CSV. Et la saisie suppose également que les champs voisins aient un nom attendu.
Enfin, pour que la saisie perso soit manipulable depuis formidable, il faut créer un fichier .yaml de description dans le même dossier que la saisie.
Merci pour la réponse et pour cette piste de travail. On va regarder ça de près avec ma collègue plus à l’aise avec php que moi (ce qui est facile ;-) ).
Reply to this message
Bonjour
J’ai créé un formulaire ficheprojet et j’ai configuré :
- Modifiable : Les visiteurs peuvent modifier leurs réponses après coup.
- Identification des réponses : par cookie
Et cela fonctionne bien. Si je retourne sur mon formulaire plus tard, les données sont toujours là.
Ensuite, j’ai dupliqué ce formulaire en ficheprojet_2, ficheprojet_3, ficheprojet_4, ficheprojet_5, avec exactement la même configuration.
Si je remplis un de ces formulaires, et si je reviens dessus juste après, les données ne sont PAS conservées, tout est perdu. Alors que cela fonctionne bien avec le 1er formulaire.
Est-ce un BUG ou un problème de configuration ?
MERCI pur votre aide.
dans la config rien n’est perdu après duplication ? c’est bien la même chose que pour le premier ?
Reply to this message
Bonjour,
Je suis en train de configurer un question/sondage en utilisant le plugin.
Je n’arrive pas à mettre un affichage conditionnel sur un groupe sur la première question et du coup je préfère poster ma question.
la conf est la suivante :
et par défaut le @oui_non_1@ est positionné à “oui”, d’ailleurs qu’ils soit positionné à ou ou non cela ne change rien et que je mette “Oui” ou “oui” dans la condition ne change rien.
Faut-’il configurer autre chose dans la zone privé du plugin. Pour info je suis sous SPIP 3.2.7
Merci
La saisie oui_non produit “on” ou “” (chaine vide) comme vraie valeure ,c’est évidement pas le label humain qu’on teste (et qui peut changer suivant les langues), comme pour n’importe quelle autre saisie, on teste la vraie valeur technique.
Mais cela dit, je ne vois même pas comment tu peux avoir la saisie oui_non alors qu’elle est dépréciée et n’est plus proposée.
Quelle version de formidabel et de saisies? la saisie oui_non est obsolète, il lui faut préferer des saisies avec des textes explicites, pour des questions d’accessibilité. Du type “oui j’ai été contraint” et “Non je n’ai pas été contraint”
Ensuite j’imagine que vous parliez bien de l’onglet “affichage selon un champ” ?
Enfin, même si vous gardez oui/non (ce que je déconseille) il se trouve que la valeur a testé est un peu piégeuse. Il faut tester
@oui_non_1@=='on'Merci
effectivement passer avec un contrôle du champs par “on” ou “” marche parfaitement.
Bonne journée à vous
Reply to this message
Bonjour,
Mes formulaires s’affichent bien dans spip, pas de soucis, par contre ils ne s’affichent pas dans les squelettes. Auriez une idée ?
Merci
le formulaire est-il bien publié?
Reply to this message
Bonjour,
Merci pour ce formulaire que je trouve parfait.
Par contre, pensez-vous qu’il serait possible qu’une réponse postée pourrait être exporter directement dans un nouvel article spip. Cela éviterait de ressaisir chaque champs dans l’article.
Si c’est possible, j’avoue que je n’ai pas trouver comment faire dans par exemple : configurer les traitements.
Merci de votre aide.
Pour la petite histoire sur mon site https://www.edition999.info/Formulaire-d-envoi-de-votre-livre.html les auteurs postent un formulaire pour leur livre et ensuite je crée un article qui met à disposition ce live gratuitement.
Ce serait compliqué car selon la structure du formulaire, la structure de l’article devrait s’adapter. Donc sûrement pas en natif. À la rigueur dans un plugin à part, avec un nouveau traitement,
Mais sinon c’est possible de
1) créer son propre modèle à appeler dans l’article https://www.spip.net/fr_article3454.html
2) ce modèle utilisera les boucles et balises de formidable https://contrib.spip.net/Balises-et-boucles-avec-Formidable
3) il faudra aussi ajuster les traiements pour que les réponses soient publiques
Cela étant je me demande si dans votre cas vous n’auriez pas meilleur temps d’utiliser le plugin “Fabrique” pour créer un nouveel objet “critique de livre”.
Cela dit il y a un sous-plugin FormiTable, qui ajoute justement un traitement pour que la réponse soit transférer dans un objet SPIP à configurer dans le traitement (plugin de JLuc mais qui était expérimental). Il n’a pas l’air d’avoir été importé dans le git.
Merci beaucoup je vais regarder ces possibilités.
Je me rappelle, voici plusieurs années, j’utilisais le plugin Forms et Tables et celui-ci permettait en appuyant de mémoire sur exporter, dans l’espace privé, d’ouvrir un nouvel article et que certains champs étaient déjà pré-rempli.
Mais parfois ma mémoire peut me faire défaut.
Merci encore et je reviendrai vers vous si je trouve une possibilité facile à mettre en oeuvre, cela pourrait peut-être aider des utilisateurs de Spip.
Reply to this message
Bonjour,
merci pour votre plugin qui rend bien des services. Toutefois, il a quelque chose que je n’arrive pas à faire.
je cherche à savoir comment récupérer une variable depuis l’url pour l’injecter dans le formulaire saisie en contenu. Je m’explique :
j’ai un article 32 qui contient dans le texte :
<formulaire|formidable|id=contact|defaut=destinataire,4>c’est-à-dire que le destinataire par défaut est le 4
lorsque je clic sur spip.php?article32&destinataire=10
je voudrais que le destinataire soit 10 et pas 4
Est-ce possible,et si oui, comment faire ?
Merci.
Tu ne peux pas logiquement faire ça depuis le texte d’un contenu SPIP, puisque tu n’as pas accès à l’environnement technique de la page. Pour faire ça c’est uniquement quand tu es dans un squelette, comme expliqué plus haut dans la doc de l’insertion squelette qui contient précisément un exemple de ce dont tu parles, qui utilise une valeur dynamique disponible là où on est en train d’insérer le formulaire
Reply to this message
Salut,
je rencontre un bug pour un formulaire dont le résultat est posté par courriel :
Quand je coche dans les configurations des traitements “Masquer les liens d’administration dans le courriel” l’envoi de mail ne se fait pas.
Voila pour le petit report. Si non tout est nickel, merci.
à+
joz
Salut,
je viens de tester et je ne reproduit pas. J’ai reregarder le code correspondant, et je vois vraiment pas ce qui pourrait bloquer à ce niveau là...
version du plugin, de saisies etr de php ?
Reply to this message
Bonjour
J’ai un soucis avec le plugin : la vérification de champs (en front office) ne marche plus. La validation du formulaire se fait même si aucun champ obligatoire n’est rempli.
Du coup, j’ai mis à jour le plugin … et patatra j’ai en plus le même pb que celui énoncé plus bas. Le formulaire existe bien dans les articles où il at été mis mais il « n’existe plus » en BO. Le plugin est vide...
Merci pour votre aide
Paolo
quel était la version ancienne du plugin? quels sont les versions que vous avez aujourd’hui ?quels est la structure de la table spip_formulaires que vous avez? version de spip et de php ? ca veut dire quoi que cela n’existe plus en bo? avez vous des messages dans mysql.log ?
Bonjour
merci pour votre réponse
en même temps que la maj de Formidable, tous les autres plugins ont été mis à jour.
- version ancienne du plugin : comment savoir ???
- version spip actuelle : 3.2.5, version php 7.0
- j’ai mis en PJ une capture d’écran où ce matin apparait aussi un message d’erreur.
où trouver les mysql.log ?...
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=MyISAM DEFAULT CHARSET=utf8;
merci
Paolo
oki, ce n’est pas tout à fait les mêmes erreurs.
As tu une table spip_formulaires_liens. Peux tu donner la stucturre?
Est tu chez ovh?
Que se passe-til si tu repasse par la page de gestion des plugins.
Le les logs mysql se trouve dans tmp/log
j’ai bien une table spip_formulaires_liens :
CREATE TABLE `spip_formulaires_liens` (
`id_formulaire` bigint(21) NOT NULL DEFAULT ’0’,
`id_objet` bigint(21) NOT NULL DEFAULT ’0’,
`objet` varchar(25) NOT NULL DEFAULT ’’
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
je suis bien chez OVH
je suis repassé par la page de gestion des plugins et là miracle j’ai retrouvé mes formulaires dans la page d’admin du plugin...
Par contre j’ai toujours mon problème du départ à savoir la validation du formulaire qui ne fonctionne pas (image en pj)
merci
tu aurais pas la version 4.0.0 du plugin saisies par hasard?
Saisies pour formulaires 3.38.2 - stable
API de vérification 1.10.0 - stable
ouais, donc c’est pas ca.
Bah écoute, envoi moi un export .yaml de ton formulaire, que j’essaie en local...
LE PLUGIN est OK. C’était une erreur humaine pas technique ...
Je m’explique (hum hum)...
ce matin j’ai pris le pb à l’envers... j’ai dupliqué le formulaire en question pour faire des tests et là rapidement je me suis aperçu que mon collègue (néophyte) a rajouté des astérisques sur les labels pour les rendre obligatoires (on ne rigole pas) et n’a donc pas du tout coché la case de validation.... Mais c’est moi qui suit à blâmer, j’aurais dû commencer par vérifier le formulaire et l’erreur humaine possible !!!
Merci MAIEUL pour ton aide et désolé pour ton temps passé.
Paolo
Bon l’essentiel est que cela soit résolu. Mais oui un (*) c’est pas une bonne manière de montrer que c’est obligaoire. Voir http://romy.tetue.net/1289
Reply to this message
Bonjour,
J’ai un souci un peu similaire à une personne plus bas: plus de formulaires listés dans le back-office, par contre le formulaire (il n’y en a qu’un seul) apparait bien sur la page d’édition de l’article qui le contient et sur la page publique ...
Par contre je suis en 3.2.7 et je viens de mettre à jour Formidable en 4.4.6 et je ne peux pas dire si c’était ok ou pas avant mais c’était à jour de pas longtemps auparavant. Quand je vais sur la page qui liste les formulaires existants j’ai une erreur:
Bien sûr j’ai vidé les caches, essayé de créer un second formulaire, désactivé-activé, ... Au vu de l’erreur j’ai exploré et j’ai trouvé ça dans le fichier formulaires.html indiqué dans l’erreur, au tout début:
Je l’ai modifié comme suit:
Juste un retour à la ligne après le ]. Et ça marche ... c’est le “_formulaires” qui semblait venir de la syntaxe de la boucle qui m’a interpellé.
Bug ? pbm de transfert ?
Pierre
c’est franchement étonnant ca oui. Après #SET c’est souvent sensible.
Quoi qu’il en soit, je vais apporter cette modif dans le code. et puis la prochaine version de formidable l’aura.
Merci du signalement.
Ps : peux tu nous indiquer ta version de PHP ?
PHP 7.0.33 c’est un serveur en Debian 9.
Je pense que ça n’a rien à voir avec SET, ni le saut de ligne.
Le fait d’avoir édité le fichier a invalidé le cache PHP Opcache surtout. Si tu remets le fichier comme avant, est-ce que le bug revient ?
Sinon maieul, j’ai cette Notice en php 7.4 : Trying to access array offset on value of type bool in formidable_pipelines.php on line 148
Je viens de faire le test: si je supprime le saut de ligne que j’ai ajouté, j’ai de nouveau l’erreur (j’ai vidé le cache entre-temps).
Ensuite j’ai fait 2-3 allers-retours avec-sans-avec-sans, sans vider le cache, l’erreur revient toujours quand le début de la boucle est collé au crochet fermant. J’ai essayé en mettant un espace, erreur aussi.
Bref ici, en tous cas, ça ne marche que si je reviens à la ligne avant la boucle.
Reply to this message
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
Ajouter un commentaire
Follow the comments:
|
