Cette documentation est valable à partir de la version 6.1.0 de Formidable.
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}}Autres options utilisable dans le squelette
Il est possible de passer des options comme troisième argument du formulaire, sous forme de tableau (#ARRAY).
| Nom de l’option | Fonction | Type |
|---|---|---|
forcer_modif |
Permet de forcer la modification d’une réponse, même si non autorisé | Booléen |
id_formulaires_reponses |
Identifiant de la réponse à modifier | Entier |
no_ajax |
Désactiver l’ajax sur le formulaire | Booléen |
traiter_email_destinataires |
Destinataires pour le traitement | Tableau (#ARRAY) d’emails ou liste d’emails séparés par des virgules |
traiter_email_destinataires_methode |
Indique si traiter_email_destinataires doit remplacer les emails déjà configurés dans le traitement ou les ajouter |
Au choix 'remplacer' ou 'ajouter' (valeur par défaut) |
url_redirect |
Url de redirection | Chaine |
Exemple d’un formulaire Formidable dont l’identifiant est contact_libre et dont l’email destinataire est dans le champ email de la table de votre objet #EMAIL de la table spip_contacts ….
<div class="ajax">
#FORMULAIRE_FORMIDABLE{contact_libre,'',#ARRAY{traiter_email_destinataires,#EMAIL}}
</div>Case unique
Pour rendre obligatoire la réponse oui à une 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é
811 discussions
Bonjour, depuis ce matin, j’ai ce message sur la page d’administration du formulaire
ainsi que sur la page publiée. j’ai vidé le cache etc ... et
Warning : in_array() expects parameter 2 to be array, null given in /homepages/4/d316519483/htdocs/tmp/cache/skel/html_1c4991a39b8d3f9182a70667674d7e32.php on line 78
Merci de votre réponse
Version SPIP 3.2.1 [23954]
La version 2.25.0 du plugins saisies posait ce problème.
La version 2.25.1 qui vient juste d’être envoyé sur la zone le corrige. Il sera disponible en zip vers 16h15, et en mise à jour automatique dans l’espace privé vers 18h15.
Cela étant quand tu as des choses qui arrive comme cela du jour au lendemain, il est bon d’indiquer les modifications que tu avais fait peut avant. En l’occurence j’imagine une mise à jour de plugin.
Je dirais qu’une info aurait été aussi bien sur les maj des plugins utilisés et des fois en incompatibilité « d’humeur » ! Oui en effet j’ai fait toutes les maj ce matin ... En tout cas merci pour ta réponse rapide qui servira à d’autres surement !!
Passage en >> Saisies pour formulaires 2.25.1 - stable = OK nickel merci Maïeul !
Répondre à ce message
Bonjour, existe-t-il un moyen d’ajouter un captcha à formidable ? Si oui, comment procéder ? Cela serait utile pour lutter contre le spam, même si certains trouvent la solution trop « dure ». Merci à vous.
Non, pour lutter contre le spam on met le plugin nospam, et on ne gène pas les utilisateurices qui n’ont rien demandé. :)
Répondre à ce message
Bonjour,
Comment remplacer « (obligatoire) » par une « * » dans le label des champs obligatoires ?
Merci d’avance,
Cordialement,
Hervé
Une étoile ça ne signifie rien, ce n’est pas bien pour l’accessibilité. Mais tu peux très bien changer et faire ce que tu veux en CSS, puisque c’est ciblable dans « label .obligatoire ». Donc tu peux masquer accessiblement le texte et mettre autre chose à la place.
Merci pour ta réponse.
Mais, n’est-il pas possible de garder l’accessibilité tout en changeant l’affichage ?
Avec quelque chose du type :
<span class="obligatoire" alt="obligatoire"> *</span>Merci d’avance,
Cordialement,
Hervé
j’ajoute ceci à mon commentaire précédent et qui est tiré du code du formulaire de commentaire du site « https://www.accede-web.com » :
_ 7.4. Intégrer required ou aria-required=« true » dans les champs obligatoires
Les champs obligatoires doivent intégrer required ou aria-required=« true ».
Répondre à ce message
Question bête : sur la pagre d’édition d’un article ?exec=article&id_article=1 je vois :
« Il n’y a pour l’instant aucun formulaire. »
Je clique sur « Ajouter un formulaire »
J’en choisi un et je clique sur « ajouter ce formulaire »
Et après.. il ne se passe rien.
Lorsque je vais sur la page ?exec=article_edit&id_article=1 il y a bien à gauche
« Formulaire utilisé : Liste des livres » avec un lien vers le formulaire.
Est- qu’il est supposé ajouter ce formulaire via un modèle dans le texte de l’article ? Est-ce qu’il faut ajouter un plugin pour l’insertion de formulaires ?
Est-ce qu’il faut modifier le squelette ?
Merci
dd
normalement si tu insère le formulaire via le modèle dans le texte de l’article suffit.
OK mais je ne vois pas le modèle ; Est-ce qu’il faut installer le plugin « insertion de modèle » ou similaire ?
Parce que je ne vois pas, si l’insertion est manuelle, l’intérêt d’avoir un lien sur « Ajouter un formulaire » et sur « ajouter ce formulaire » qui ne fonctionnent pas.
dd
Je ne comprend pas le problème. Je n’ai aucun lien « Il n’y a pour l’instant aucun formulaire »
Répondre à ce message
Bonjour,
J’utilise Formidable depuis un moment et j’ai modifié récemment mon formulaire.
J’ai maintenant 6 messages d’erreur qui apparaissent :
J’ai beaucoup de mal à comprendre le code. Il s’agit du bloc test :
La ligne 124 est « and isset($labels_data[$valeurs[$champ]]) »
Mais c’est quoi « une liste de choix avec des clés et labels humains » ?
Un grand merci pour ce greffon indispensable !
Bien cordialement,
Répondre à ce message
Avec SPIP2.1, Formidable n’est pas compatible avec le plugin Bandeau (qui surcharge prive/javascript/gadget.js). Et même en enlevant Bandeau, je ne suis pas parvenu à le faire marcher.
Avec SPIP 3.1, il est indiqué pour la saisie de l’
Affichage résumé de la réponse: « Cette chaîne sera utilisée pour afficher un résumé de chaque réponse dans les listes. Les champs comme @input_1@ seront remplacés comme indiqué par l’aide mémoire ci-contre. » mais où est cet aide mémoire ?A gauche de la page. Mais attention, si tu viens juste de créer les champs, ils n’apparaissent pas.
Oui c’était ça !
Répondre à ce message
Bonjour,
Afin d’améliorer l’accessibilité de mon site, je souhaiterais mettre en place le fonctionnement suivant :
Lorsque le formulaire est envoyé, en complément des messages (message_ok ou message_erreur) qui apparaissent dans la page, j’aurais voulu donner directement l’information de succès ou échec directement dans le titre de ma page.
Ex :
<title>Confirmation d'envoie - Nous contacter </title>ou
<title>Erreur de saisie - Nous contacter </title>Malheureusement quand je suis dans mon squelette, les valeurs des variables #ENV*message_ok et #ENV*message_erreur (utilisées dans le formulaire) semblent inconnues. Comment dois-je donc procéder ?
Merci par avance pour vos retours.
Julie
Salut, il n’y a rien qui permette de faire cela dans tous les formulaires de SPIP, que ce soit Formidable ou n’importe quels autres formulaires (d’édition de contenu, de contact ou autre).
Il peut très bien y avoir plusieurs formulaires dans la même page et les choses sont cloisonnés. C’est seulement dans le formulaire qu’on accède aux retours de lui-même. À l’extérieur, dans un squelette, il n’y a rien qui permette de récupérer cela.
Il faudrait peut-être que tu ouvres un ticket de bug accessibilité sur les tickets de SPIP pour signaler cela et demander à ce que SPIP permette d’avoir de manière globale (dans les squelettes) des infos sur le formulaire posté s’il y en a eu un.
https://core.spip.net/projects/spip/issues/new
(il faut avoir un compte)
Hop je l’ai fait en fait :)
https://core.spip.net/issues/4111
Merci !!!
Répondre à ce message
Bonjour,
La page de réponse de mon formulaire ne se charge pas complètement (que je choisisse l’option « Afficher le formulaire à nouveau » ou « Afficher les valeurs saisies ») et j’ai le message suivant :
Warning : Illegal offset type in /homepages/45/xxxxxxxxxxx/htdocs/plugins/auto/formidable/v3.6.1/traiter/email.php on line 120
J’ignore depuis combien de temps il y a ce bug, j’ai été alertée par une même demande reçue 3 fois parce que la personne a pensé que son formulaire n’avait pas été traité correctement.
Je viens de passer de la v3.6.0 à la v3.6.1, le Warning est toujours présent.
Merci pour votre attention.
Répondre à ce message
Bonjour,
Il me semble que je suis confronté à une incohérence d’affichage dans l’admin des formulaires. Les réponses formulaires enregistrées en base de données ne correspondent pas toujours à ce qui s’affiche dans la page administration du formulaire (page Réponse de formulaire).
Le formulaire est correctement saisi puis enregistré, les accusés réception sont transmis correctement avec toutes les infos saisies correctement, tout va bien....
Pourtant, dans l’admin de spip, un champ obligatoire apparaît comme étant *sans réponse*. En allant regarder dans la base de données, je constate qu’il y a bien une valeur pour ce champs obligatoire et que cette valeur correspond à celle qui a été transmise par mail d’accusé réception. Mais l’admin de spip indique toujours *sans réponse*.
Le problème est que lorsque j’exporte les réponses, je me retrouve avec des *sans réponse* sur des champs obligatoires dans mon tableau et ça complique mes traitements.
Ai-je mal fait ou mal compris quelque chose ?
Merci pour votre éclairage.
C’est typiquement un bug si c’est en base donnée, mais je suis étonné de cela.
En tous cas je n’ai jamais rencontré ce problème.
Il faudrait que tu m’envoie un dump sql du formulaire + de la réponse qui pose problème pour voir précisement le souci.
Voilà l’export Yaml
Voilà l’export sql
C’est pour la liste_déroulante_1 (Choix du premier atelier) que cela est le plus flagrant mais cela arrive aussi pour les autres listes déroulantes. Je pense que cela se produit quand l’internaute hésite et tergiverse avant de valider son choix.
Dans la base de données tout est cohérent.
Merci d’avance.
Je vois pas en quoi l’hésitation pourrait expliquer cela. L’affichage du champ se fait à un moment où il n’y a plus que l’info en BDD, pas d’autre informations sur les hesitations avant l’envoi du formulaire
L’hésitation pourrait peut-être créer une confusion dans les traitements du plugin car il existe un lien conditionnel entre les champs. Certaines listes déroulantes apparaissent ou disparaissent en fonction de la valeur saisie dans la liste déroulante précédente.
Je ne sais pas si ce que je dis est clair...
si la donnée est stokée ne base, le problème se pose au momenz de l’affichage.
Mais je me demande si Rastapopoulos, qui a fait un commit est sur le coup ou pas.
Non du tout, moi j’essayais de refaire marcher le afficher_si sur une explication, mais pas réussi (elle se masque pas)
Re,
Après enquête, il me semble que c’est parce que la valeur à afficher qui correspond à la « clé » de l’élément de la liste contient trop de caractères.
Si
#ENV*{valeurs/selection_1}c’est la clé de de l’élément sélectionné de selection_1, puis-je savoir comment on manipule le label correspondant à cette clé ?Pour contourner le problème, c’est le label que je vais afficher dans le mail d’accusé réception, ce qui me permettra de réduire la longueur de la clé.
Merci.
Pas compris le problème, mais à mon avis il faut le résoudre et pas le contourner.
Merci pour ta réponse.
Du coup tu pourrais m’expliquer un peu mieux ce que tu detecte comme le problème ?
Une liste déroulante se configure avec une clé et un label
Le label est affiché aux visiteurs de l’espace public.
La clé est envoyée dans le mail d’accusé réception en mettant
#ENV*{valeurs/selection_1}dans le squelette du courriel.Parfois ça impose de créer une clé très longue... Je suppose que c’est cette trop longue clé qui ne s’affiche pas correctement dans l’espace privé de spip. Même quand tout est bien enregistré dans la base de données et que le mail a été parfaitement généré, transmis et reçu.
Je propose donc de transmettre le label dans le mail (au lieu de la clé), ce qui permettrait de réduire la longueur de la clé qui pourrait, de fait, s’afficher correctement dans l’espace privé de SPIP. Comment donc afficher ce Label ?
Une clé n’est pas censé contenir 450 caractères. Mais tu as raison, il faudra bien corriger le problème plutôt que le contourner.
Bon, il y a plusieurs problèmes du coup
1. Effectivement ce n’est pas une bonne chose d’avoir une clef à rallonge, qui se comporte comme un label. Surtout avec des espaces / accents. Cela étant, avec l’exemple que tu fournis de data, je n’obtiens pas ton problème. Mais peut être modifie tu aussi les infos de l’espace privé ?
2. Je ne savais pas que tu avais modifié ton mail de validation. Je n’ai pas l’impression qu’il y ait de fonctions qui donne directement le label d’après la valeur, surtout qu’en l’espace les informations sont explosés entre un tableau donnant la description des saisies et un autre donnant les informations . En general on utilise la vue de la saisie pour générer l’affichage. Il faudrait peut être créer uen fonction ad hoc, mais je préfère l’avis de Rastapopoulos avant de me lancer dans une enieme fonction de saisies.
:-\ En effet, je ne suis pas sûr qu’il faille se lancer dans plein de nouveaux développements juste pour ça...
Le plugin accepte et gère très bien les clés contenant des espaces, des accents, des apostrophes,... c’est déjà remarquable !
Et bien merci quand même. Je vais plutôt essayer de raccourcir mes labels !
@+
Euh il gère les accents etc, bah oui comme tout array PHP, mais ce n’est pas DU TOUT fait pour ça. À aucun moment la clé n’a signifié « c’est pour l’email », et l’autre pour le site.
Une clé, c’est une clé, c’est un truc *technique* qui sert à la retrouver et à l’utiliser informatiquement. Pas du tout pour les humains (sauf dans des tableurs CSV etc mais c’est au final aussi pour faire du traitement).
Donc quand on veut la valeur bah faut aller chercher la valeur. Il me semblait qu’il y aviat un truc pour ça avec les vues, mais là tout de suite de tête je ne me rappelle plus de toutes les balises et fonctions disponibles.
Dommage... C’est exactement ce que je cherche : le « truc » qui permet de récupérer la valeur...
Je vais chercher dans le squelette du mail de notification par défaut...
Si les clés longues s’affichaient bien dans l’espace privé, tout ça serait passé complètement inaperçu.
Merci en tout cas pour le plugin et pour vos réponses. @+
Répondre à ce message
Salut, En développant mon site afin d’ajuster des modifications j’ai changé le numéro d’un formulaire soumis dans la base de donnée puis je l’ai supprimé. Malheureusement avant de la supprimer j’avais dû renommer son ID (si j’avais su !!). Depuis chaque nouveau formulaire conservé dans la BDD s’incrémente avec le numéro suivant celui de la correction et ainsi de suite. Pourtant j’a tout nettoyé dans la BDD pour retomber juste. Mais rien à faire.
Pourriez vous me dire comment est trouvé le dernier numéro de formulaire pour soumettre un nouveau ? je n’ai pas l’impression que ça soit dans la BDD
Je ne suis pas sûr de tout comprendre, mais il y a une règle de base en base de donnée : lorsqu’on a un identifiant numérique qui s’autoincrémente, on ne le modifie pas.
J’avoue ne pas comprendre non plus en quoi cela pose problème d’avoir un trou dans les numéros de formulaire.
Enfin oui, c’est bien en base de donnée que c’est géré, pas en SPIP. La base mysql ou sqlite contient un paramètre interne pour chaque champ auto incrémenté donnant le dernier numéro d’incrément. Tu peux l’avoir par exemple en executant
SHOW TABLE STATUSdans phpmyadmin. Quand à modifier, je ne sais pas le faire et surtout je ne le conseille pas.Salut Alex. Si tu as accès à phpMyAdmin,
1./ tu vas dans l’onglet opération de ta table
2./ Dans table options, tu remets AUTO_INCREMENT à 0
( Attention à bien supprimer toutes les entrées des anciens formulaire dans toutes les tables qui commencent par « spip_formulaire » )
Oui oui je reconnais que j’ai fait un peu n’imp. je m’en suis finalement sorti. Non pas en modifiant quoi que ce soit dans la BDD mais bien en changeant ma méthode, qui est bien plus efficace et pertinente à présent. merci pour ta réponse et désolé du dérangement.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
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.
Suivre les commentaires :
|
