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 :

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

  1. #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.

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

  1. 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 14 January 2020

Discussion

694 discussions

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

    Reply to this message

  • 3

    Bonjour à tous,

    Je viens de mettre en ligne mon formulaire et je me rend compte que l’affichage est différent. Pas de contour gris pour les titres. Chaque choix sont à la ligne. Bref je n’ai aucune mise en forme tout est en brut à la ligne.
    Si je fais f12 j’ai une erreur : bulles_blanches.png

    • Ce plugin ne s’occupe d’absolument rien de graphique, il ne fait que générer des formulaires en suivant la norme de structuration des formulaires de SPIP. Après c’est à ton thème graphique de styler les formulaires.

    • ok et le thème graphique est géré ou ?
      Désolé mais cette question qui peut paraître simple mais je viens de récupérer la gestion du site et je ne connais du tout le fonctionnement de SPIP :)

    • Les thème graphiques sont la plupart du temps livrés avec le squelette (mais par fois c’est différent).

      Celui-ci peut être distribué/installé de manières différentes, selon l’historicité de ton site et la capacité de la personne qui le gérait avant. Mais en gros
      1. Soit c’est un plugin qui est installé
      2. Soit c’est un contenu dans le dossier squelettes

      La vrai question qui se pose est : quelle indication faut-il te donner pour t’aider. Connus tu un peu de HTML/CSS ?
      Et surtout pour nous aider à t’aider, un lien serait bienvenu.

    Reply to this message

  • 9
    EtienneJ

    Grand merci pour les dernières modifications : la fonctionnalité de modification des réponses est vraiment très utile pour traiter et suivre la relation aux internautes (il semble que cette fonctionnalité vienne juste d’être ajoutée ?). Il reste semble-t-il toutefois une incompatibilité suite à ces derniers développements, avec l’extension de duplication des formulaires (je ne sais pas si vous l’avez remarqué).

    Une future évolution qui serait également extraordinaire (sauf çà ce que ce soit moi qui ne sache pas faire en l’état de l’extension), serait de pouvoir envoyer par publipostage courriel des formulaires avec certains champs préremplis par des informations des inscrits aux listes de diffusion (nom, courriel). Là, nous toucherions à la perfection en matière d’outil de personnalisation de la relation !

    • Je n’ai compris ni le problème sur la duplication, ni la demande d’évolution

    • EtienneJ

      Pour la compatibilité, le message de l’interface privée est :
      “Impossible d’activer le plugin ../plugins/auto/formifusion/v1.0.7
      Nécessite le plugin FORMIDABLE en version ≤ 3.*.*.”

      Pour l’évolution suggérée : Il s’agirait par exemple d’envoyer des courriels contenant un formulaire où l’adresse courriel ne serait plus à saisir, puisque cette information serait déjà préremplie avec l’adresse de destination du courriel, ce qui fait moins de saisie au destinataire.
      Cela permettrait par exemple aussi de s’adresser à lui par son prénom, puisque nous pourrions afficher ce prénom dans une phrase inscrite dans un champ descriptif du formulaire.

    • Il s’agit de l’extension de fusion, pas de duplication de formulaire. C’est lié au changement de numéro de version dans formidable (qui implique spip 3.1 minimum désormais). J’ai modifié le plugin formidable_fusion pour dire qu’il est compatible avec la version 4.0.0. La nouvelle version sera disponible sous peu.

      je ne comprend toujour pas le besoin. Il s’agit d’envoyer un lien vers un formulaire pre rempli ? ou bien de proposer de répondre par courriel avec des valeurs pré rempli. C’est vraiment pas clair du tout le besoin...

    • EtienneJ

      Il s’agit effectivement de proposer de répondre par courriel avec des valeurs pré-remplies (cela l’extension Formidable le propose déjà pour une valeur fixe en dur), mais paramétrable en fonction du destinataire du courriel (la valeur pré-remplie s’adapte à l’adresse courriel et au nom de l’inscrit à la lettre de diffusion qui reçoit le courriel).

    • Je n’y connais rien en terme de publipostage, mais dans tous les cas je commencerais par regarder du coté des outils de newlettrer de spip. Quoi qu’il en soit, je n’aurais pas le temps de dévelloper un tel outil.

    • EtienneJ

      Merci.

      Je vous précise quand même en regardant votre travail, que vous avez déjà fait ce type de développement avec l’extension “Formidable : abonnements à des listes de diffusion”, pour les inscriptions par Mailsubscribers. En effet, vous savez dans cette extension alimenter @email@ et @nom@ dans les inscriptions aux listes.

      Pour la fonctionnalité que je propose, il “suffirait” (je sais, c’est plus facile à dire qu’à faire :-) de faire le chemin inverse : comme les variables @email@ et @nom@ sont déjà récupérables dans chaque courriel envoyé par liste de diffusion (ces variables affichent leur valeur lorsqu’elles sont insérées dans le corps d’une infolettre), il faudrait juste que les formulaires Formidables acceptent également de les interpréter (balise spécifique ?), lorsque le formulaire est édité dans le corps d’un publipostage.
      Note : J’ai bien essayé en l’état mais cela ne fonctionne pas, car @email@ mis en valeur par défaut dans un champ de formulaires Formidables s’affiche alors ’@email@’ dans le courriel, et non par la valeur qui correspond au destinataire de l’infolettre.

      Bonne journée !

    • lorsque le formulaire est édité dans le corps d’un publipostage

      On est d’accord que cette phrase ne veut rien dire ? À aucun moment un formulaire ne peut être utilisé dans un email…

      Moi je n’ai toujours pas compris ce que tu cherches à faire (“répondre par courriel” ? là non plus ça ne veut rien dire, à quel moment on peut répondre à un formulaire par courriel ?)

    • EteinneJ

      RastaPopoulos,

      Bah si : essaye d’insérer ta balise de formulaire formidable (

      ) dans une infolettre, tu verras que les destinataires reçoivent un message qui contient le formulaire :-)

      Amicalement.

    • Ce n’est pas parce que tu le vois que ça peut MARCHER. Je le répète : à aucun moment un formulaire, censé être lié à des comportements PHP sur le serveur, ne peut marcher dans ton client email qui n’a RIEN à voir avec le serveur. Par ailleurs, ce n’est même pas forcément visible, car chacun reçoit les emails comme il le désire, et on peut très bien dire qu’on ne veut voir que les emails en mode texte, donc non le formulaire ne s’affiche même pas dans ce cas. Les emails c’est juste de la lecture.

    Reply to this message

  • 3

    Bonjour ,
    j’ai un soucis avec un champs type “grille de questions” : les cases cochées ne sont pas transmises (ni sauvées) (versions SPIP 3.2.5 [24404], formidable 3.47 et 48).
    Et si on met ce champ “obligatoire”, l’utilisateur ne peut pas envoyer son formulaire.

    Sans doute lié, il est mis dans l’onglet “utilisation” que :
    Vous devez indiquez un choix par ligne sous la forme “cle|Label du choix”
    et si je mets des ’"’ en fin de ligne, ils apparaissent à l’écran. (voir copie écran.
    merci de votre aide.

    • il ne faut pas mettre de guillemet (ni en fin, ni en début de ligne). de plus évitez les virgules et espaces dans vos clès, mettre plutot des _ si vous devez séparer les choses.

    • Merci Maieul et bonne année !
      Cela marche parfaitement avec ces explications.
      Je suggère de mettre dans la prochaine version de l’explication de l’onglet « utilisation » , corrigeant la terminaison aussi de ’indiquer’ (’z’ au lieu de ’r’) sur toutes les explications en passant:
      Vous devez indiquer un choix par ligne sous la forme : cle_sans espaces|Label du choix
      William

    • bah heu non, les guillemets par définition indiquent une citation, donc on n’est pas censé les reprendre

    Reply to this message

  • 7

    J’ai un problème persistant : je coche sur la page ?exec=formulaire_edit&id_formulaire=2&configurer=traitements
    Effacer régulièrement les résultats les plus anciens
    et j’indique un nombre de jours ex 160 pour “Nombre de jours avant effacement”

    mais cela n’est pas pris en compte. Je suis obligée d’aller effacer les enregistrements dans la base et les fichiers joints sur le serveur (là par exemple j’ai 8 mois de réponse alors que je veux que les plus récentes de 160 jours.

    Les réponses sont toutes à “proposées” car n’ont pas vocation à être publiques
    Plugins à jour avec SPIP 3.2.7 [24473]

    Merci

    • très étrange, il n’y a pas de raison que cela ne fonctionne pas. Peux tu me dire si dans “liste des travaux” (menu maintenance) tu a bien une tache “formidable_effacer_enregistrements” et qu’est-ce qu’il se passe si tu l’applique manuellement. Par ailleurs as tu des messages de logs PHP (niveau serveur) ?

      (ps : tu peux aussi mettre les réponses à la corbeille, elles sont supprimées au bout de 24h)

    • Merci pour ta réponse rapide.
      J’ai lancé les travaux du cron mais cela n’efface rien.
      Je ne trouve pas de error.log

      Je vais effacer les anciens enregistrements dans la base directement (il y en a plusieurs centaines).

    • non, efface les en mettant à la poubelle, pas directement dans la base, cela permet de s’assurer de la cohérence.

      Du reste, si il y a un bug, il faut le résoudre. Peux tu m’envoyer l’export yaml de ton formulaire? Peux tu activer temporairemnet l’affichage des erreurs et des warnings, puis faire un test par cron?

    • Mon yaml est là : https://framadrop.org/r/ByvTk_R_DF#+6/orTBBZzRfcfcdrb/ikA+4//CyW0zxtXkCxoTkDnQ=

      Peux-tu me dire quel fichier de log je dois regarder ?
      J’ai par exemple dans dans jq.log :

      debug         
          Fichier : ecrire/inc/queue.php
          Ligne : 401
          Fonction : queue_schedule()
          JQ schedule end time 1578320489

      et

      debug         
          Fichier : ecrire/inc/utils.php
          Ligne : 1010
          Fonction : cron()
          cron !
    • HUM. En tout cas chez moi ca marche. Moi il me faudrait les logs de PHP. En gros on dirait qu’il y a un bug au niveau PHP, donc ces là que cela doit être logué. Eventuellement les logs sql.log.

      Tu est en mysql ou sqlite ?

    • J’ai réussi : il y avait quelques réponses isolées de plus d’un an qui étaient toujours en base. Je les ai supprimées à la mano et maintenant le cron supprime bien les réponses de plus de 6 mois. Il devait y avoir un blocage quelque part.
      Merci

    • j’avoue mal comprendre pourquoi des vieilles réponses bloquait le cron qui se contentait de faire un requete sql. Mais l’essentiel est que cela soit résolu

    Reply to this message

  • 10
    Bertrand

    Bonjour

    Lors de l’utilisation d’un formulaire qui récupèrent les réponses à un sondage pour des paniers de légumes, les adhérents donnent un minimum de renseignements nom/courriel/type de panier.
    Or je m’aperçois que dans l’interface d’administration seul les noms (+liens) des auteurs du site apparaissent dans le récapitulatif des réponses (cf copie écran), les autres réponses restent sans nom … il faut cliquer sur la réponse pour accéder à toutes les infos dont le nom.
    Est ce normal ? ou j’ai omis de paramétrer quelque chose ?

    Grand merci pour ce petit bijou de plug-in
    Bertrand

    • Oui c’est normal : Formidable ne peut pas deviner tout seuls les champs pertinent à afficher.

      Mais lors de la configuration de l’enregistrement, tu peux définir une option “affichage résumé de la réponse” pour dire quel champ afficher ici.

    • Bertrand

      Génial !
      Exactement ce que je voulais ! On peut même combiner plusieurs champs :-)
      C’est le champ utilisateur/adresse IP qui me posait problème et que je cherchais à modifier. Je n’avais pas vu la subtilité “Affichage résumé de la réponse”.

      Merci encore

      PS : j’ai l’impression que j’ai un bug d’affichage ou bien c’est dans le plug-in ? (voir copie d’écran)
      Dans l’écran de Configurer les traitements, la tête de chapitre Enregistrer les résultats est en dessous des réglages …

    • c’est plus ou moins un bug d’affichage, ca depend comment on voit les choses.

      la flèche point le legend du fieldset, alors que le cercle entoure le pseudo label de la case. Du coup on a l’impression qul’info est dupliqué, alors qu’en fait nom. Il faudrait plutot supprimer ce qui est entouré dans le cercle, qui n’a guère de sens en terme d’accessibilité

    • Bertrand

      Ben OK sauf que tout le reste du formulaire utilise une nomenclature ; tête de chapitre, puis réglages… donc ça me paraissait logique sauf là :-)
      Bertrand

    • ca se discute. L’idée est qu’on choisi les traitement, puis on les règles, ce qui n’est pas le cas ailleurs. Techniquement on pourrait faire ainsi, mais c’est pas si simple.

    • ouais, ce serait possible, mais ca impliquerait une migration de la structure du formulaire et des données + des tests qui en découle. Bref un sacré sac de nœud avec des risques de bugs potentiels pour une plus value limitée.

    • Faut bien comprendre qu’il y a 2 étapes
      1) le choix du traitement (ce que tu tappel “réglage”)
      2) le réglage du traitement (ce qui amène une “tete de chapitre” a apparaite, si le traitement est coché)

      Si je supprime ce qui est entouré en cercle, ca fait bizarre parce qu’on a des label hyper long. Si je déplace la case à cocher sous la “tete de chapitre”, faut beaucoup de code pour ne pas afficher la suite des résultats. Bref, pas convaincu et pas envie de passer du temps sur ca.

    • Comme tu dis le faux label qui n’est pas de la case ne sert à rien. On pourrait l’enlever et mettre “pleine_largeur” sur la saisie, et du coup sans marge inutile sur le côté gauche. Et du coup aussi enlever la marge gauche non standard qu’il y a sur “.option_traiter”. Après avoir fait ça, pour mieux distinguer les lignes des traitements racines (les deux cases à cocher de base du départ), il faudrait peut-être les mettre avec un fond d’une autre couleur, un truc comme ça…

      Cf capture. Je ne dis pas que c’est avec cette couleur qu’il faudrait mettre (et sans bordure je pense, juste le background), mais sur le principe, ça permet de bien mettre en avant du premier coup d’œil les choix “racines”, de leur configuration respective, sans ajouter d’encadrement de partout (c’est mal, fuck les bordures et cadres partout).

    • oui j’avais testé d’enlever le faux label, mais j’était pas hyper convaincu en terme de rendu. Tu veux que je commite et que tu complète avec ta couleur ?

    Reply to this message

  • 3

    Bonjour,
    je viens de faire la mise à jour de spip, version : SPIP 3.2.7 [24473]
    ainsi que celles des plugins qui le nécessitait, dont “Formidable” version : Formidable 3.46.8
    Il y a un message “Erreur dans les plugins :” concernant plugins/auto/formidable/v3.46.7/formidable_pipelines.php !
    Pas plus de précisions, je viens de tester un formulaire et j’ai bien les élements envoyés, c’est donc pour info !!!
    Il me reste à trouver comment supprimer le message ?

    Encore bravo pour tout ce travail
    AlainF

    Reply to this message

  • 21

    Bonjour,

    J’aimerai savoir si avec Formidable on peut créer un formulaire comme ce qui suit.

    À vrai dire, j’ai déjà créé le formulaire que je souhaite avec l’aide d’un intervenant du forum spip. Mais celui-ci ne fonctionne pas comme attendu.
    Il est visible ici : https://www.the-ghost-bassist.com/bootsy-collins-i-m-leavin-u
    Vous pouvez le tester avec toto@free.fr

    Il s’agit pour les visiteurs de remplir quelques champs pour voir apparaître une ligne lui permettant de télécharger un fichier (zip ou RAR).
    L’admin lui, devrait recevoir une alerte mail lui indiquant le nom du fichier télécharger, le nom et email du visiteur.

    Est ce possible !?

    Merci

    Chrys

    • Mince !
      Pas de piste pour ce type de formulaire ?

      Merci

    • bah ... je sais pas. Il s’agit d’un bete formulaire formidable. Je vois pas où tu éprouve une difficulté.

    • ah ! tu veux que les gens recoivent un fichier, et pas qu’ils l’envoie.

      formidable n’est pas fait pour cela. Tu pourrais créer ton propre formulaire cvt. Ou bien “tricher” : dans la la réponse envoyé au moment où une personne poste un formulaire, tu pourrais mettre un lien vers le fichier à telecharger.

    • Merci pour ta réponse,

      Oui c’est ce que j’ai tenté avec le binôme de fichier HTML et PHP en CVT.
      Visible à l’adresse sur mon ancien post.

      Mais cela ne fonctionne pas comme attendu.

    • Bah du coup
      1) ca concerne pas spécifiquement formidable, donc tu devrais plutot poser ta question sur la liste des utilisateur de spip
      2) sans code impossible de savoir pourquoi ca marche pas.

    • Oui ! je peux mettre les codes ici ?
      Bien que ça ne concerne pas Formidable ?

    • le mieux serait vraiment de demander sur la liste https://listes.rezo.net/mailman/listinfo/spip/
      ou bien passer sur l’irc irc.spip.net

    • Biensur, d’accord et merci :-)

    • Changelog.

      Bonjour,

      Quand une nouvelle version est publiée, je cherche souvent ce qui a été modifié. Serait-il possible d’avoir un fichier ou un paragraphe de changelog quelque part avec un minimum d’explication des changements ?

      Par exemple : je vois que la mise à jour recenté crée une dépendance avec NoSpam. En l’indiquant dans le changelog, on ne serait pas surpris et on ne suspecterait pas une faille.

      Merci en tout cas de cette extension très utile.

    • Bonjour,

      A droite de cette page, comme tout les plugins, tu as un lien vers le “Code source” ce qui te donne les informations de commit.

      C’est ce que tu cherches ?

    • Oui et non. Je recherche un résumé, si possible commenté, des changements comme on le voit dans les fichiers changelog des logiciels libres. Si c’est possible bien sûr.

    • C’est une politique qui n’a jamais été prise dans les plugins spip, mais c’est vrai qu’idéalement il faudrait.

      La dépendance à NoSPam a été mise pour éviter que des gens passent leurs temps à nous demander de mettre un anti spam. Rien à voir avec la sécurité.

    • Bonjour @Maïel,

      J’aimerai tester, en utilisant ton astuce en « Trichant » ;-)

      Comment puis je trouver les fichiers d’un formulaire perso fais dans formidable, afin de modifier l’alerte de réponse ?

      Merci

    • quand tu configure ton formulaire formidable, et notamment l’envoi de mail, tu peux definir le message de retour...

    • Oui, mais j’aimerai si cela est possible, y mettre une boucle spip (documents) pour compléter mon idée de base.

      Est ce possible ?

    • J’avais pas compris.

      Oui c’est possible. Cf le paragraphe “Courriels de notification” du présent article...

    • Merci je regarde de ce coté :-)

    • Merci Maïeul,

      J’ai suivi toutes les informations de l’article au-dessus.
      J’arrive a quelque chose de pas trop mal, il me reste une chose a réglé, et a moi le bol de sangria :-)

      Donc.
      Je charge un fichier (rar ou zip) dans certains de mes articles, en faisant un formulaire avec formidable je demande au visiteur leur nom et email. Une fois les champs renseignés, ils valident et reçoivent un mail avec le lien de chargement du dit fichier.

      Voici la boucle que j’ai mis dans mon fichier de notification :
      formulaire_download_accuse.html

      <BOUCLE_download(DOCUMENTS){extension==zip|rar}{mode=document}{doublons}>
      	Bonjour,	
      	<br />Télécharger votre fichier en cliquant sur ce lien :
      	<br /><a href="#URL_DOCUMENT">#TITRE #EXTENSION ([(#TAILLE|taille_en_octets)])</a>
      	<br />Merci et à bientôt.
      </BOUCLE_download>

      Si je ne mets pas de critère d’article, je vois tous les fichiers de tous les articles ayant un document à télécharger dans le mail de notification.

      1. <BOUCLE_download(DOCUMENTS){extension==zip|rar}{mode=document}{doublons}>

      Si je mets le critère id_article, il n’y a rien dans le mail de notification.

      1. <BOUCLE_download(DOCUMENTS){id_article}{extension==zip|rar}{mode=document}{doublons}>

      Si je mets le critère id_article=8 (par exemple), je vois bien dans le mail de notification le fichier qui correspond à cet article, c’est le résultat attendu.

      1. <BOUCLE_download(DOCUMENTS){id_article=8}{extension==zip|rar}{mode=document}{doublons}>

      Du coup, je ne sais pas comment indiquer à cette boucle le bon id_article, il y a une solution ?

      Merci

      Chrys

    • Ah mon avis, tu a intéret à savoir quel article la personne a demandé en enregistrant aussi cela en base/par email. Du coup tu peux simplement
      1) créer un champ caché
      2) passer la valeur de l’article comme valeur par défaut du champ caché

      <formulaire|formidable|id=contact|defaut=hidden1,8>

      3) fair id_article=#ENV{valeurs/hidden_1}

      (by the way:je viens de tester #ENV{valeurs/input_1} me retourne bien la valeur du champ 1.

    • Bon, alors
      1) si tu désactive l’option “Ne pas envoyer les valeurs de la réponse dans l’accusé de réception”, alors le squelette qui construit l’accusé de réception recevra bien les valeurs postées (y compris cachées) et donc ma solution pourra marcher.
      2) tu crée un champ caché, qui sera appelé hidden_1 (nom donné automatiquement par formidable)
      3) tu pré rempli ce champ caché lorsque tu insère ton formulaire dans un article. La valeur que tu passe au champ caché, c’est l’identifiant de l’article

      <formulaire|formidable|id=dowload|defaut=hidden_1,8>

      si par exemple tu veux les doc de l’article 8.
      4) dans ton squelette, tu utilise #ENV{valeurs/hidden_1 (qui est désormais accessible, cf 1) pour selectionner le bon article.

      <BOUCLE_download(DOCUMENTS){id_article=#ENV{valeurs/hidden_1}{extension==zip|rar}{mode=document}{doublons}>
      	Bonjour,	
      	<br />Télécharger votre fichier en cliquant sur ce lien :
      	<br /><a href="#URL_DOCUMENT">#TITRE #EXTENSION ([(#TAILLE|taille_en_octets)])</a>
      	<br />Merci et à bientôt.
      </BOUCLE_download>

      Par ailleurs, tu as fait une chose TRÈS TRÈS MAL. Tu n’a pas mis de label à tes saisies, mais tu a simplement mis un “placeholder”. Or cela n’est pas du tout la même chose. Un label explique ce qu’est la saisie, un placeholder donne une valeur exemple. En terme d’accessibilité, ne pas avoir de label c’est **MAL**. SI tu veux que le label soit visible dans le contenu de la saisie “à la mode d’un place holder”, cela peut se régler par des astuces CSS (que je ne connais pas)

    • MERCI tout marche très bien et comme attendu !!

      Je règle les soucis de label également

      Merci encore

    Reply to this message

  • 10

    Bonjour,

    Je continue d’explorer votre plug-in.

    J’aimerai pouvoir personnaliser le fichier formulaire_accuse.html à ma guise.
    J’ai d’abord copié le répertoire notifications dans mon dossier squelettes.
    J’ai l’habitude d’utiliser mjml pour créer des mails responsive.

    Dans le fichier formulaire_accuse.html, j’aimerai pouvoir faire quelque chose comme :

    Bonjour {{$nom}},
    Votre email : {{$email}}
    Votre message : {{$message}}

    Mais qu’elles sont les balises à utiliser pour cela.

    J’imagine que c’est quelque part dans :

    [(#ENV*{message_retour}|propre)]
    #VOIR_SAISIES{#ENV*{saisies}, #ENV*{valeurs}}

    Si vous avez des pistes ?

    Merci

    • normalement #ENV{valeurs/nomduchamp}. Attention, par nomduchamp on entend le nom technique du champ (input_1,input_2,etc pas le libellé.

    • Entendu Maïeul et merci.
      Je tente cela en rentrant demain ;-)

    • Excellent ! une fois de plus :-)
      Merci

      J’adopte… belle souplesse pour nos formulaires ce plug

    • Désolé, cette syntaxe ne marche plus pour moi :

      #ENV{valeurs,input_1}

      Ou ais je fauté ?

      Merci

    • tu a mis une virgule et pas un slash

    • Désolé, même comme ceci ca ne marche pas pour moi

      1. #ENV{valeurs/input_1}
    • Hum,
      j’ai un peu perdu le fil de ce que tu veux faire. Peux tu
      1) me reexpliquer
      2)m’envoyer ton yaml
      3) m’envoyer ton fichier .html

    • Entendu, sur quelle adresse puis je te faire passer ceci ?

      Merci

    • monprenomsansaccent@monprenomsansaccent.net

    • Si #ENV{valeurs/input_1} ne marche pas chet toi, c’est que tu avais coché l’option “Ne pas envoyer les valeurs de la réponse dans l’accusé de réception”. Donc forcément les valeurs ne sont pas envoyées au squelette qui construit l’AR, puisque telle est ta demande....

    Reply to this message

  • 1

    Bonjour,

    Est-il possible de faire appel à une base de données pour une liste déroulante ou une sélection multiple où les Clés et Label correspondraient à des champs de cette base de données ?

    Merci pour la réponse.

    • Il vous faudra créer votre saisie personnalisée. C’est relativement simple :
      1) un dossier saisies et un dossier saisies-vues à créer dans son dossier squelettes (ou dans un plugin)
      2) un fichiers .yaml pour décrire la configuration de la saisie, un fichier .html pour décrire son affichage, un .html pour décrire sa vue.

      Le plus simple est de vous inspirer de ce qui existe dans le plugins saisies.

    Reply to this message

Comment on this article

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