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 utilisateurtrice

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_reponse Identifiant de la réponse à modifier Entier
no_ajax Désactiver l’ajax sur le formulaire Booléen
traiter_enregistrement_desactiver_modif_instituer_prop Permet de désactiver au cas par cas l’option de configuration « Lorsque l’internaute modifie la réponse, son statut redevient « proposée » » 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

830 discussions

  • 6

    Bonjour,

    J’essaie de faire un formulaire de contact qui permette de garder secrets les courriels des personnes de notre annuaire professeur (certains utilisent des adresses personnelles).

    Les personnes inscrites n’ont pas toutes des comptes auteurs aussi ai-je enregistré les adresses de contact dans le champ “Description brève” de leurs fiches. L’idée est donc de transférer la valeur de cette Description brève dans un champ caché du formulaire et de l’utiliser comme adresse de destinataire.

    J’ai intégré le formulaire dans le squelette des fiches de membres, avec l’appel

    #FORMULAIRE_FORMIDABLE{formulaire_contact, #ARRAY{courriel_cache, #DESCRIPTIF|PtoBR}}

    (j’ai mis PtoBR pour éviter le risque d’ajouts de balises HTML perturbatrices)

    Sauf que je ne parviens pas ensuite à récupérer la valeur pour l’injecter correctement. J’ai même essayé en saisissant directement une adresse électronique lors de l’appel du formulaire. J’ai aussi essayé

    Est-ce que cette manip n’est tout simplement pas faisable ? Ou, s’il faut manipuler un autre squelette, où puis-je le trouver ? Je n’ai pas réussi à trouver formulaire_contact dans les dossiers...

    Merci de votre aide,

    Alexis

    • Qu’entendez vous par “fiche” ?.

      Par ailleurs je vous invite à relire la doc juste au dessus

      1. Vous verrez que la première option d’appel au formulaire correspond aux valeurs par défaut des champs du formulaire. Or
      a. Il n’y a pas de champ courriel_cache dans le formulaire (cf les noms de champs listé à droite lors de la config des traitements !)
      b. Quand bien même un tel champ existerait, votre appel revelerez publiquement les emails, en rajoutant leur nom dans le code html
      2. Il existe la possibilité de passer un second tableau d’option, dont l’une des options est traiter_email_destinataires pour indiquer les destinataires lores du traitement email

    • La fiche de membre est la rubrique qui lui est consacrée, avec un ou plusieurs articles de présentation. C’est dans le premier article, qui est obligatoire, que j’ai enregistré le courriel dans le champ “Description brève” (donc #DESCRIPTIF dans les boucles) afin de l’avoir en référence (parce que cet article, obligatoirement page d’accueil de la rubrique, n’a pas l’usage de DESCRIPTIF, me permettant d’en détourner l’usage).

      Je n’ai pas bien saisi le comportement de “traiter_email_destinataires”, ce qui fait que je n’ai pas essayé de l’utiliser.

      De ce que j’ai compris, il s’agirait donc d’intégrer {traiter_email_destinataires, #DESCRIPTIF|PtoBR} comme argument de l’appel du formulaire, mais ce que je ne parviens pas à trouver dans la documentation (ni dans l’interface d’édition du formulaire), c’est comment j’indique ensuite au formulaire de l’utiliser. Est-ce automatique et je cherchais comment l’intégrer pour rien ? Ou est-ce qu’il y a encore quelque chose qui m’échappe ?

    • Bah dans formidable une fois qu’on a créé les champs d’un formulaire, on doit configurer des traitements. Parmis ceux-ci, il est possible de d’activer le traitement “Envoyer par email”. Si vous activez ce traitement, et bien ensuite tout les emails passé comme argument via traiter_email_destinataires seront ajoutés comme destinataires...

    • Merci pour la confirmation.

      En préparant ma réponse parce que ça ne marchait pas, j’ai constaté qu’un caractère vide était intégré dans mon code (le copier-coller affichait ceci : ARRAY{-traiter_email_destinataires, mais totalement invisible dans NotePad++), ce qui faisait bugger l’appel à cet argument.

      Maintenant que je l’ai retiré, ça marche en effet directement.

      Merci beaucoup,

      Alexis

    • Super. Pour l’avenir, peut tu utiliser la balise code ou les backsticks lors que tu cite du code ? cela évite de perdre les } et autres caractères spéciaux...

    • J’essaierai d’y penser, oui. :-)

    Reply to this message

  • 2

    Bonjour,

    Je cherche à construire le tableaux de réponses à un formulaire.
    Je suis en SPIP 4.4 et formidable 7.0.6.

    Comme indiqué dans Complément sur Formidable, j’ai une boucle pour afficher les labels dans la ligne de tête :

    <BOUCLE_spip_formulaires(FORMULAIRES){id_formulaire=1}>
        [<th scope="col">(#SAISIES|unserialize|saisies_chercher{input_1}|table_valeur{options/label})</th>]
        [<th scope="col">(#SAISIES|unserialize|saisies_chercher{input_2}|table_valeur{options/label})</th>]
        [<th scope="col">(#SAISIES|unserialize|saisies_chercher{input_3}|table_valeur{options/label})</th>]
    </BOUCLE_spip_formulaires>

    Mais cette boucle ne me renvoie rien.

    Si je mets #SAISIES dans la boucle, ça ne renvoie rien.
    Quelle serait les bonnes balises pour afficher les labels ?

    Merci.

    • La doc complement sur formidable n’a jamais vraiemnt été “approuvée” par les auteurs de formidable, Ce sont plus des essais fait par des gens et mis dans une doc pas forcément pensé de a à z.

      Il se trouve que depuis la rédaction de cette doc, formidable a modifié la manière de stocket en interne les saisies. Il faut remplacer unserialize par formidable_deserialize et cela devrait marcher (/(sur ce point du moins).

    • Merci Maïeul, ça fonctionne avec formidable_deserialize !

      Je dépose le code SPIP de mon tableau de résultats :

      #SET{bonnes_reponses_total,0}
      #SET{effectif_total,0}
      
      <B_reponses>
      <table class="table spip">
        <caption>
          Les réponses à la question 
        </caption>
        <thead><tr class="row_first">
      <BOUCLE_spip_formulaires(FORMULAIRES){id_formulaire=1}>
          <th scope="col" id="date">Date</th>
          <th scope="col" id="groupe-classe">[(#SAISIES|formidable_deserialize|saisies_chercher{input_1}|table_valeur{options/label})]</th>
          <th scope="col" id="bonnes-reponses">[(#SAISIES|formidable_deserialize|saisies_chercher{input_2}|table_valeur{options/label})]</th>
          <th scope="col" id="effectif">[(#SAISIES|formidable_deserialize|saisies_chercher{input_3}|table_valeur{options/label})]</th>
          <th scope="col" id="ratio">Ratio</th>
      </BOUCLE_spip_formulaires>
        </tr></thead>
        <tbody>
      <BOUCLE_reponses(FORMULAIRES_REPONSES spip_formulaires_reponses_champs)
             {id_formulaire=1}{par date}
             {nom=liste_questions_1} {valeur=#ENV{id_article}}
      >
        #SET{bonnes_reponses,#VOIR_REPONSE{input_2,brut}}
        #SET{effectif,#VOIR_REPONSE{input_3,brut}}
        #SET{bonnes_reponses_total,#GET{bonnes_reponses_total}|plus{#GET{bonnes_reponses}}}
        #SET{effectif_total,#GET{effectif_total}|plus{#GET{effectif}}}
        #SET{ratio,#GET{bonnes_reponses}|div{#GET{effectif}}}
        <tr class="row_[(#COMPTEUR_BOUCLE|alterner{odd,even})] ">
          <td headers="date" class="date small">[(#DATE|affdate)]</td>
          <th headers="groupe-classe" class="#VOIR_REPONSE{input_1,edit}">#VOIR_REPONSE{input_1,brut}</th>
          <td headers="bonnes-reponses" class="numeric #VOIR_REPONSE{input_2,edit}">#GET{bonnes_reponses}</td>
          <td headers="effectif" class="numeric #VOIR_REPONSE{input_3,edit}">#GET{effectif}</td>
          <td headers="ratio">[(#GET{ratio}|round{2})]</td>
        </tr>
      </BOUCLE_reponses>
      #SET{ratio,#GET{bonnes_reponses_total}|div{#GET{effectif_total}}}
        </tbody>
          <tfoot>
          <tr>
            <th scope="row" colspan="2" id="totaux" class="center">Totaux</th>
            <td class="numeric" headers="bonnes-reponses totaux">#GET{bonnes_reponses_total}</td>
            <td class="numeric" headers="effectif totaux">#GET{effectif_total}</td>
            <td class="numeric" headers="ratio totaux">[(#GET{ratio}|round{2})]</td>
          </tr>
        </tfoot>
      </table>
      </B_reponses>
      <strong>Il n'y a pas encore de réponse pour cette question.</strong>
      <//B_reponses>

    Reply to this message

  • 12

    Bonjour,
    depuis la dernière màj de Formidable, les mails ne partent plus. J’ai systématiquement le message d’erreur du plugin.
    Les mails partent bien à partir du test du Facteur (par SMTP, via un compte sur le domaine). Tout est à jour (Spip 4.4.2) et plugins.
    J’ai ce problème chez Ionos et Infomaniak.
    Je joins le yaml sur demande. Tout fonctionnait bien avant...

    D’avance merci pour votre aide,
    Rémy

    • Les plugins facteurs et le cas écheant mailshot sont-ils bien à jour ?

    • Bonjour,
      Facteur 5.2.1 et Mailshot n’est pas installé.
      Merci

    • Bon, je poursuis mes tests sur différents sites avec les mêmes versions de plugins. Certains sont sous Spip 4.3.8, d’autres en 4.4.2. Chez Hostinger, j’ai aussi le même souci : les mails ne partent pas. Les réponses s’enregistrent bien en base, Facteur fonctionne normalement. Les configurations sont identiques.

    • Hum. Donc oui c’est bon.

      Je ne sais pas. Il faudrait que je puisse debuguer en live en disposant d’un accès au privé et des accès ssh... Chez moi ca marche TM.

    • Bonjour,
      j’ai continué mes tests en comparant les réglages de chaque formulaire, quel que soit l’hébergeur. Je n’ai rien trouvé de ce côté. Les seules différences se situent au niveau du Facteur, avec plusieurs cas de figure (fonction mail php, smtp, Mailjet). Dans tous ces cas, les mails partent bien depuis le Facteur.
      En installant Formidable (7.0.5) sur un site perso (4.4.2 / php 8.3) qui n’utilise pas le plugin, j’ai créé un formulaire et celui-ci fonctionne parfaitement (mail admin + internaute). C’est bien une nouvelle installation et non une màj.
      J’ai donc fait le test suivant : exporter un yaml d’un formulaire, supprimer le formulaire, supprimer Formidable. Puis, j’ai réinstallé Formidable et importé le yaml. Malheureusement l’erreur est toujours présente. Sur ce même site, j’ai créé un nouveau formulaire : erreur également :-(
      Je ne peux que constater que les versions après la 6.6.2 donnent tous la même erreur quand il y a eu màj.

      Peut-on se caler pour essayer de résoudre le problème ?
      Merci pour ton aide, parce que là j’ai les 2 pieds dedans...
      Rémy

    • Essaie de me biper sur discord (dans l’idéal) ou à la rigueur IRC (mais je suis même réactif) dans la journée. On peut essayer de voir cela.

    • Merci pour ton temps. Je ne suis par sur Discord et je ne sais pas utiliser Irc...
      Je serai plutôt dispo demain, si tu l’es également ?

    • Non je ne suis pas dispo demain, ni toutes les 2 prochaines semaines...

    • Ok, je peux être dispo maintenant pour maxi 30mn. Ok pour toi ?

    • Bah oui mais faut que tu me contacte...

    • Je t’envoie un mail, merci !

    • Eh bien, un GRAND MERCI à Maïeul pour avoir résolu le problème.
      Il suffisait de décocher la case “Insérer l’adresse d’envoi dans le champ “From”” dans les traitements du formulaire pour que ça fonctionne.
      J’ai testé sur plusieurs formulaires, avec des méthodes d’envoi différentes, chez plusieurs hébergeurs : c’était bien ça qui coinçait !

      Si ça peut servir à d’autres :-)
      Bon dimanche,
      Rémy

    Reply to this message

  • 1

    bonsoir,

    cette fois, j’ai fait ma première pétition avec formidable.... avec un modèle pour afficher les signataires dans la partie publique.
    le tableau des résultats est parfait pour gérer les signatures..

    il reste une fonction que je ne sais pas faire...
    Comment importer les données d’un tableau dans un formulaire... ?

    Pour mon cas de pétition, j’ai en effet des signatures qui n’ont pas été saisies en ligne et qui me son transmises sous forme de tableau...

    une idée ?

    • Malheureuement non on n’a pas encore de fonctions d’import. Ca fait partie d’une todoliste depuis longtemps.

      Et je pense que tu a compris en codant ton modèle (félicitation) pourquoi ce n’est pas si simple que cela d’avoir un modèle generique d’affichage des réponses d’une petition.

    Reply to this message

  • 4

    bonsoir

    j’avais tenté dans le passé de faire développer un plugin de pétition amélioré, qui n’a pas survécu à l’évolution de spip et notamment à spip4
    et de toute façon, formidable est tellement formidable, que tout peut se refaire avec...

    j’ai créé mon premier formulaire formidable, ca marcne, il y a des signatures en ligne, mais je m’aperçois que ce n’est pas simple du tout de faire qqchose qui parait simple avec la pétition standard de spip, un modèle d’affichage des résultats dans la partie publique (donc en choisissant les données à publier...)
    J’ai vu qu’il y avait tablesorter mais pour le coup, c’est beaucoup trop pour le besoin simple d’un tableau paginé dans un modèle.
    je vois que le modèle formidable analyse propose un affichage, mais pas du tout orienté vers une liste de signataires...

    est-ce que j’ai raté qq chose ?
    merci d’avance

    • Je ne pense pas, effectivement. Il n’y a pas pour l’instant un truc adapté à ton besoin directement.

    • j’ai avancé, en faisant un modèle reposant sur une boucle FORMULAIRES_REPONSES et une FORMULAIRES_REPONSES_CHAMPS, qui me permet d’avoir la liste des valeur saisies par réponse.

      c’est primitif et surtout, ca fait un modèle pour un formulaire précis, mais c’est un premier pas...

      encore un petit pb, ca ne veut pas générer un tableau spip malgré les “|”... ???

      et il faudrait ajouter la date de la réponse, qui ne semble pas être un champ
      et paginer...

      voila le code

      <BOUCLE_formulaire(FORMULAIRES){id_formulaire}>
      #SET{exclure_champs,#ARRAY{cle1,email_1,cle2,input_2,cle3,case_1,cle4,case_2,cle5,textarea_1}}
      <div class='formidable_analyse'>
      [(#REM) On fait un tableau qui contient toutes les réponses, sans les champs qui sont à ne pas prendre en compte ]
      
      #SET{valeurs,#ARRAY}
      #SET{reponses_total,0}
      |Nom|Prénom|Commune|Code Postal|<br>
      <BOUCLE_reponses(FORMULAIRES_REPONSES){id_formulaire}{!par date}>
      |
      <BOUCLE_champs(FORMULAIRES_REPONSES_CHAMPS){id_formulaires_reponse}{nom ?= #ENV{nom}}{!nom IN #GET{exclure_champs}}>
      #VALEUR |
      </BOUCLE_champs>
      <br>
      </BOUCLE_reponses>
      |
      #SET{reponses_total,#TOTAL_BOUCLE}
      <strong class='nombre_reponse'>
      	[(#TOTAL_BOUCLE|singulier_ou_pluriel{formidable:reponse_une,formidable:reponses_nb})]
      </strong>
      </B_reponses>
      	<strong class='nombre_reponse'><:formidable:reponse_aucune:></strong>
      <//B_reponses>
      </BOUCLE_formulaire>
    • j’ai ajouté la date avec

      #SET{datesaisie,#DATE|affdate{'Y-m-d'}}
      | #GET{datesaisie} |

      je ne sais pas pourquoi on ne peut pas ajouter le filtre addate directement dans le tableau...

    • voila le modèle final avec pagination
      idéalement, il faudrait pouvoir sélectionner les champs à afficher et pouvoir les mettre dans un certain ordre...

      <BOUCLE_formulaire(FORMULAIRES){id_formulaire}>
      #SET{exclure_champs,#ARRAY{cle1,email_1,cle2,input_2,cle3,case_1,cle4,case_2,cle5,textarea_1}}
      <div class='formidable_analyse'>
      [(#REM) On fait un tableau qui contient toutes les réponses, sans les champs qui sont à ne pas prendre en compte ]
      <B_reponses>
      [(#ANCRE_PAGINATION)]
      <h2>Signatures à la date du [(#DATE|affdate)]: [(#GRAND_TOTAL|objet_afficher_nb{signature})] </h2>
      [[<div class="pagination pagination">(#PAGINATION)</div>](#TOTAL_BOUCLE|affiche_pagination{top})]
      <table class="spip">
      <thead>
      <tr class="row_first">
      	<th><b>Date</b></th><th><b>Nom</b></th><th><b>Prénom</b></th><th><b>Commune</b></th><th><b>Code Postal</b></th><br></tr>
      </thead>
      	<BOUCLE_reponses(FORMULAIRES_REPONSES){id_formulaire}{pagination 20}{!par date}>
      		#SET{datesaisie,#DATE|affdate{'Y-m-d'}}
      	<tr><td>#GET{datesaisie} </td>
      	<BOUCLE_champs(FORMULAIRES_REPONSES_CHAMPS){id_formulaires_reponse}{nom ?= #ENV{nom}}{!nom IN #GET{exclure_champs}}>
      	<td>#VALEUR </td>
      	</BOUCLE_champs>
      	</tr>
      	</BOUCLE_reponses>
      	[[<nav class="pagination pagination">(#PAGINATION)</nav>](#TOTAL_BOUCLE|affiche_pagination{bottom})]
      	</B_reponses>
      	<//B_reponses>
      </table>
      </BOUCLE_formulaire>

    Reply to this message

  • Bonjour,

    Nouveau sujet ici pour éviter les mélanges de sujets : je vois que l’on peut exporter les résultats d’un formulaire, mais je me demande si l’on peut réimporter ces résultats (pour chaque formulaire) sans forcément toucher à la base de données (j’avoue ne pas oser) ?

    L’idée étant de ne pas perdre les réponses des internaudes et leurs validations RGPD, lors de grosses modification d’un site en local, sans perdre les données récentes issues des formulaires qui elles, arrivent tous les jours sur le site en production…

    D’avance merci pour vos retours et éclairages.
    Bonne semaine :)

    Reply to this message

  • 13

    Bonjour,
    Je poste ici car c’est un problème qui est survenu depuis l’avant-dernière mise à jour du plugin, que j’ai faite ce mardi, et idem avec la dernière mise à jour d’aujourd’hui 7/02, même problème :
    Mon module d’abonnement à des listes de diffusions (grâce au plugin du même nom et non modifié) ne fonctionne plus depuis la mise à jour du plugin Formidable. C’est une page blanche pour le visiteur et l’information remontée en debbugage de SPIP rapporte l’erreur suivante :

    Erreur(s) dans le squelette :
    L111: formulaires_formidable_saisies_set_options(): Argument #3 ($valeurs) must be of type array, string given, called in D:\SERVER\wamp64\www\adn-4-3-test\plugins\auto\formidable\v7.0.1\formulaires\formidable.php on line 97

    Est-ce que quelqu’un d’autre qui utilise l’abonnement aux listes aurait le même problème, et/ou comment le résoudre ? Je n’en ai pas les compétence.

    Je précise que je n’ai rien modifié dans les modèles, et que mes autres formulaires fonctionnent toujours.

    D’avance merci pour vos remontées et/ou aide.
    Bonne journée

    • Bonjour,

      peux-t-on avoir un export yaml du formulaire en question ?

    • Je poste le code de l’export directement ? Car je ne crois pas pouvoir joindre un fichier yaml…?

    • tu peux me l’envoyer a monprenom@monprenom.net

    • C’est fait, avec un i normal à la place du ï… :)

    • Bonjour,
      Pour info j’ai eu ce problème et cela venait du code d’inclusion de mon formulaire :
      j’avais #FORMULAIRE_FORMIDABLE
      (il prenait automatiquement le seul formulaire créé)

      en mettant :
      #FORMULAIRE_FORMIDABLE{1}

      cela refonctionne.

      dd

    • @Karen le problème venait de l’appel dans le corps de l’article.

      Tu as mis

      <formulaire|formidable|id=inscription_newsletter|listes=newsletter_inscriptions>

      or la bonne syntaxe (cf le corps de l’article) est le suivant

      <formulaire|formidable|id=inscription_newsletter|defaut=listes,newsletter_inscriptions>

      en corrigeant cela tout remarche.

    • hum non il y a quand meme un problème, même avec cette syntaxe. Mais j’ai trouvé pourquoi.

    • Génial, merci Maïeul, ça fonctionne très bien à présent.
      Juste une info toutefois, j’ai testé ta syntaxe :

      <formulaire|formidable|id=inscription_newsletter|defaut=listes,newsletter_inscriptions>

      Et cela fait que l’internaute qui s’inscrit ne reçoit pas le mail à valider pour finaliser son inscription.
      J’ai donc conservé “ma” syntaxe :

      <formulaire|formidable|id=inscription_newsletter|listes=newsletter_inscriptions>

      Et tout fonctionne parfaitement grâce à ta mise à jour. Merci pour ton temps et ton partage.

    • Ta syntaxe ne sert strictement à rien. Elle ne permet pas l’inscription. Je regarde pour le problème avec la vraie syntaxe, la seule officiellement supportée (et supportable).

      Je regarde pourquoi tu a le problème.

    • Hum,

      je ne comprend mmeme pas comment ta syntaxe aurait pu marcher. Mais la mienne non plus.

      La bonne syntaxe c’est celle là

      <formulaire|formidable|id=inscription_newsletter|defaut=listes_diffusion_1,newsletter_inscriptions>

      pour dire de cocher par défaut la liste newsletter_inscription.

      Cela étant si tu n’a qu’une seule liste, tu pourrais très bien simplifier tout cela en

      1. Supprimer la sisie de choix de liste dans le formulaire
      2. Mettre à la place un champ caché contenant l’idnetifiant de la newsletter et dire qu’on s’appuie sur ce champ dans la configuration du traitement
      3. Appelerr directement le formulaire.

    • @Maïeul, un grand merci, et effectivement ça fonctionne super avec cette syntaxe et les corrections que tu as apportées :D

    • Oups, erreur et je ne sais comment supprimer mon message !

    Reply to this message

  • 6

    Bonsoir,
    J’ai créé un simple formulaire avec un champ pour le nom, l’email et un bloc de texte (textarea). Le message de confirmation arrive bien chez l’expéditeur, en revanche, moi, en tant que destinataire, je ne reçois rien.
    Ai-je oublié quelque chose ? mais ou !
    Merci

    Sinon, est-il possible d’afficher des * pour indiquer les champs obligatoires à la place du texte “obligatoire” ?

    Merci à vous.

    Reply to this message

  • 3

    Bonjour

    J’ai un (vieux) formulaire sur l’un de mes sites web qui utilise le champ “oui_non” qui est maintenant obsolète.

    Il est utilisé de façon à ce que les personnes identifiées puissent modifier leur réponse.

    Je ne saurai pas dire depuis quand, mais les réponses des champs “oui_non” ne se chargent plus. Les autres champs se chargent bien avec la réponse précédente.

    C’est assez ennuyeux.

    Comment rectifier mon formulaire ? Si je supprime les champs “oui_non” pour les remplacer par des champs “radio”, je vais perdre les données saisies par les gens, ce n’est donc pas une option.

    Merci de votre aide

    • Peux tu fournir un export de ce formulaire. C’est un pur bug d’affichage, Les saisies obsolètes sont censées toujours etre disponibles à l’affichage, juste plus étendue/améliorée.

      (il n’y a pour l’heure pas de manière simple de convertir des types de saisies)

    • id_formulaire: '20'
      identifiant: droits_a_limage
      titre: 'Droits à l''image'
      descriptif: 'Accord individuel donné par chaque personne travaillant au LIRA concernant l''utilisation de son image sur les différents supports de communication du laboratoire.'
      css: ''
      message_retour: 'Votre réponse a bien été enregistrée.'
      saisies:
        -
          options: { label: 'Mon identité', nom: fieldset_1 }
          identifiant: '@5e3bf7f4d119e'
          verifier: {  }
          saisie: fieldset
          saisies: [{ options: { label: 'Nom et prénom', type: text, readonly: 'on', size: '40', autocomplete: defaut, obligatoire: 'on', nom: input_1 }, identifiant: '@5e3bf2ed87f0a', verifier: {  }, saisie: input }]
        -
          options: { label: 'Mes autorisations', nom: fieldset_2 }
          identifiant: '@5e3bf8105ce06'
          verifier: {  }
          saisie: fieldset
          saisies: [{ options: { texte: 'J''autorise le LIRA / Observatoire de Paris-PSL   à publier mon image et/ou ma voix sur les supports numériques suivants :', nom: explication_1 }, identifiant: '@5e3bf2f463ff1', verifier: {  }, saisie: explication }, { options: { label: 'Sites en accès restreint aux membres du LIRA', nom: fieldset_5 }, identifiant: '@5e3bfa9e670d7', verifier: {  }, saisie: fieldset, saisies: [{ options: { label: 'Trombinoscope sur l’Intranet du LIRA ', valeur_oui: 'on', valeur_non: 'off', nom: oui_non_1 }, verifier: {  }, identifiant: '@5e2ac34278cce', saisie: oui_non }, { options: { label: 'Intranet du LIRA ', valeur_oui: 'on', valeur_non: 'off', nom: oui_non_3 }, verifier: {  }, identifiant: '@5e3bf3a7d5188', saisie: oui_non }, { options: { label: 'Photothèque du LIRA ', explication: 'https://phototheque-LIRA.obspm.fr/', valeur_oui: 'on', valeur_non: 'off', nom: oui_non_4 }, verifier: {  }, identifiant: '@5e3bf3c2c9266', saisie: oui_non }] }, { options: { label: 'Sites publics', nom: fieldset_6 }, identifiant: '@5e3bfae3bdee6', verifier: {  }, saisie: fieldset, saisies: [{ options: { label: 'Site web du LIRA', valeur_oui: 'on', valeur_non: 'off', nom: oui_non_5 }, verifier: {  }, identifiant: '@5e3bf3e97cfb0', saisie: oui_non }, { options: { label: 'Page BlueSky du LIRA', valeur_oui: 'on', valeur_non: 'off', nom: oui_non_6 }, verifier: {  }, identifiant: '@5e3bf54d37cfe', saisie: oui_non }, { options: { label: 'Page Facebook du LIRA', valeur_oui: 'on', valeur_non: 'off', nom: oui_non_7 }, verifier: {  }, identifiant: '@5e3bf55c3cf36', saisie: oui_non }, { options: { label: 'Page Linkedin du LIRA', valeur_oui: 'on', valeur_non: 'off', nom: oui_non_8 }, verifier: {  }, identifiant: '@5e3bf5759b193', saisie: oui_non }] }]
        -
          options: { label: Modifications, nom: fieldset_3 }
          identifiant: '@5e3bf855576d9'
          verifier: {  }
          saisie: fieldset
          saisies: [{ options: { texte: 'Je peux modifier à tout moment les droits accordés sur ce formulaire.', nom: explication_2 }, identifiant: '@5e3bf5c36d07a', verifier: {  }, saisie: explication }, { options: { label: 'Date de la dernière modification', defaut: 'Sera mis à jour automatiquement', heure_pas: '30', readonly: 'on', nom: date_1 }, verifier: { type: date, options: { normaliser: datetime } }, identifiant: '@5e3bf5a5888e3', saisie: date }]
      traitements:
        enregistrement:
          moderation: posteriori
          moderer_admins: ''
          multiple: ''
          modifiable: 'on'
          effacement: ''
          effacement_delai: ''
          identification: id_auteur
          variable_php: ''
          unicite: ''
          message_erreur_unicite: ''
          anonymiser: ''
          ip: ''
          invalider: 'on'
          resume_reponse: ''
          analyse_exclure_champs: ''
        email:
          modification_reponse: ''
          activer_responsable: 'on'
          activer_accuse: ''
          destinataires_plus: xxx@obspm.fr
          destinataires_selon_champ: ''
          champ_sujet: 'Droit à l''image modifié pour @input_1@'
          champ_sujet_modif_reponse: ''
          champ_sujet_valeurs_brutes: ''
          masquer_champs_vides: ''
          exclure_champs_email: ''
          pj: ''
          masquer_liens: ''
          activer_ip: ''
          champ_nom: ''
          activer_vrai_envoyeur: ''
          sujet_accuse: ''
          texte_accuse: ''
          masquer_valeurs_accuse: ''
          courriel_envoyeur_accuse: ''
          nom_envoyeur_accuse: ''
          champ_courriel_destinataire_form: ''
          AR: ''
      statut: publie
      maj: '2025-02-07 11:51:22'
      apres: formulaire
      url_redirect: ''
      date_creation: '2020-02-06 12:24:34'
      
      
    • J’ai essayé de reproduire et je n’ai pas de problème. Mais je ne suis pas sur de comprendre ce que tu veux dire par “les réponses ne se chargent plus”. Peut tu me décrire précisement les étapes?

    Reply to this message

  • 5

    Bonjour
    Avec Spip 4.3.6, depuis que je suis passé à Formidable 7, et 7.1 je rencontre le pb suivant :
    -  dans le traitement des formulaires, j’ai choisi “Envoyer un courriel à des responsables”.
    -  dans “Adresses de destination”, j’ai saisi l’adresse voulue.
    -  dans “Sujet”, j’ai saisi : “MonTexte : 9-@input_1@”
    -  mais le mail reçu contient le sujet : “Machin vous a écrit”.

    Il s’agit de formulaires écrits avant la mise à jour de Formidable : et à l’époque leur sujet reprenait bien ce que j’indiquais.

    Une idée ?
    Merci.

    • Bonjour,

      formidable 7.1 n’existe pas. Je pense que vous parlez de formidable 7.0.1

      Dans tous les cas lorsqu’il s’agit de signaler un bug formidable, un export yaml sera très utile pour comprendre plus précisement où se trouve le problème.

    • Fichier Yaml envoyé.
      Ensuite, comme ce formulaire est une “duplication” d’un autre - sans autre changement que le choix des cases à cocher - j’ai comparé les champs “traitements” via PhpMyAdmin : j’y ai vu des différences (cf image jointe).
      J’ai remplacé le contenu du champ “traitements” du formulaire KO par celui du formulaire OK, et le “sujet” du courriel est redevenu celui attendu.
      Mais je ne sais pas pourquoi les traitements avaient changé...

    • La version “Master” du plugin corrige cela. Je sortierai une version officielle tantot, je dois encore debuguer un truc.

    • Et donc la version 7.0.2 résoud le problème.

    Reply to this message

Add a comment

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.

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