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

811 discussions

  • 10

    Bonjour,
    Je n’ai pas (pas su ?) trouvé la réponse dans les discussions.
    Je voudrais donner le droit de modifier le contenu d’un formulaire.
    Je fais donc ceci :

    <BOUCLE_modif_form (FORMULAIRES_REPONSES){id_formulaire=1}{id_auteur=3}>
    <div> L'auteur n° #ID_AUTEUR peut modifier les réponses ( de#ID_FORMULAIRES_REPONSE) du formulaire n° #ID_FORMULAIRE</div>
    [(#AUTORISER{editer,formulaires_reponses,#ID_FORMULAIRE_REPONSE,#ID_AUTEUR})Modifier les réponses ] 
    </BOUCLE_modif_form> 

    J’obtiens bien dans ma div lpréalable les bonnes infos : n° auteur (3) n° formulaire (1) n° formulaire réponses (52).

    Mais rien ne s’affiche. aucun champ, ni aucun contenu.et je ne vois pas où se situe mon erreur !

    Si je modifie la boucle en mettant (FORMULAIRES) à la place de ( FORMULAIRES_REPONSES), je n’ai strictement rien.

    Merci de votre aide

    • Et dans la config du traitement d’enregistrement, c’est autorisé de le modifier ?

    • Merci
      Oui, ils sont modifiables. Voici ce que nous avons indiqué :

      coché : Multiple : Une même personne peut répondre plusieurs fois.
      coché : Modifiable : Les visiteurs peuvent modifier leurs réponses après coup.

      Si les réponses sont modifiables, quel procédé utiliser en priorité pour connaitre la réponse à modifier ?

      Coché : Par l’identifiant (id_auteur) de la personne authentifiée

    • Je ne vois aucun appel au formulaire dans ton code là.

      Mais en troisième argument il faut mettre l’identifiant de la réponse.

      http://zone.spip.org/trac/spip-zone/browser/_plugins_/formidable/trunk/formulaires/formidable.php#L51

    • Je confirme que le troisième argument prend bien l’identifiant de la réponse (#ID_FORMULAIRES_REPONSE).

      Et si je mets l’appel au formulaire, comme dans le code ci-dessous, celui-ci s’affiche, vierge, autant de fois qu’il y a de ID_FORMULAIRES_REPONSE de l’auteur. Normal, mais ces formulaires sont vierges alors que je suis sensé pouvoir en modifier le contenu.

      Je suis vraiment perdu !

      <BOUCLE_modif_form(FORMULAIRES_REPONSES){id_formulaire=1}{id_auteur=3}>
      _ <div> L'auteur n° #ID_AUTEUR peut modifier les réponses (formulaire réponses n° : #ID_FORMULAIRES_REPONSE) du formulaire n° #ID_FORMULAIRE</div>
      [(#AUTORISER{modifier,formulaires_reponse,#ID_FORMULAIRES_REPONSE,#ID_AUTEUR})Modifier les réponses ]
      #FORMULAIRE_FORMIDABLE{1}
      </BOUCLE_modif_form>
    • Bah peut-être qu’il y a un bug, mais théoriquement c’est bien censé remplir avec le contenu de la réponse avec cet appel :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/formidable/trunk/formulaires/formidable.php#L103

      Il faut peut-être var_dump() dans le PHP pour voir si tout se passe bien.

    • Bonsoir.
      Comme mes compétences en php sont très limitées je ne sais ni où ni comment mettre ce
      var_dump()

      D’autre part, je ne m’en sors pas du tout avec cette boucle pour modifier le contenu d’un formulaire.
      Et aussi, je n’ai pas trouvé, dans le plugin, de modèle de boucle pour autoriser les modifications sur les formulaires remplis
      Exact ou erreur de ma part ?
      Merci

    • Je ne comprends pas ce que tu appelles « des boucles pour autoriser ». Une boucle ça n’autorise rien du tout. Et on peut modifier une réponse précise en donnant son identifiant lors de l’appel du formulaire, comme dit précédemment (enfin théoriquement, apparemment il y a peut-être un bug quelque part…).

    • Bonjour,
      je vais essayer d’être plus clair.
      J’ai un formulaire n°1 avec 3 champs dont deux de dates.
      Le formulaire fonctionne très bien et les personnes autorisées, via une boucle #SESSION, remplissent ces champs que j’affiche ensuite sur une page publique (en l’occurrence une page AUTEUR).

      Comme je souhaite que les auteurs des réponses à ce formulaire n° 1 puissent, en se connectant avec identifiant (via une boucle #SESSION) à leur page AUTEUR, modifier leurs réponses, notamment les dates, j’ai paramétré le formulaire ainsi :

      coché : Multiple : Une même personne peut répondre plusieurs fois.
      coché : Modifiable : Les visiteurs peuvent modifier leurs réponses après coup.
      Si les réponses sont modifiables, quel procédé utiliser en priorité pour connaitre la réponse à modifier ?
      Coché : Par l’identifiant (id_auteur) de la personne authentifiée

      Je fais donc, dans ma page AUTEUR une boucle comme celle ci, (reprise sur le wiki) :

      <BOUCLE_reponse(FORMULAIRES_REPONSES){tout}{id_formulaires_reponse=52}>
      #SET{valeurs,#ARRAY}
      <BOUCLE_champs(FORMULAIRES_REPONSES_CHAMPS){id_formulaires_reponse}>
      #SET_MERGE{valeurs,#ARRAY{#NOM,#VALEUR|tenter_unserialize}}
      </BOUCLE_champs>
      <BOUCLE_formulaire(FORMULAIRES){id_formulaire}>
      #VOIR_SAISIES{(#SAISIES|unserialize), #GET{valeurs}}
      </BOUCLE_formulaire>
      </BOUCLE_reponse>

      ou celle-ci

      <B_reponses_tp>
      <h3>L'abonné n° {id_auteur}   publie :</h3>
      <BOUCLE_reponses_tp(FORMULAIRES_REPONSES){id_auteur=3}{id_formulaire=1}{!par date}><div >
      <span >#VOIR_REPONSE{date_1}</span>&nbsp;
      <span >#VOIR_REPONSE{date_2}</span>&nbsp;
      <span >#VOIR_REPONSE{textarea_1}</span>&nbsp;
      </div>			
      </BOUCLE_reponses_tp>
      </B_reponses_tp>

      L’une et l’autre de ces boucles affichent le contenu des réponses.

      Mais ni l’une ni l’autre de ces boucles ne permet à l’auteur, depuis la page publique, de modifier sa réponse.
      Donc j’ai essayé, sans succès, d’utiliser, dans une boucle (FORMULAIRES_REPONSES) la balise #AUTORISER, en me référant toujours au wiki, qui indique, dans le chapitre « Extraits de todoformidable »

      Autorisations de formidable

      #AUTORISERrepondre, formulaire, #ID_FORMULAIRE

      Permet par exemple de ne pas afficher le formulaire si l’utilisateur a déjà répondu. A combiner aussi avec les modèles fournis :
      -  modeles/formulaires_reponse.html (affiche une réponse précise)
      -  modeles/formulaire_analyse.html (stats de toutes les réponses)


      <Ma boucle pour autoriser :

      _ <BOUCLE_modif_form(FORMULAIRES_REPONSES){id_formulaires_reponse=52}{id_auteur=3}>
      [(#AUTORISER{modifier,formulaires_reponses,#ID_FORMULAIRES_REPONSE,#ID_AUTEUR})]
      #FORMULAIRE_FORMIDABLE{1}
      </BOUCLE_modif_form>

      _
      Donc soit je fais probablement une très grossière erreur que je n’identifie pas, soit on ne peut pas modifier après-coup les réponses, malgré le paramétrage du formulaire, dans la page de l’espace publique. .
      Merci de vos éclaircissements et de votre aide.

    • Multiple ça veut dire qu’une même personne peut générer plusieurs réponses au même formulaire hein.

      Si le but c’est juste de modifier la dernière réponse, ya pas à expliciter l’identifiant de la réponse à modifier. En appelant juste le formulaire ayant l’option qu’ils ont le droit de modifier, alors c’est censé pré-remplir avec la dernière réponse.

      Mais si on donne explicitement l’identifiant de la réponse à modifier, alors ya même pas besoin de l’option pour accepter la modif des réponses dans la config du traitement enregistrement, car là c’est le squelette qui demande explicitement à le modifier. En troisième argument ai-je dis précédemment plus haut.

      #FORMULAIRE_FORMIDABLE{truc, '', #ID_FORMULAIRES_REPONSE}

      Pour l’appel SANS l’identifiant de réponse, ça ne pré-remplit avec la dernière réponse QUE si c’est configuré pour ne PAS pouvoir répondre plusieurs fois DIFFÉRENTES évidemment.
      Car la config « pouvoir répondre plusieurs fois » est prioritaire à « pouvoir modifier sa dernière réponse ».

      Il faut soit que tu décoches pour ne PAS accepter plusieurs réponses (en laissant d’accepter de modifier). Soit que tu indiques explicitement l’identifiant de la réponse à modifier (comme plus haut là). Pour le première cas, l’appel classique avec juste l’identifiant du formulaire suffit, sans identifiant de réponse : ça va chercher la dernière tout seul.

    • Grand merci.
      Non seulement j’ai (enfin !) compris mais j’ai pu le faire fonctionner avec plusieurs formulaires et plusieurs réponses par formulaires via des #SET/#GET sur un squelette unique.

    Répondre à ce message

  • 3

    Bonjour, un champ caché peut il recevoir une donnée d’un autre champ du formulaire de manière dynamique ? Comment faire ? Existe-t-iil de la doc à ce sujet ?

    Merci pour votre réponse !

    • Je ne saisis pas trop le concept (si c’est déjà dans un autre champ, pourquoi le copier en plus dans un champ caché ? ou bien tu parles en faisant une transformation avant, en combinant plusieurs trucs ou en faisant des opérations ?)

      Mais non, ça n’existe pas, à moins d’ajouter du javascript (mais comme pour n’importe quel formulaire, faire des trucs en javascript n’est pas très sain car pas actif partout et peut être trafiqué).

    • Merci pour cette réponse.
      Je cherche un moyen de proposer un choix fermé + un choix libre. Et je souhaite récupérer cette variable dans un champ caché pour traitement...

    • quelqu’un d’entre vous aurait-il des pistes ?

    Répondre à ce message

  • 45
    Polar oïd

    Bonjour,

    Après validation d’un formulaire avec paiement, j’aimerais retrouver le

    transaction_hash

    dans le mail envoyé par le plugin, pourriez_vous m’indiquer la marche à suivre ?

    • Aucune idée, Formidable ne fait pas de paiement, c’est au sous-plugin de paiement qu’il faut demander ça. :)

    • Polar oïd

      Avec le plugin transaction 0.3.1 et SPIP 2.1.19 je pouvais récupérer la référence de transaction dans le mail avec la balise #EVAL{$_SESSION['ref']}

      Avec SPIP 3.0.20 et le plugin BANK, je n’arrive pas à retrouver ce mode de fonctionnement... Comment identifier la variable correspondante ?

    • Je ne sais pas, je t’ai dit que ce n’est pas Formidable qui gère ça, c’est le sous-plugin de paiement, dont je ne suis pas l’auteur.

    • Polar oïd

      D’après ce que je constate, lors d’une validation d’un formulaire formidable (avec transaction/bank ou pas), formidable inscrit en base un id_formulaires_reponse, c’est cette valeur qui est ensuite utilisée par le plugin Bank et renomée sous la forme tracking_id... C’est donc formidable qu’il faut interroger :) Ainsi, je reformule ma question : comment retourner id_formulaires_reponse dans le mail envoyé par formidable ? Avec cette valeur, et peut être une boucle avec jointure, je pourrai certainement trouver ce que je cherche...

    • Bank « n’utilise » rien du tout : il ne sait absolument pas ce que c’est que Formidable, tout comme Formidable ne sait absolument pas ce que c’est que Bank.

      Je le répète : c’est le plugin « Paiement avec Formidable » (que tu as forcément) qui fait tout ça, et qui a donc potentiellement les informations voulues.

      À part ça les traitements dans Formidable sont absolument séparés les uns des autres, indépendants. On peut en cocher un ou plusieurs. Et pour le moment il n’y a même pas de notion d’ordre d’exécution des traitements (qui pourraient par exemple être choisi dans le YAML du traitement). Donc on peut même pas être sûr que tel traitement est fait après ou avant un autre. Si l’email part en tout premier traitement, les autres ne sont même pas encore démarrés. Donc aucune information possible venant des autres (Formidable n’inscrit pas *forcément* en base id_formulaires_reponses : seulement quand on a activé le traitement d’enregistrement).

    • Polar oïd

      J’ai donc désactivé Bank et Paiement avec formidable afin de cerner au mieux, ainsi : je valide un formulaire paramétré comme tel : « Poste le résultat du formulaire par courriel à une liste de destinataires. ». Au moment de la validation, le plugin inscrit en base un id_formulaires_reponse dans la table spip_formulaires_reponses qui est spécifique à un id_auteur tel qu’inscrit dans la base... Ma question subsiste donc, comment retourner id_formulaires_reponse dans le mail formulaire_email.html ? Nous sommes d’accord, rien à voir avec Bank ni Paiement avec formidable !

    • Réponse : il me semble que pour l’instant on ne peut pas puisque le traitement « enregistrement » est fait APRÈS le traitement « envoyer un email ».

    • Polar oïd

      Pourtant avec formidable 0.6.7 et SPIP 2.1.19 je pouvais récupérer la référence dans le mail avec la balise #EVAL{$_SESSION['ref']}, il doit bien exister une variable de session qui stocke cette donnée mais quel est son nom ?

    • « Paiement avec Formidable » n’existe pas pour SPIP 2.1, donc tu utilisais autre chose.

    • polar oïd

      Quels que soient l’ordre des traitements, les données à traiter sont stockées quelque part en attente de traitement non, en session ? C’est ici que se pose la question ! Comment récupérer ces données ? D’autant plus que si elles sont utilisées par d’autres plugins, il faut bien qu’elles existent quelque part ?!

    • polar oïd

      Je reprends donc ma question : après la validation d’un formulaire formidable paramétré comme tel : « Poste le résultat du formulaire par courriel à une liste de destinataires. ». J’aimerais afficher id_formulaires_reponse dans le mail formulaire_email.html au même titre que les résultats de saisies préformatés et retournés par

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

      Comment faire ?

    • Je le répète, « id_formulaires_reponse » c’est ce qui est *enregistré en base*, donc par le traitement « enregistrement ». Qui se fait APRÈS le traitement « email ». Donc pour l’instant, tant qu’on peut pas forcer l’ordre des traitements, je dirais impossible.

    • polar oïd

      Si j’intègre la boucle suivante dans formulaire_email.html

      <BOUCLE_reponse(spip_formulaires_reponses){id_auteur=#SESSION{id_auteur}} >
      #ID_FORMULAIRES_REPONSE
      </BOUCLE_reponse>

      Elle me retourne bien id_formulaires_reponse en question (testé avec une table vierge). Dans ce cas, comment le mail (et donc cette boucle) pourrait-il retourner un id_formulaires_reponse qui ne serait pas en base ???

    • polar oïd

      Correctif : effectivement, ce que j’affirme au dessus est erroné, l’enregistrement en base se fait bien après l’envoi du mail , pardon pour cette erreur de ma part. IL doit pourtant être possible de récupérer cette id_formulaire_reponse dans la session, avant le traitement enregistrement du formulaire.

    • Je ne sais pas, là dans le code je ne vois rien qui permette de dire que « enregistrement » se fait avant « email »…

    • Il doit pourtant être possible de récupérer cette id_formulaire_reponse dans la session, avant le traitement enregistrement du formulaire.

      Euuuh, tu saisis pas le problème de logique dans ta phrase là ? :D

      « id_formulaire_reponse » c’est l’identifiant SQL, crée par la base SQL, quand tu ajoutes une nouvelle ligne dans la table des réponses. Donc comment veux-tu que cette identifiant existe avant puisque c’est justement le traitement « enregistrement » qui enregistre cette ligne de réponse ?

    • polar oïd

      Oui je comprends mais mon entendement se heurte au fait, comme on dit « les faits sont tétus » dans une utilisation antérieure du plugin j’utilisais la boucle suivante dans le mail et ça fonctionnait parfaitement...

      <BOUCLE_formulaire_valeur(spip_formulaires_reponses_champs spip_formulaires_transactions){ref_transaction=#EVAL{$_SESSION['ref']}}{nom="radio_1"}>
         Type : #VALEUR<br />
         N° de réponse : #ID_FORMULAIRES_REPONSE<br /> 
      </BOUCLE_formulaire_valeur> 

      Elle retournait parfaitement l’id_formulaires_réponse dans le mail, ceci pour ensuite fabriquer un lien de type

      <a href="#URL_SITE_SPIP/spip.php?page=mapage&ref=#EVAL{$_SESSION['ref']}">Editer</a>

      Je voudrais retrouver ce mode de fonctionnement suite à une mise à jour...

    • Mais les faits sont têtus : en 2.1 le plugin « Paiement pour Formidable » n’existe pas, il me semble non ? Donc c’est que tu utilisais autre chose (quoi ?). Et cet autre chose fonctionnait peut-être différemment ? En tout cas là tout de suite, je ne vois pas pourquoi à un moment ça aurait pu faire « enregistrement puis email » et désormais « email puis enregistrement ».

    • Bonjour,

      Je me pose un peu la même question (et je suis à peu près dans le même cas), je vais essayer de formuler différemment pour voir si on trouve une solution.

      Comme Polar Oïd j’utilise la notification créée par le squelette formulaire_email.html (que j’ai copié dans un dossier notifications dans mes squelettes) qui contient un :

      #VOIR_SAISIES#ENV*saisies, #ENV*valeurs

      Ce que je ne pige pas même après la lecture de tout ce fil c’est que le #VOIR_SAISIES marche et retourne bien tous les champs de la réponse que l’on vient de faire au formulaire, donc j’imagine que ce #VOIR_SAISIES récupère bien l’info « id_formulaires_reponse » pour pouvoir afficher la liste des champs et de leurs réponses ... comment fait-il ?

      Pour ma part je constate que l’on a bien #ENVid_formulaire mais par contre impossible de récupérer un #ENVid_formulaires_reponse dans ce squelette, et pourtant #VOIR_SAISIES marche ....

      Pour l’instant j’ai contourné le problème en utilisant un truc semi correct : je récupère la dernière réponse (classement inverse et 0,1) avec une boucle FORMULAIRES_REPONSES avec sélection sur #ENVid_formulaire mais j’ai bien conscience que je cours un risque si quelqu’un commande exactement au même moment .... bref pas satisfaisant, pas très grave mais pas satisfaisant.

      Une idée ?

    • Mais non je l’ai déjà dit, il n’y a absolument pas de « id_formulaires_reponse » ! Justement on passe #ENV{valeurs}, on ne va RIEN chercher dans la base de données, ce sont les valeurs postées durant le formulaire, tout simplement et directement, ya aucun besoin de la base pour ça. Le traitement d’enregistrement est séparé, se fait à part, ya aucun lien (et possiblement il se fait même après, on peut pas être sûr de l’ordre, et donc on peut absolument pas être sûr que ça ait été enregistré dans les tables avant que l’email ne soit généré).

    • Polar Oïd

      Je nourris la même insatisfaction pour avoir utilisé le même contournement semi correct (classement inverse et 0,1) qui ne permet pas d’avoir une confiance absolue vis à vis du

      id_formulaires_reponse

      voulu. En toute logique, il doit courir en session quelque part mais impossible de mettre la main dessus au stade actuel de mes recherches. Je suis content d’apprendre qu’une autre personne rencontre le même questionnement, cela pourrait motiver de nouvelles réponses... Ne pas lâcher ! A noter que le mail part bien avant le traitement bien que si formidable est utilisé avec d’autres plugins comme Bank, il faudrait peut être que l’envoi du mail soit réalisé en fin de traitement par les autres plugins, ceci dans un rapport de dépendance...

    • Alleluïa !!!!

      RastaPopoulos vient de donner LA solution, pour mon cas en tous cas. Plus besoin de boucle, toutes les valeurs du formulaire sont dans #ENVvaleurs, on peut utiliser ça !!! Mon besoin était de personnaliser le look de l’email, donc ça le fait pour moi !!!

      J’ai vérifié avec un #ENVvaleurs|foreach, j’ai tout ce qu’il me faut !

      Pour Polar Oïd, je ne sais pas quel est le besoin final, mais je me disais qu’on pourrait créer un champ caché avec un identifiant unique ... on peut ensuite remonter à l’id de la réponse au moyen de cet identifiant ...

      Bref, j’avais le bon pressentiment, en reformulant la question on aurait une solution, merci à tous !

    • Polar Oïd

      Du coup, je me pose une autre question sur Formidable suite à la dernière réponse de RastaPop, pourquoi envoyer par mail le résultat d’une saisie qui pourrait ne pas être enregistrée dans la base ? Ca peut se comprendre dans le cas ou l’on paramètre le plugin pour qu’il n’enregistre pas les résultats dans la base mais dans le cas contraire, n’y aurait-t-il pas une autre façon de procéder qui devrait porter sur l’ordre des traitements relativement à cette affaire de mail ? :)

    • pourquoi envoyer par mail le résultat d’une saisie qui pourrait ne pas être enregistrée dans la base

      Je ne comprends pas trop ta dernière question. La réponse est un peu toute conne : les traitements (il y en a deux fournis par défaut mais on peut en ajouter d’autres et d’ailleurs certains sous-plugins en ajoutent d’autres) sont totalement indépendants. On peut vouloir un formulaire de contact, et donc juste envoyer par mail. Et on peut vouloir un formulaire de contact ET le garder en mémoire en base histoire de pas perdre les contacts. Et on peut vouloir garder en base parce pour faires des stats, des questions plus fermées, sondages. Ya plein de cas d’utilisations possibles. Donc évidemment qu’on peut vouloir envoyer par mail sans l’enregistrer en base.

      La solution la plus logique c’est évidemment d’améliorer le plugin pour introduire un système de déclaration d’ordre des traitements, de « poids », ou bien carrément de dépendance mais ça me parait plus compliqué pour rien. Juste pouvoir donner un « rang », et classer par ça avant de lancer les traitements (et donc par exemple email on pourrait mettre dans le YAML, rang:1000, pour être sûr que ça passe en dernier).

    • Polar Oïd

      @pierrot

      créer un champ caché avec un identifiant unique

      J’avais également pensé à cette solution, en utilisant une balise [(#VAL{1}|rand{10000000000})] pour générer un identifiant unique à passer dans un champ caché...

    • Polar Oïd

      @RastaPopoulos

      J’avais bien compris ce que tu précises en premier au sujet des nombreuses modalités d’utilisations des formulaires et je ne remets pas ça en cause, Formidable est formidable, que ferrions nous sans lui ?! :) Il est juste perfectible et ça serait vraiment cool de pouvoir envoyer les mails à la fin des traitements qui peuvent être réalisés par d’autres plugins qui reposent sur lui... Ceci afin de créer des liens d’admin dans les mails pour des traitements donnés... :)

    • @RastaPopoulos

      Bonjour,

      J’ai partiellement résolu mon problème de personnalisation d’email mais bien évidemment la demande évolue au fur et à mesure et effectivement, on souhaiterait ajouter le numéro de facture au mail envoyé suite à un paiement Formidable. J’ai compris que c’était dans l’absolu impossible (car au moment de l’envoi du mail, le stockage en base n’a pas été fait donc impossible de remonter le chemin formulaire->reponse_champ->reponse->facture), cela ouvre 2 questions pour moi :
      -  rien n’est prévu pour « ordonner » les traitements dans le plugin, néanmoins si je voulais faire ça, même manuellement, je devrais regarder ou ? (je suppose qu’il y a un fichier php ou on éxécute chaque traitement dans un certain ordre ...)
      -  le plugin notifications avancées semble être une autre piste, avec l’inconvénient qu’il faudrait le déclencher sur la création de la facture ce qui implique un mail en plus, pour les gens qui administrent une corrélation à faire entre le mail de commande et la facture (et encore une fois sans indication sur le mail de commande du n° de facture ...)

      Merci !

    • Je ne sais pas, tout ça me parait vraiment tordu par rapport à l’usage de départ de Formidable (faire des forms de contact ou des téléformulaires ouverts du genre questionnaires, ou fermés du genre sondage pour faire des stats).

      Moi perso pour le commerce, j’utilise le plugin Commandes, le plugin Bank, et le plugin Factures.

      D’autant plus que la facturation est un point légale avec des trucs précis à respecter, et on doit pas faire n’importe quoi pour être dans les clous (si jamais ya un contrôle fiscal, etc, et le prestataire qui a vendu la solution est responsable aussi si ça ne correspond pas à la loi !).

      Mais par contre, pour ça, il n’y a pas (encore ?) de formulaire « générique » qui permet de faire ce qu’on veut.

      Et non il n’existe aucune manière pour l’instant d’ordonner les traitements, c’est justement un vrai manque, je suis tout à fait d’accord, mais ça reste à développer. Les traitements sont appelés… bah dans la fonction traiter() du formulaire CVT « formidable » : formulaires/formidable.php

    • Je suis dans le cas d’un site qui contient une boutique plus 2 formulaires séparés de paiement, j’ai eu la faiblesse de dire ok au fait que ce que vendent les 2 formulaires ne peut être dans la boutique tout en n’ayant qu’un seul contrat VAD, donc je suis plus ou moins obligé de faire marcher ça avec Formidable (et pour un des 2 formulaires, c’est un choix complexe à tiroirs que je voyais difficile avec le binz de commerce habituel).

      Bref j’essaye, j’en suis à 99% mais évidemment quand ils ont compris que c’est eux qui devaient envoyer la facture ils m’ont demandé d’ajouter un lien vers cette facture sur le mail et je suis retombé dans la problématique de l’ordre des traitements.

      J’ai donc essayé d’inverser l’ordre à la mano dans le json, effectivement ça inverse bien l’ordre des traitements (grave bidouille) mais ça ne résout pas mon problème. L’email retrouve bien la réponse enregistrée dans le formulaire (parfait) mais ne trouve pas la facture qui est enregistrée trop tard dans la base (genre une 15aine de secondes plus tard d’après les timestamp).

      Bref, à moins de trouver un moyen d’appliquer un délai conséquent à l’envoi du mail (genre au moins une minute), c’est impossible, et en tout état de cause pas très solide comme process (que se passe-t-il si pour une raison X ou Y la génération de la facture prend 2 minutes ;..) ...

    • bah, généralement on envoie possiblement un mail de confirmation de commande quand la commande est faite ET un email après avoir fini de payer, quand tout est généré comme il faut, donc y compris possiblement avec des trucs de facture

      le plugin Bank a d’ailleurs des pipelines dédié à la facturation, et le plugin Factures peut appeler des notifs (donc renvoyer un mail quand la facture est vraiment générée)

      enfin ce sont des exemples possibles…

    • Bonjour,

      Pour que la génération de la facture produise une notification, il faudrait faire quoi par ex ?

      Pierre.

    • Bah par exemple le plugin Factures il appelle l’API « notifications » dès qu’il a finit de tout générer :
      https://github.com/nursit/factures/blob/master/inc/factures.php#L106

      Donc par défaut ça fait rien, mais tu peux alors implémenter cette notif et envoyer un email (et avec le plugin Notifications avancées, ya quasiment pas de PHP à faire, juste faire un ou deux squelettes de mail).

    • Bonjour,

      Pour vérifier ce que je comprends (je continue ici au lieu de la page notifications car il me semble que ce sera utile dans le cadre de ce type de question sur Formidable).

      Je dois (en plus d’installer le plugin de Notifications avancées) :
      -  déclarer dans mes_options.php :

      $notifications = charger_fonction('notifications', 'inc/');
      $notifications('truc', $id, $options);


      -  créer dans un dossier « notifications » au minimum un squelette truc.html qui va récupérer ce que je veut envoyer, probablement sur la base de $id ... ?

      Ce que je vois pas là comme ça c’est le lien. Comment factures.php sait-il quelle notification utiliser ? c’est le nom « truc », autre chose ?

      Merci pour une mise sur rail ... :-)

    • Je n’ai absolument rien compris. :D

      Je disais juste que le plugin Factures (que moi j’utilise, tel quel), et bien LUI, il appelle déjà l’API « notifications » lorsqu’il a fini de générer une facture. API qui ne fait rien par défaut tant qu’on a pas implémenter telle ou telle notification (du nom du premier argument, « genererfacture » dans le cas du lien précédent).

    • Oui c’est difficile de poser une question sur un truc qu’on ne comprends pas complètement. Je suis d’accord avec ce que tu n’as pas compris :-)

      -  je comprends que le plugin Factures appelle l’API notifications quand il a généré une facture
      -  je comprends que je dois préparer une notification qui s’appelle par exemple « toto »

      Ce que je ne comprends pas c’est comment le plugin Factures sait quelle notification il déclenche (car j’imagine que le plugin Notifications peut gérer plein de notifications pour des tas d’autres plugins), ou est-ce que je dis à « Factures » d’utiliser « toto » ?

      Ou alors ma notification doit s’appeler exactement « genererfacture » et c’est ça qui fait le lien ? et si c’est ça, comment je trouve ce nom « genererfacture », ... et putain (oops) je viens de comprendre, oui c’est exactement ça, le nom de la notification est déjà dans le code de Factures ...

      Donc en fait la seule chose que j’ai à faire c’est de faire le squelette de notification ? Tu parlais d’un peu de PHP, j’en ai besoin ou ?

    • Mais je n’ai pas compris un truc : tu utilises déjà le plugin Factures ou pas ?

      Je n’ai jamais parlé du plugin Notifications. Mais de l’API uniquement, qui est dans le noyau de SPIP, et qui ne fait rien du tout par défaut.

      Ensuite pour une notification donnée, soit il faut l’implémenter entièrement en PHP, avec l’API d’origine (faire un fonction notifications/truc.php => notifications_truc_dist(…)).

      Soit il faut utiliser le plugin « Notifications avancées », qui augmente l’API Notifications avec des trucs possiblement plus simples :

      • pour le contenu de la notification ya juste à faire un squelette du nom de celle-ci,
      • et après il faut une fonction PHP pour lister le ou les destinataires de la notifications. Mais toute la doc est dans l’article hein. Notamment dans le chapitre « Destinataires ».
    • Polar oïd

      @Pierre

      Suggestion pour la facturation :

      Etant donné que tous les détails d’uns transaction donnée se trouvent dans la table spip_transactions, on peut donc les retourner avec une boucle dans un pdf (la facture). En utilisant par exemple le plugin Spipdf => http://contrib.spip.net/spiPDF-generer-des-contenus-sur-mesure-en-PDF. Le plugin permet de générer un pdf en cliquant sur un lien pouvant contenir des variables comme celle qui correspond à l’id_transaction que tu parviens à récupérer dans le mail envoyé au client... Soit tu poses un lien dans ce mail vers un espace de facturation ou se trouverait le lien pour le pdf, soit tu le mets directement dans le mail... La création du template de facturation par Spipdf repose sur l’utilisation de librairie qu’il faut choisir selon le rendu offert par celles-ci. On peut s’en sortir assez facilement comme ça :)

    • Oui j’utilise déjà Factures et effectivement je croyais que tu parlais du plugin Notifications Avançées, que j’ai de toutes les façons, mais bon en fait tu parlais des notifications du noyau ...

      Ok je vais donc essayer de faire un squelette genererfacture.html pour produire un contenu et je vais re-relire la doc de Notifications Avancées sous ce nouvel éclairage mais il est probable que j’aurai d’autres questions ... J’ai des destinataires fixes et potentiellement un destinataire à récupérer de la réponse à formidable ...

    • #Rastapopoulos et @Polar oïd

      Bonjour,

      J’ai pas mal progressé, c’est à dire que j’arrive à générer une notification à la création de la facture, notification contenant toutes les infos glanées par le formulaire formidable ainsi qu’un lien vers la facture qui fonctionne (avec le hash nécessaire) ...

      Il me reste un souci sur lequel je cale. Je n’ai pas de souci pour les destinataires systématiques (trésorier de l’assoc) que je peux ajouter sans problème dans ma fonctiopn notifications_genererfacture_destinataires_dist() du fichier genererfacture.php. Mais j’aimerai envoyer ce même mail (enfin un mail du même genre) à la personne qui a rempli le formulaire formidable et son champ obligatoire d’email, et là je cale, comment faire ça depuis le fichier genererfacture.php ? cette personne n’est pas un auteur ...

      Merci pour des éventuelles lumières :-)
      Pierre

    • Si tu as lu la doc de la fonction « destinataires », tu remarqueras qu’on peut mettre 3 formats différents dans le tableau de retour. Soit un id_auteur, soit un email simple, soit un tableau plus complet. Donc tu peux parfaitement mettre l’id_auteur de ton trésorier ET en deuxième un email.

    • Bonjour,

      Oui j’ai compris ça, mon problème c’est que je voudrais aussi adresser le message à la personne qui a rempli le formulaire formidable. Cette personne n’est pas un auteur (donc elle n’a pas d’id) et son email n’existe que dans la réponse n° X au formulaire n° Y, c’est ça que je voudrais récupérer.

      Pierre.

    • Un autre truc qui me turlupine, je ne vois pas comment spécifier un sujet aux mails de notifications traités avec Notifications avancées. Ils partent bien mais sans sujet.

      Pierre.

    • Ta facture ou ta transaction n’est pas lié à la réponse de formulaire (la transaction au moins non ?). Donc tu cherches la réponse de formulaire liée à la transaction lié à la facture (tu as l’id de la facture dans la notif). Et une fois que tu as la réponse, tu cherches le champ avec l’email.

      Apparemment ya l’id de la réponse dans le champ « tracking_id » de la transaction de Bank, d’après le code ici :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/formidablepaiement/trunk/formidablepaiement_pipelines.php#L86

    • Pour le sujet, il me semble qu’il y a plusieurs manière. Soit tu définis un contenu court (soit par le PHP soit avec un squelette) :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/notifications_avancees/trunk/notifavancees_pipelines.php#L432

      Soit dans ton gabarit de contenu mail, avec le plugin Facteur, il est possible d’avoir du semi-html, avec les balises html/title/body et dans ce cas, Facteur va prendre « title » comme sujet, et il faut échafauder un truc autour du texte brut (ce n’est pas ou mal documenté, ce truc là pour l’instant).

      Mais quoique, la deuxième solution n’est même pas forcément censé être cherché, car si ya pas de version « court », normalement il génère automatiquement à partir de la première ligne :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/notifications_avancees/trunk/notifavancees_pipelines.php#L441

      Donc bizarre que t’es du vide et pas au minimum la première ligne… (mais c’est peut-être mal fait, peut-être ya un bug…)

    • Bonsoir,

      Pour le sujet, oui finalement ça prend la première ligne, le bug étant peut-être que si elle est vide, ça la prend quand même ...

      Ensuite j’ai réussi à récupérer l’email dans les formulaires_reponses_champ à coup de sql_select et sql_fetch via effectivement le tracking_id mais ça je l’avais déjà trouvé pour la partie squelette, le doute que j’avais était ou placer ça et savoir si $id me ramenait bien l’id de la facture.

      Vu l’heure il me reste à remercier Rastapopoulos et Polar Oîd pour leurs conseils et leur aide précieuse, désintéressée et patiente, bon week-end à vous !

    Répondre à ce message

  • 12

    J’ai un petit problème : je n’arrive plus à modifier les caractéristiques d’un groupe, je voudrais changer les caractéristiques d’un groupe et je ne peux pas, cela me renvoie systématiquement vers le dernier groupe. Impossible de modifier les autres.

    J’ai fait la mise à jour de Formidable et je suis en SPIP 3.0.21. Je suis sous Firefox, j’ai vérifié sur Chrome même sanction.

    • Je viens de créer un formulaire de test avec deux groupes et divers champs dans chacun. Et je peux bien configurer les options de chaque groupe, leur mettre un titre différent, etc.

      Sinon le constructeur de formulaire est dans Saisies, pas dans Formidable.

    • Je viens de faire la mise à jour de saisies. Le truc, c’est que la barre d’outils remonte en haut du premier groupe.
      Dans mon exemple :
      si je passe la souris sur le groupe « Products », la barre d’outils apparaît sous la barre d’outils liée à « Request ». C’est systématique dès que j’ai 2 groupes. Je vais laisser un message sur Saisies, alors.

    • PS : je ne vais pas poster sur Saisies :

      Saisies
      
      27 mars 2010 – par RastaPopoulos 
    • Je n’ai absolument pas ce comportement, j’ai bien les actions qui sont affichés au bon endroit pour chaque saisie. Tu as désactivé tous les plugins non-obligatoires pour tester uniquement ce que tu veux tester ? Tu as vider tous les caches de SPIP et navigateur ? Il y a forcément un truc de JS ou de CSS qui entre en conflit.

    • Je pense que cela viens plutôt du formulaire en lui même, j’ai supprimé tous les plugins sur un site de test en 3.0.21, vidé les caches SPIP et navigateur, et j’ai le même problème. Les barres d’outils se superposent.

    • J’ai fait le test en important le fichiel yaml dans un autre site. Et effectivement si je fais un nouveau formulaire avec 2 groupes cela fonctionnent. Mais sur mon formulaire importé, niet.

    • Bah donc c’est ton formulaire qui est pété quelque part, dans l’enregistrement en base de ses saisies. Mais je ne sais pas pourquoi… un problème d’identifiant peut-être…

    • « un problème d’identifiant peut-être… »

      C’est ce que je pense aussi. Le fichier yaml a l’air pourtant correct et les identifiants sont #. Je ne vois pas trop. Et ce formulaire est très long. Pourtant, je n’ai pas d’incohérence sur les groupes, dans le code du yaml.

      J’ai une autre question, pourquoi il n’y a pas de classe supplémentaire sur les champs. C’est un peu bloquant car le formulaire est ’lié" à SPIP et quand on utilise Bootstrap, on peut pas utiliser les classes de Bootstrap.

    • bah si, ya un paramètre pour ajouter des classes, dans la plupart des onglets « Affichage »

    • bin oui et non, pas dans les boutons radios.

    • http://zone.spip.org/trac/spip-zone/changeset/95151/_plugins_/saisies/trunk

      S’il en manque, il faut proposer de compléter les fichiers YAML qui décrivent les options des saisies. Dans le code ya généralement une personnalisation de « li_class » pour ajouter des classes sur le bloc englobant tout le champ, et une personnalisation de « class » tout court pour ajouter des classes sur le champ HTML précisément. Mais après pour que ça apparaisse dans le constructeur il faut que ce soit décrit dans le YAML.

      Ceci dit, ce n’est clairement pas la bonne méthode, de devoir en permanence ajouter des classes dans le HTML. C’est pour ça qu’il y a des pré-processeurs (LESS ou SASS) et qu’avec on peut appliquer les mêmes styles que telle classe mais pour une autre classe (en gros dire : ma classe perso « saisie_truc » hérite des styles de la classe « machin » de Bootstrap). Ce qui permet ne ne pas toucher au HTML.

    • Ok merci pour l’explication sur la structure du constructeur.

      Pour le deuxième paragraphe, utiliser du LESS ou SASS sur un petit/moyen projet, c’est lourd et l’utilisation de SPIPR avec lequel j’ai fait quelques sites se révèle lourd par les contraintes de mise en place du design car entre autre utilise Bootstrap 2 avec ses dégradés/ombrés horribles et surtout pas facile à maintenir. Je viens d’adapter le squelette « moulinette » et le résultat est plus efficace. Je n’ajoute pas à tout va des class dans tous les recoins du html, mais je ne voudrais pas réinventer la roue et je veux juste utiliser les class de base de Bootstrap, notamment pour les formulaires.

    Répondre à ce message

  • 3

    Bonjour,

    Config :

    SPIP : 3.1.0 (mis à jour depuis une version 3.0.16)

    Plugins : plusieurs, tous à jour

    Formidable version : 2.9.5

    Contexte : Obtention d’un joli warning en voulant consulter les réponses apportées à un de mes formulaires

    Message d’erreur :

    Erreur SQL 1064
    You have an error in your SQL syntax ; check the manual that corresponds to your MySQL server version for the right syntax to use near ’’ at line 3 SELECT id_formulaire FROM spip_formulaires_reponses WHERE id_formulaires_reponse=

    Squelette :

    plugins/auto/formidable/v2.9.5/formidable_autorisations.php

    Le défaut disparaît après avoir ajouté des guillemets simples autour de ’id’ à la ligne ’3’

    Code avant correction - ligne 242 :

    function autoriser_formulairesreponse_modifier_dist($faire, $type, $id, $qui, $opt){
        if ($id_formulaire = intval(sql_getfetsel(
    			'id_formulaire', 'spip_formulaires_reponses', "id_formulaires_reponse=$id"))) {
    
    		$retour = (autoriser_formulaire_editer_dist($faire, $type, $id_formulaire, $qui, $opt)
    				and formidable_auteur_admin_reponse($qui));
    	}
    	return $retour;
    }

    Code après correction :

    function autoriser_formulairesreponse_modifier_dist($faire, $type, $id, $qui, $opt){
        if ($id_formulaire = intval(sql_getfetsel(
    			'id_formulaire', 'spip_formulaires_reponses', "id_formulaires_reponse='$id'"))) {
    
    		$retour = (autoriser_formulaire_editer_dist($faire, $type, $id_formulaire, $qui, $opt)
    				and formidable_auteur_admin_reponse($qui));
    	}
    	return $retour;
    }

    Espérant que cela puisse servir à d’autres et dans l’attente d’une petite mise à jour du plugin.

    Et très bon plugin bien sûr ;)

    Bien cordialement,

    Raphaël

    • Ça devrait être mieux avec ça (et il ne faut surtout pas de guillemets puisqu’on attend un entier) :
      http://zone.spip.org/trac/spip-zone/changeset/95070

    • Salut,

      Effectivement pour les guillemets, je me suis fait la même remarque mais comme cela faisait disparaître l’erreur et me laissait l’accès aux réponses... et à lire tes corrections, je me rends bien compte que cela ne suffisait pas, et qu’il fallait passer par une ’optimisation’ du code. ^

      Code modifié d’après le spip-zone/changeset et tout baigne !

      Merci Mr Rasta Pop’ ;)

      PS : j’en profite pour relancer l’idée d’ajouter à Formidable ce fameux champ ’joindre’ qui reste la pièce manquante à ce très bon plugin générateur de formulaires.

      Bien cordialement,

      Raphaël

    • Je viens de repérer un autre petit défaut et le signale donc :

      le glisser / déposer d’un champ nouvellement créé fonctionne mal : son déplacement n’est pas pris en compte, après enregistrement bien entendu... il reste en bas (dans le dernier groupe de champs pour être précis).

      En revanche, lorsque l’on passe par la configuration du champ en lui même, là ça fonctionne correctement.

      Raphaël

    Répondre à ce message

  • bonjour,
    depuis mon passage sur la dernier version de formidable j’ai un comportement bizarre sur un formulaire existant. J’avais un mail de confirmation à celui qui répond et une autre personne et simultanément un mail aux destinataires du formulaires.
    Parfois seul le mail de confirmation est envoyé. alors que le formulaire n’a pas bougé ( champs, config etc)

    Un nouveau formulaire n’envoie carrément pas de mail

    Le test du plugin facteur est ok.
    formidable 2.9.5
    api de vérification 1.0.8
    facteur 3.1.3
    saisie 2.5.26
    bonux 3.2.1
    yaml 1.5.2
    la désactivation de YAML désactive formidable oud e bonux

    Même pb en spip 3 et 3.1
    Avez vous une idée merci

    Répondre à ce message

  • 12

    Bonjour ,

    Sur un site spip récemment mis à jour :

    J’aimerais faire remplir un formulaire à des visiteurs , rassembler les données dans un tableau de façon à les exploiter pour des graphiques : jpgraph ou charts.js .

    Tout cela est peut-être vague mais j’aurais voulu savoir si quelqu’un à des pistes à m’indiquer pour voir vers quelles solution me tourner ...

    D’avance merci .

    • Bé une fois récolté il faut que tu boucles dans (FORMULAIRES_REPONSES) et (FORMULAIRES_REPONSES_CHAMPS) dans ton squelette, et après tu fais ce que tu veux suivant ce qu’attendent comme entrées les librairies choisies.

    • Merci RastaPopoulos ,

      Je pense que la réponse s’adresse à un initié , j’essaie de comprendre :

      Bé une fois récolté Où sont les réponses , dans une table de la base de données , il faut donc y accéder avec des trucs bizarres : du sql , du php , ... :( ?
      il faut que tu boucles dans (FORMULAIRES_REPONSES)
      Je dois donc me servir d’une « boucle spip » , j’y connais rien , j’utilise seulement les plugins sans jamais les modifier et je repompe parfois du html pour rajouter de petits inserts sur des sites , c’est tout ce que je sais faire .
      Ça c’est dans la base de données : (FORMULAIRES_REPONSES) ?
      et (FORMULAIRES_REPONSES_CHAMPS) dans ton squelette,
      Il faut que je change le squelette d’une page genre article.html ?
      et après tu fais ce que tu veux suivant ce qu’attendent comme entrées les librairies choisies.
      Déjà il faut que je comprenne le début : où sont les données et sous quelle forme pour pouvoir les mettre dans un tableau ! Les données que je veux récolter sont des nombres décimaux et après je veux faire des graphiques basiques : camemberts , histogrammes .

      Merci de ta réponse mais je suis loin de comprendre tout : je suis un utilisateur de spip depuis 8 ans , mais , comme un imbécile , je n’ai jamais commencer à me documenter sur les boucles , etc ...

      Je vais essayer d’aller courageusement voir dans la BDD , mais comment lire la BDD , exploiter les valeurs ???

    • Je viens de voir avec phpMyAdmin qu’il y a effectivement des tables du genre (FORMULAIRES_REPONSES) dans la BDD , mais de là à être capable de les exploiter ...

      Je cherche des trucs sur les boucles et la BDD ...

    • Je viens de trouver ça : http://contrib.spip.net/Boucler-sur-un-tableau-un-compteur
      On y donne cet exemple de boucle :

      <BOUCLE_t(TABLEAU){var=tables_principales}>
              <BR>- #CLE => #VALEUR
              <BOUCLE_tt(TABLEAU){valeur}>
                      <BR>-- #CLE => #VALEUR
                      <BOUCLE_ttt(TABLEAU){valeur}>
                              <BR>--- #CLE => #VALEUR
                      </BOUCLE_ttt>
              </BOUCLE_tt>
      </BOUCLE_t>

      C’est peut-être ce qu’il faut que j’utilise mais tout ça est encore mystérieux ...

      Je ne sais pas si ça va aider , voici un peu plus de détails :

      Mon formulaire a l’air de générer trois « trucs » : @input_1@ , @input_2@ ...
      je pose trois questions et j’attends deux nombres décimaux et un pseudo (pour l’instant ...)
      Comment récupérer ces nombres à chaque fois qu’un visiteur rempli un formulaire et génère donc deux nombres décimaux plus une chaîne de caractères (son pseudo ) :
      @input_3@
      Pseudo
      @input_1@
      Kilométrage mensuel total
      @input_2@
      Endurance active

      je continue de chercher , merci d’avoir la patience de suivre !

    • Oulaaaa bah oui mais non : si effectivement tu ne sais pas utiliser le langage de template de SPIP (les squelettes avec des boucles et des balises), c’est bien sûr la première chose à apprendre…
      Le chapitre :
      http://programmer.spip.net/-Ecriture-des-squelettes-

      Et ensuite c’est pas fini car tu parlais plus haut d’utiliser les valeurs pour générer des graphes, donc forcément ça veut dire apprendre Javascript aussi, au moins des bases, pour savoir utiliser les librairies que tu voulais (cf leurs docs respectives), et « donner » les valeurs récupéré d’un formulaire dans ce que ces libs attendent en entrée.

    • Je n’ai rien contre javascript mais je fais de très beaux graphes avec jpgraph ou charts.js comme je l’écrivais plus haut !

      Je regarde ces boucles ...

    • Je connais un peu python , html mais comme peut-être certains , j’ai rechigné à apprendre "un autre langage’ spécial spip ...

      C’est un tort car j’ai toujours beaucoup utilisé spip ... bien sûr j’aurais rêvé de trouver un plugin « tout frais pondu » qui me serve à faire l’opération :
      1) Un visiteur saisit 1 pseudo + deux décimaux
      2) Je rassemble ça dans un tableau
      3) j’affiche mon graphique

    • Je cherche à faire ce qui est décrit ici

      Le site de la Journée du 20 Mars de l’Organisation internationale de la Francophonie gère des « événements » renseignés par les visiteurs. Une originalité ici est que les différentes informations concernant ces événements sont ensuite exportés, via des squelettes, au format Excel, à destination des administrateurs. Il s’agit là de squelettes qui fabriquent directement du PHP, utilisant un script PHP qui permet de fabriquer des fichiers au format .xls. C’est donc du PHP fabriqué dynamiquement dans des squelettes SPIP, permettant l’export direct de fichiers Excel.

      Tout ça est difficile à suivre ... ,, je regarde timidement la doc sur les boucles spip ...

      Merci RastaPopoulos .

    • Il n’est pas forcément judicieux de suivre un truc qui date de 7 ans.

    • kristoff23

      Oui , je suis déjà sur autre chose :

      Mon but :

      1) Un visiteur saisit 1 pseudo + deux décimaux
      2) Je rassemble ça dans un tableau
      3) j’affiche mon graphique

    • kristoff23

      Je lis ceci par exemple :

      - Pour afficher les réponses, mais c’est déjà documenté :


      [

      (#VALEUR)

      ]

      Le problème que je rencontre souvent ( je ne suis pas très doué) :
      Où placer le code indiqué ?
      Dans une page bidule.html , mais laquelle et souvent je renonce et je contourne en faisant différemment ..

    • kristoff23

      Zut on ne peut pas éditer le message ? , j’ai oublié de mettre code !!

      Je réécris :

      -  Pour afficher les réponses, mais c’est déjà documenté :
      
      <BOUCLE_spip_formulaires_reponses(FORMULAIRES_REPONSES_CHAMPS){id_formulaires_reponse}{nom=input_1}>
      [<p>(#VALEUR)</p>]
      </BOUCLE_spip_formulaires_reponses>

      Le problème que je rencontre souvent ( je ne suis pas très doué) :
      Où placer le code indiqué ?
      Dans une page bidule.html , mais laquelle et souvent je renonce et je contourne en faisant différemment ..

    Répondre à ce message

  • 2
    Alexandre FIEY

    Bonjour,
    Est-ce que quelqu’un sais si un champs upload de document est prévu du développement de ce plugin ? (soit via Saisies ou non).
    C’est une fonctionnalité qu’il manque cruellement à ce superbe générateur de formulaire !
    Cdt, Alexandre

    • Pas de nouvelles sur ce point ? Un tel champ existe sur le formulaire de contact avancé.

    • J’abonde, c’est terriblement dommage. Je sais bien que les plugins spip sont des initiatives personnelles volées au précieux temps libre, et j’en sais particulièrement gré aux contributeurs en général et à RastaPopulous en particulier (c’est sans doute le seul plugin que j’installe d’office à chaque nouveau site), mais, indépendamment de tout ce qu’on pourrait ajouter à celui-ci, de plugin, l’upload de fichiers le rend véritablement incomplet, et il semble que nous soyons nombreux à attendre Noël.

    Répondre à ce message

  • 1
    Brice Boulangeot

    Bonjour,
    Merci beaucoup pour cet excellent plugin. Je voulais savoir si il était prévu bientôt ou jamais d’intégrer un champ de type upload de fichier ? Je sais que la question a été posée plus tôit cette année mais il n’y a pas eu de réponse.
    Merci d’avance

    • Natacha Courcelles

      Bonjour et bonne année 2016 à tous

      je bosse sur un projet que j’aimerai bien mener avec Spip (sinon c’est Wordpress :-(
      j’ai besoin de faire un formulaire si possible en étape et téléchargement de cv et lm en pdf

      alors prévoyez vous upload de fichier ?

      merci
      Natacha Courcelles

    Répondre à ce message

  • Bumborass

    Bonjour,

    J’ai construit un formulaire de contact. Je voudrais savoir, vu que j’ai activé des champs obligatoires, s’il y avait possibilité de retirer le fameux « info obligatoire 02 ».

    Merci de votre attention,
    Bonne journée.

    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