Formidable, le générateur de formulaires

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

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

Options possible comme troisième argument de #FORMULAIRE_FORMIDABLE
Nom de l’optionFonctionType
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 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

166 discussions

  • 3

    Bonjour,
    Pour info, les champs « Date » pourraient se voir attribuer un placeholder, ce qui pourrait être bien utile notamment pour l’affichage sur mobile (où l’optimisation de l’espace est très important...)
    Merci pour ce formidable plugin et à ses concepteurs !

    • Alors non, le placeholder ne DOIT SURTOUT PAS servir à remplacer le label d’un champ, jamais. Ça n’a aucun rapport en terme sémantique, le label c’est le nom du champ, à quoi il sert, tandis que l’attribut placeholder sert uniquement à donner un exemple de remplissage valide (par exemple « XX/XX/XXX » pour une date). Un champ doit absolument toujours avoir un label.

      En revanche il y est bien dans la saisie « input » et devrait donc être aussi ajouté dans la saisie « date » (et couleur etc toutes les variantes input)

    • Merci RastaPopoulos pour ta réponse rapide,
      Pour autant, si ton conseil est probablement judicieux, il n’est pas très sûr que tu m’aies convaincu. A moins que tu ne proposes une technique pour que le label apparaisse dans le champ de saisie, le placeholder m’apparaît comme une bonne technique pour minimiser la taille des formulaires, notamment pour les mobiles !

    • Je ne vois pas en quoi le placeholder est une solution, l’accessibilité n’est pas une option, pour aucun site. Donc non, jamais ô grand jamais, on ne doit utiliser le placeholder comme remplacement à un label, ça n’a strictement rien à voir.

      Toi tu parles uniquement de style graphique, et éventuellement de comportement javascript (masquer ou déplacer). Donc ça se fait… en CSS et en JS.

      Tu peux très bien t’amuser à positionner ton label à l’intérieur du champ, et à le déplacer en plus petit en haut quand tu cliques dessus (c’est ce que fait Google sur certains de ses forms je crois).

      Par contre c’est très mal de le masquer entièrement quand on est focus dans le champ (ce qui est le cas pour le placeholder aussi), puisque ça signifie qu’une fois dedans… on ne sait plus à quoi sert le champ, ergonomie pourrie.

      Exemple de tutoriel plus accessible (mais il y en a plein d’autres sur le net) :
      https://itnext.io/how-to-build-a-floating-label-input-field-f9b21669fe2f

    Répondre à ce message

  • 7

    Bonjour,
    Petit problème lors du remplissage des champs dans formidable pour les websites multilingues. On peut mettre des chaînes de langue (du genre <:form_oulala :>) mais impossible manifestement de les afficher correctement si on y place des caractères devant ou après la chaîne (du genre <:form_oulala :> oh oui).
    Est-ce un bug ?
    Peut-on corriger ce problème car il est très pénalisant...

    Merci

    • c’est un peu étrange de mettre du contenu avant ou après, puisque ce serait un contenu invariant selon la langue, alors quela chaine de langue est prévu pour le multiling...

    • Salut Maïeul,
      alors là, pas d’accord ;-) le comportement actuel n’est pas appréciable, car on peut vraiment avoir besoin de placer une chaîne de caractère (multilingue) et des paramètres fixes. Ex : liste déroulante -> type : 12h30|<:reservation :> 12h30

    • la version 3.27.2 du plugins saisies corrige cela sur un certain nombre de paramètres des saisies. S’il y en a qui sont encore « bugé », le signaler.

    • Ton explicatio initial était pas clair. J’imaginais que tu pensais aux label, et autres.

      Mais bref. Globalement : faut appliquer un filtre au bon endroit dans chaque squelette de saisie.

    • correction c’est la version 3.27.3 qui résoud le problème.

    • oui, c’est parfait, les chaînes de langue sont reconnues dans les champs, et s’affichent maintenant tout comme il faut, merci bien !!!

    • hum. en fait j’ai pas forcément corrigé de la bonne manière.

      peux tu m’envoyer un export .yaml du formulaire qui marchait pas avant, pour que je comprenne. On va sans doute revenir là dessus en terme d’implementation.

    Répondre à ce message

  • 9

    Bonjour,
    Les formulaires semblent ne pas tenir compte du plugin Timezone. Quelle pratique utiliser pour associer ce paramètre de fuseau horaire au formulaire ?
    En vous remerciant

    • @beno qu’entend tu par « Tenir compte ». Je vois pas où un formulaire serait concerné par le timezone...

    • Bonjour Maïeul,
      Il peut être utile de proposer un décompte horaire à partir du résultat d’un formulaire (prise de RDV par exemple, ou horaire d’exposition pour un show, dans le cas présent).

      Merci Pierre,
      J’ai essayé cette méthode, mais elle ne fonctionne pas sur le site sur lequel j’ai essayé de mettre ça en place (voir https://cutt.ly/6wStiO8 , le décompte est calé sur l’Europe, et non le Laos, c’est ballot...)

    • Il me faudrait un exmeple concret de formulaire formidable faisant ce décompte horaire pour comprendre.

    • Bonjour Maïeul,
      le formulaire a un champs #EVENT_OPEN. qui renseigne sur l’horaire d’un événement. Là dessus, j’ai un compteur qui affiche le temps restant.
      A la base, je cherche à utiliser data-end="[(#EVENT_OPEN|affdate{'Y/m/d H:i:00'})] en tenant compte du décalage horaire (plus 5 heures au Laos, voir la page mentionnée dans mon précédent message), ou bien (plus simple) de retirer les 5 heures à mon #EVENT_OPEN... une idée pour faire cela ?

    • heu... tu est sur que c’est un formulaire formdiable ca :-). C’est pas un bete formulaire cvt ?

      Bref, envoi moi le code de ton formulaire, j’y comprendrais mieux.

    • Et oui, tu as vu juste, pour l’instant c’est un champ extra rempli à partir d’un article, mais je cherche (développement local pour l’instant) à ce que cette fonctionnalité soit proposée par un formulaire via formidable...

    • en tous cas le problème est pas lié à formidable.

      Mais grosso modo, il faudrait utiliser les fonctions de dates et heures de php, qui permettent d’additittoner/soustraire.

    • Merci Maïeul,
      je pensais que cela serait plus facile, mais je me rends compte à quel point ça va être plus compliqué que je ne le pensais... je verrai pour mettre en ligne cette option de formulaire plus tard ;-) Merci encore pour ton aide !

    Répondre à ce message

  • 2

    Je viens ici poster un message qui concerne la partie paiement du formulaire et accessible ici

    Le mapping des champs nom/prénom/adresse en bas de page de configuration des traitements ne fonctionne pas.

    • inutile de poster à 36 endroits....

    • 100% d’accord. Cependant mon précédent post sur le bon forum n’a jamais eu de réponse depuis plusieurs jours et surtout en sachant que la deadline est dans 7 jours

    Répondre à ce message

  • 17

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

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

    • La version 3.37.8 corrige cela.

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

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

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

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

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

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

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

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

      D’avance merci

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

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

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

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

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

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

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

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

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

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

    • bonjour,

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

    • Yes :)

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

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

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

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

    Répondre à ce message

  • 7

    Bonjour à tous
    J’ai un petit soucis de calcul en utilisant des données d’un formulaire.
    Je souhaite faire une moyenne.
    Les info du formulaire sont par exemple :
    Nombre d’objets : ..... Poids moyen de l’objet : ....
    Je souhaite calculer le poids moyen de l’ensemble des objets avec la formule :
    (Nb objets A x Poids moyen A + Nb objets B x Poids moyen B + .....) / (Nb objets A + Nb objets B + ...)

    Pour l’instant, j’ai ce code (qui ne prend pas en compte le nombre d’objets). (Input 1 = poids moyen des objets ; textarea_3 = nombre d’objets)

    #SET{total,0}
    <BOUCLE_reponses(FORMULAIRES_REPONSES){id_formulaire=7}>
    #SET{total,#GET{total}|plus{#VOIR_REPONSE{input_1,brut}}}
    </BOUCLE_reponses>
    [(#GET{total}|div{#TOTAL_BOUCLE}|round{1})]
    </B_reponses>

    Quelqu’un peut-il m’aider s’il plait ?

    • on suppose que input_1 est le poid moyen de l’objet, et input_2 le nombre d’objets.

      Tu dois
      a) calculer le poid total
      b) calculer le nombre total d’objet
      c) calculer poidtotal/nombre_total

      #SET{poids,0}
      #SET{objets,0}
      <BOUCLE_reponses(FORMULAIRES_REPONSES){id_formulaire=7}>
      #SET{poids,#GET{poids}|plus{#VOIR_REPONSE{input_1,brut}|mult{#VOIR_REPONSE{input_2,brut}}}}
      #SET{objets,#GET{objets}|plus{#VOIR_REPONSE{input_2,brut}}}
      </BOUCLE_reponses>
      [(#GET{poifs}|div{#GET{objets}}|round{1})]
      </B_reponses>

      non testé

    • Bonjour
      Je tiens dans un premier temps à vous remercier pour la solution ci dessus qui fonctionne parfaitement.
      Je me trouve dans l’obligation de modifier le code proposé.
      A présent, je dois intégrer une condition dans mon calcul de moyenne.
      Dans le formulaire, l’une des saisies est le type d’objet (ex : fruit, légume, ...) : nom de la variable dans le questionnaire : textarea_1

      Je dois calculer le poids moyens de chaque type d’objet. et l’intégrer dans un tableau du genre première colonne : type d’objet ; seconde colonne : moyenne.
      Comment faire en sachant qu’il y a une 60aine d’objets possible ?

    • Si tu as un textarea, tu laisse libre aux gens de choisir le type d’objet > tu risque d’avoir des doublons du type « fruit » vs « fruits ».

      En tout cas, l’idée est d’utiliser une structure de #ARRAY pour faire les calculs (une entrée de tableau par type d’objet) et une boucle POUR pour afficher le résultat (sous forme de tableau)

    • L’histoire des doublons n’est pas possible car le textarea sera pré rempli.
      Ce qui me pose problème, c’est comment calculer la moyenne de l’ensemble des saisies pour un même produit.
      J’imagine qu’il faut mettre un « si », mais je ne vois pas comment faire.
      Voici le bout de code que j’utilise mais ça ne fonctionne pas :

      <BOUCLE_formidable_id_form2(FORMULAIRES_REPONSES){id_formulaire=13} {si textarea_1|=={fruit}}>
      
      
      
      		<td>#VOIR_REPONSE{textarea_1, valeur_uniquement, '' }</td>
      		<td>#VOIR_REPONSE{input_7, valeur_uniquement, '' }</td>
      		<td>#VOIR_REPONSE{input_1, valeur_uniquement, '' }</td>
      
      
      </BOUCLE_formidable_id_form2>	
    • même prempli, tu n’es pas sur qu’une personne ne modifiera pas la valeur. Il vaudrait mieux proposer une liste déroulante (aussi en terme d’ergonomie).

      Comme expliqué, il faut que tu utiliser un #ARRAY. Tu pourra stocker dans un même tableau (#ARRAY) le poid pour chaque type d’objet, et dans un autre tableau le nombre total d’objet, pour chaque objet.

    • Ok, merci. Je vais tenter ma chance. Pour l’instant, c’est du chinois pour moi.

    • En gros, dans ma réponse sur le cas simple, tu avais deux variables :
      -  une pour stocker le poids total
      -  une pour stocker le nombre total d’objet

      Là le problème est que tu a plusieurs types d’objet. Pour ce faire tu va devoir utiliser des « tableaux » (au sens informatique). Un tableau c’est un type de variable permettant d’associer des clés (ici le type) avec des valeurs (ici le poid total pour l’objet dans une première variable, ou le nombre total d’objet pour la seconde variable).

      En gros tu aura quelque chose du type :

      • poid :
        • Fruit -> 3
        • Legume -> 5
      • objets :
        • Fruit -> 2
        • Legume > 1

      Si tu as 3 fruit pesant 2 kg en tout (!) et 1 légume posant 5 kg en tout (!!!).

      Et concrètement, pour faire cela en SPIP, tu utilise la balise #ARRAY (doc sur programmer.spip.net / spip.net).

      Et à la fin pour l’affichage en tableau (HTML) tu utilisera une boucle POUR permettant de parcours les tableau.

    Répondre à ce message

  • 12

    Bonjour,

    Désolé de cette question de débutant, mais je n’ai pas trouvé moi-même la réponse :
    Le retour de formulaire que je reçois est visiblement en HTML, peu facile à lire (beacoup de lignes vides, pas d’alignement etc) et à exploiter (automatiquement), donc je pense que tout le monde a du modifier ce comportement par défaut ;-)

    J’utilisais avant (pas sous SPIP) un php qui faisait les traitements & verifs puis le POST et j’envoyais simplement en PLAINTEXT la liste des champs remplis (non vides) sous la forme :

    [nom_du_champ] [hor_tab] [Valeur_entrée] [NewLine]
    par exemple :
    Name Franck TOTO
    Email moi@truc.com
    Expert On
    CallMe On

    (et terminé par l’@ IP, mais grâce à RealET, c’est bon maintenant sous formidable)

    Ce qui me permettait facilement d’exploiter manuellement ou d’extraire automatiquement les infos (c’est déjà du CSV tab separated).
    Je suis sûr que c’est possible avec formidable mais j’ai du rater qq chose...

    Merci d’avance !

    • Je ne comprends pas vraiment ce que tu veux faire, et je ne vois pas de quel « retour de formulaire » tu parles. À mon avis, avant Formidable, tu devrais d’abord comprendre, l’API « CVT » des formulaires de SPIP.

    • Je veux juste recevoir un email résultant du remplissage du formulaire qui a la forme (en plain text) décrite ci-dessus. Par exemple :

      Name Franck TOTO
      Email moi@truc.com
      Expert On
      CallMe On

      Ce que je reçois pour l’instant n’a PAS cette forme
      mais (en html) :

      Form « Contact form » sent on 09/09/2016 at 11:24:05.
      From this page.

      Your Name
      Bert75

      Job Function
      CTO

      Company
      My Company

      Address
      (no data entered)
      City
      PARIS

      Zip code
      75000

      Country
      France

      Email address
      moi@hotmail.com

      Telephone
      0123456789

      Interested by :
      Intellectual Property blocks
      Training Coursess
      Design Services
      Your message
      (no data entered)
      — -

    • Bah tu surcharges le squelette d’email pour faire autre chose. Il y a un chapitre juste au-dessus qui parle des squelettes d’email en donnant le chemin…

    • Génial !
      Pile ce qu’il me fallait.
      J’en profiterai pour supprimer les champs vides (totalement inutiles).

    • Sauf que :
      D’une part, le notifications/formulaire_email.html contient un élément totalement obscur (une boite noire qui donne un résultat :

      #VOIR_SAISIES{#ENV*{saisies}, #ENV*{valeurs}}

      Et que d’autre part, le moyen de passer en plain-text le résultat est documenté où ?

    • « pile ce qu’il me fallait » était de l’humour, désolé !

      Et dans les features que j’aurais trouvé intéressantes :
      -  hook d’appel à script à la validation du formulaire
      -  captcha (oui, oui, je sais la religion de spip NOSPAM etc)
      -  insertions de textes custom dans l’email qui en facilite l’exploitation
      -  envoi à destinataire variable en fonction d’un champ
      -  champs conditionnels
      ...mais j’ai peut-être raté d’autres choses dans la doc.

    • Dans traiter/email.php j’ai vu qu’il y avait :

      		$corps = array(
      			'html' => $html,
      			'texte' => $texte,
      			'nom_envoyeur' => filtrer_entites($nom_envoyeur),
      		);

      En tentant de remplacer par :

      		$corps = $texte;

      À ce moment-là, SPIP 3.1 prend le pas et transforme quand même le message en multipart HTML/Txt

      Bref, comment forcer Formidable + SPIP 3.1 à envoyer en text/plain ?

    • Et dans les features que j’aurais trouvé intéressantes :
      -  hook d’appel à script à la validation du formulaire
      -  captcha (oui, oui, je sais la religion de spip NOSPAM etc)
      -  insertions de textes custom dans l’email qui en facilite l’exploitation
      -  envoi à destinataire variable en fonction d’un champ
      -  champs conditionnels
      ...mais j’ai peut-être raté d’autres choses dans la doc.

      Il y a déjà des champs conditionnels. Le captcha tu le codes si ça t’amuse, mais personne n’a envie de ça, la religion du respect des utilisateurices oui on peut dire ça, c’est plutôt une fierté.

      Il n’y a pas de système de choix de destinataires suivant des tests sur d’autres champs arbitraires, par contre il y a déjà une saisie Destinataires qui permet de choisir un ou plusieurs parmi les comptes utilisateurs (s’il s’agit d’autres gens qui ne sont pas déjà dedans, il suffit de créer des comptes sans login, même en statut visiteur peu importe).

      Pour le reste oui tu as oublié des choses dans la doc : tu as oublié la doc générale de l’API CVT de SPIP. Comme déjà dit précédemment. Si tu ne connais pas ça, je vois mal comment tu pourrais espérer modifier des choses complexes dans Formidable spécifiquement ou n’importe quel autre formulaire de SPIP. Il y a déjà tous les points d’entrées qu’il faut, et il y a déjà des sous-plugins qui modifient ou augmentent de manière conséquente Formidable, donc il n’y a à priori aucun problème majeur.

      @RealET, avec Facteur TOUS les emails sont envoyés avec une variante HTML par défaut, et avec une variante texte ensuite, qui dérive de la variante HTML. On pourrait imaginer que la variante texte vienne d’un squelette si il existe et sinon le générer à partir du HTML. Mais dans tous les cas il y aura la variante HTML (et ça vaut pour absolument tous les emails dès qu’on a Facteur). Mais quel est le but final d’absolument vouloir avoir des emails text/plain uniquement ?

    • Pour faire court : SPIP est visiblement complexe, c’est pour ça que je n’ai décidé de l’adopter qu’en m’appuyant entièrement sur RealET pour tout ce qui l’est pas le contenu et l’exploitation du site. Donc ce n’est pas à moi d’apprendre la doc SPIP ni de programmer dans son langage, mais j’essaie quand même d’en comprendre le fonctionnement et de voir si j’ai vraiment besoin pour quelque chose d’apparemment simple (que je faisais moi-même avant) de faire appel à un ou plusieurs spécialistes.
      Il me semblait aussi que la présentation par défaut des emails de soumission (les forms remplis) n’était franchement pas conviviale, ni optimisée (champs vides, interlignes inutiles...), ni facile à exploiter (je ne parle pas de les regarder sur un smartphone !).
      D’où ma question sur ce forum. Ca me semble une amélioration nécessaire. En tous cas SPIP+Formidable -je ne sais pas qui est le coupable original- représente de ce fait une régression pour moi.
      J’espère que RealET va trouver une solution.

    • Bééé, si c’est apparemment si simple d’avoir un système de téléformulaire où on peut construire un form à la souris et pouvoir le modifier quand on veut sans rien coder… c’est super ! :D Go go

      Pour ce qui est de réellement exploiter les résultats, de manière carrée et pérenne, on préférera quand même clairement enregistrer en base et pouvoir exploiter les tables (qui ont même déjà un export CSV dans l’admin…), que des emails qui sont là juste pour notifier, pour des humains.

    • L’affichage compact du mail est intégré : http://zone.spip.org/trac/spip-zone/changeset/99576

      C’est donc désactivé par défaut, et activable via mes_options.php :
      Ajout d’une option pour avoir un affichage compacte et sans les réponses vides (admin & mails de confirmation).
      Dans mes_options.php, rajouter :

      if (!defined('_SAISIES_AFFICHAGE_COMPACT'))
      	define('_SAISIES_AFFICHAGE_COMPACT', 'oui');
    • Merci realET
      Ce code pour compacter le contenu des emails est bien utile et m’évite d’avoir à coder une page formulaire_email.html (le client avait la demande pertinente de réduire le nombre de pages d’impression des réponses).

    Répondre à ce message

  • 1

    Bonjour et bravo pour tout ce boulot,
    J’ai fais un formulaire où il est important (mais ce n’est pas possible de le mettre en obligatoire) d’ajouter une photo de la plaque d’identité du matériel, pour une demande de pièces détachées.

    Pour la présentation du formulaire, je souhaiterais insérer une photo d’exemple avant le champ « Fichier »
    Ne dit-on pas :un petit schéma vaut mieux qu’un long discours !

    Merci de votre intérêt pour ma question, je pense que ça peut servir à d’autres
    Alain

    • En attendant, j’ai simplement inclus dans mon champ explication, de la même façon que dans un article, un doc déjà présents dans ma médiathèque.

      Comme quoi il faut rédiger la question pour y répondre soi-même...

      Mais si il y a une autre solution !!!

    Répondre à ce message

  • 2

    Bonjour,

    Je voudrais rendre permanent le fichier csv des réponses et le générer automatiquement, le rendre accessible de l’extérieur afin de géolocaliser les réponses.

    De même je voudrais déplacer les fichiers téléversés vers IMG par exemple.

    J’avoue patauger sur la méthode malgré mes recherches surtout que je suis un débutant en programmation SPIP.

    Auriez-vous une piste ?
    Cordialement.

    • Concernant le CSV, vous pourriez créer votre squelette qui le générerait.

      Concernant le déplacement vers IMG : c’est une fonction demandée plusieurs fois. Il est clair que pour des raisons de confidentialité, cela restera une option. Il faudrait trouver un peu de temps pour coder cela. Peut être en juin j’en aurait.

    • Merci beaucoup. Je vais suivre cette piste.

      Oui une option avec un avertissement sur le risque est la meilleure solution.
      Merci pour la proposition.

    Répondre à ce message

  • 3

    Bonjour

    Sans que je ne touche à quoi ce soit sur le site ou dans la définition du formulaire, soudainement mon formulaire ne veut plus prendre de réponse : Impossible de prendre en compte votre message. Merci de le soumettre à nouveau !

    • Bon j’ai mis à jour le plugin, qui désormais à besoin de CORBEILLE, JSON, ....
      J’ai effacé le cache
      et cela semble fonctionner :)

    • Le plugin n’a ni besoin de corbeille ni collectionjson, ils sont en « utilise » eux.

    • Pour ce qui concerne ton bug : c’est un bug qui peut se produire en lien avec nospam si tu as trop de #INCLURE imbriqué. Il faut préférer les <INCLURE> lorsque cela aboutit à un formulaire.

      Cf https://contrib.spip.net/NoSPAM#comment501319

    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 :

  • 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
  • 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 apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom