Formidable, le générateur de formulaires

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

Introduction

Historiquement, deux plugins avaient déjà été développés précédemment pour gérer des formulaires :

  • Forms &Tables, qui n’a pas été complètement porté pour SPIP 2.
  • et spip-formulaire créé par artego mais qui n’était plus maintenu.

La question s’est donc posée : construire sur la base d’un des deux plugins ou repartir de zéro ?
Form &Table, très complet pour les utilisateurs, présentait l’inconvénient d’avoir un côté “fourre-tout” qui le rendait difficilement modifiable et difficile à personnaliser par les dévs.

Il a finalement été décidé de repartir de zéro pour proposer quelque chose:

  • de plus facile à utiliser pour les utilisateurs d’une part,
  • mais aussi de plus facile à personnaliser pour les développeur⋅euses.
    Avec le parti pris de se baser de préférence sur plusieurs petits plugins spécialisés et de tirer parti de la nouvelle norme CVT.

Interface utilisateur

L’utilisation basique de l’interface est abordée dans ce screencast : Mon premier formulaire pas à pas : c’est Formidable !

Appeler mon formulaire

Vous devez appeler le formulaire ayant le nom “formidable”, en lui passant en paramètre l’identifiant de votre formulaire.

Dans un contenu
Utilisez le modèle <formulaire> classique : <formulaire|formidable|id=34> ou bien <formulaire|formidable|id=contact>

Dans un squelette
#FORMULAIRE_FORMIDABLE{34} ou bien #FORMULAIRE_FORMIDABLE{contact}

Afficher les résultats du formulaire

Dans un contenu
Utilisez le modèle <formulaire_analyse|id_formulaire=34>

Pré-remplir dynamiquement les champs d’un formulaire

À noter, vous avez la possibilité de surcharger dans l’appel, les valeurs par défaut des champs de votre formulaire. Pour cela, vous devez passer un tableau de nom=>valeur en deuxième paramètre. Vous pourrez trouver les noms de vos champs dans l’aide-mémoire situé sur la page de configuration des traitements.

Dans un contenu
Le tableau de valeurs dans un paramètre defaut sous forme d’une suite de chaînes “clé,valeur” séparée par des virgules :
<formulaire|formidable|id=contact|defaut=hidden1,valeur,input_5,autrevaleur>

Dans un squelette
Le tableau en deuxième paramètre :

#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}}

Pré remplir les champs depuis une ancienne réponse

Si les réponses sont enregistrées, on peut passer en troisième argument un identifiant de réponse.

#FORMULAIRE_FORMIDABLE{contact,'',23}

pour modifier la réponse 23.

Champs oui-non et case unique

Pour rendre obligatoire la réponse “oui” à un champ de type oui-non ou case unique (pour la validation de conditions d’utilisation par exemple), il faut simplement rendre le champ obligatoire.

Courriels de notification

Une option des traitements proposés permet d’envoyer un mail de notification automatiquement, à chaque saisie d’un formulaire.

Le squelette par défaut employé pour la mise en forme de ces mails est plugins/formidable/notifications/formulaire_email.html. Vous pouvez le copier dans le répertoire ’notifications’ de votre squelette et l’y modifier à votre guise. Cette modification vaudra pour tous les formulaires.

Pour utiliser un squelette spécifique pour les mails de notification de l’un seulement des formulaires définis avec Formidable, il suffit d’ajouter son squelette dans le répertoire ’notifications’ de votre dossier squelettes, mais en ajoutant l’identifiant.

IDENTIFIANT étant l’identifiant du formulaire défini dans Formidable, les squelettes doivent se nommer :
formulaire_IDENTIFIANT_email.html pour le mail aux destinataires
formulaire_IDENTIFIANT_accuse.html pour l’accusé de réception du visiteur

Conservation des IP

Les adresse IP des personnes répondant aux formulaires sont stockées en base de donnée. Depuis la version 1.5 (SPIP 3) / 0.7 (SPIP < 3), elle sont automatiquement hashé, de manière à ce que l’IP ne soit plus reconnaissable, au bout de 124 jours (environ 4 mois).

Pour changer ce délai, vous pouvez redéfinir la constante _CNIL_PERIODE dans votre fichier mes_options.php.

Par exemple :

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

756 discussions

  • Bonjour, existe-t-il un plugin qui permettrait d’intégrer le contenu des réponses à un formulaire à salesforce ou équivalent ?

    Reply to this message

  • 21

    Bonjour

    Un très soucis depuis quelques jours : les données des formulaires se mélangent d’une réponse à l’autre.

    J’utilise un formulaire pour que mes clients me fournissent des infos concernant leur projet. Et bien, les données du client précédent sont carrément affichées dans le formulaire du client suivant. Ce sont des données confidentielles. Mes clients perdent confiance et nous nous mélangeons les pinceaux dans les projets.

    C’est arrivé il y une semaine pour un client. Je pensais à un BUG transitoire et exceptionnel. Mais cela vient de se reproduire sur plusieurs clients.

    • Heu... peut être un bug de votre côté sur la manière dont vous appeler les formulaires en disant de reprendre les anciennes données lorqu’un client veut modifier ses données, mais il y a pas de raison que cela se produise.

      Donc deja

      1. Quel est la configuration du formulaire ?
      2. Comment l’apperlez vous

      Et surtout : avec vous mis à jour formidable récemment. Cela permettrait de detecter une éventuelle regression.

    • Merci pour l’aide

      La configuration :
      -  Enregistrer les résultats du formulaire dans la base de données
      -  modération a posteriori
      -  Modifiable : Les visiteurs peuvent modifier leurs réponses après coup.
      -  Identification : Par cookie (identifiant aléatoire, ne stocke aucune information personnelle)

      Appelé dans le texte d’un article :

      <formulaire|formidable|id=ficheprojet>

      J’étais sur la version 4.0.7. Je viens de faire la mise à jour vers 4.6.2.
      Donc très en retard, mais c’est inquiétant que le bug survienne subitement sans mise à jour préalable.

    • Donc tu étais sur la 4.0.7 au moment où tu avais le bug, et tu viens juste de passer en 4.6.2 ? ou bien tu étais en 4.0.7 et c’est en passant en 4.6.2 que tu as eu le bug ?

    • Le bug était avec la 4.0.7.

      J’ai mis à jour vers 4.6.2 en lisant votre message. Pour le moment, je ne peux pas dire si le bug est toujours présent ou pas. Il n’y a que mes clients qui peuvent me le dire. Je reviendrai ici si besoin.

    • Des nouvelles sur ce problème ?

    • Bonjour Maïeul, merci pour le suivi.

      Le bug ne s’est pas reproduit depuis.

      Vu l’étrangeté, je me demande si il n’est pas lié à un manque d’espace disque sur le serveur ? cela m’arrive régulièrement ; des logs et des caches qui grossissent jusqu’à saturer le disque. Cela provoque des trucs bizarres. Peut-être que APACHE s’embrouille dans les fichiers de sessions, faute de ne pouvoir en créer de nouveau. Du coup, mixe entre les visiteurs.

      Il se trouve que c’est arrivé à la même période.

      Ni SPIP, ni FORMIDABLE ne seraient en cause si cette hypothèse est avérée.

    • Bonjour Maïeul

      Le BUG se reproduit à nouveau, et de façon quasi-systématique. depuis plusieurs semaines.

      Je pensais initialement un espace disque insuffisant. Mais beaucoup plus d’espace depuis 2 mois. Donc c’est autre chose.

      Pour rappel :
      -  des clients qui accèdent à des données d’autre clients, dans leur formulaire pré-rempli
      -  des fiches qui disparaissent du back-office. Pourtant, on avait bien reçu copie des données via email.

    • bah heu là franchement c’est dur à dire. Tu es le seul qui a cela...

      Je ne reproduis cela nul part. Et les données qui disparaissent de l’espace privé > est ce que tu les a eu une seule fois dans l’espace privé ? que donnent les logs apache + formidable ?

    • et que donnent les logs mysql aussi ?

    • dis voir, dans ta structure de squelette, tu n’aurais pas par hasard des #INCLURE à la place de <INCLURE> ?

    • dis voir, dans ta structure de squelette, tu n’aurais pas par hasard des #INCLURE à la place de <INCLURE> ? est-ce que tu as des plugins qui jouent sur le cache ?

    • OUI j’ai de nombreux #INCLURE. J’ai toujours pensé que cela permettrait au serveur de répondre plus rapidement, quitte à avoir un cache plus volumineux.

      Faut-il que je passe sur <INCLURE> ?

    • oui, on évite les formulaires au sein des #INCLURE; il vaut mieux des <INCLURE>, ca peut poser des problèmes par ailleurs (mais c’est à niveau trop complexe pour moi pour savoir a priori si c’est la cause de ton souci !). En tout cas, essai, et revient après ces essais.

    • Même si ça ne résout pas ce point là, oui de toute façon il faut transformer en , la balise #INCLURE doit être utilisée avec beaucoup de parcimonie, et ça ne fait pas du tout pareil, notamment il ne peut y avoir de choses dynamiques à l’intérieur.

    • OK j’ai planifié le remplacement des #INCLURE.

      Et pour les #CACHE, c’est pareil, faut éviter, ou bien ?

    • Une personne experte en compilation et formulaire SPIP me murmure par IRC que oui, la cause du bug c’est à 99,9% de chance les #INCLURE parents.

    • où en tu sur ce bug ?

    • MERCI Maïeul pour ton suivi.

      Aucun client ne nous a plus remonté ce bug, c’est-à-dire le mélange des données de formulaires entre client.

      Par contre, on a souvent des clients qui indiquent que les données de leur formulaire ne sont pas ré-affichées quand ils reviennent dessus. Pourtant, j’ai bien sélectionné “Modifiable : les internautes peuvent modifier leurs réponses après coup.” avec identification par Cookie.

    • alors là c’est dur à savoir, faudrait voir si le cookie a été effectivement posé chez le client...

    • Bonjour Maieul

      On est en train d’essayer de remplacer tous les #INCLURE du code. Il se trouve que cela n’est pas toujours possible. Exemple : #SETtoto, ne peut pas fonctionner.

      Chose remarquable, on a le cas de figure que tu dis, c.a.d un #INCLURE dans un formulaire, dans le code du plugin SAISIES, fichier _base.html :
              [(#INCLURE{fond=saisies/#ENV{type_saisie},env,nom=[(#ENV{nom}|saisie_nom2name)], disable=#GET{disable},readonly=#GET{readonly},describedby=[(#ENV*{explication}|?{[explication_(#ENV{nom}|saisie_nom2name)]})]})]

    • 1. Pas compris ton cas de set/get, il faudrait être plus précis
      2. Oui saisie à des #INCLURE et pas des <INCLURE>, on a projet de changer cela peut être un jour, mais cela n’a pas d’importance pour le problème qui te concerne, car ce qui est compte c’est tout ce qui est “avant” l’apelle à #FORMULAIRE_XXX

    Reply to this message

  • 14

    J’ai un problème d’affichage du bouton submit après mise à jour de Formidable 4.14.3 - stable à Formidable 4.15.0 - stable.

    Le style du bouton ’est plus pris en compte.

    <button type="submit" class="submit" name="submit" value="1">Envoyer</button>
    On voit juste “envoyer” sans style

    dd

    • Formidable en lui même ne style pas. C’est
      par contre ce qui est vrai c’est qu’on a remplacé un input par un button. peut être est-ce du côté de tes styles qu’il faut corriger (styles qui auraient du utiliser uniquement la classe).

    • OK merci je vais regarder même si je ne comprend pas trop où est le problème vu que je n’ai pas modifié les fichiers du plugin formulaire par défaut.
      Et ce qui est bizarre c’est que "<multi>[fr]Envoyer[en]Submit</multi>" dans “Texte du bouton de validation” des options globales du formulaire n’est plus prix en compte non plus. Il s’affiche tel quel.

      dd

    • hum, tu es sur d’avoir une version de formidable et saisies à jour ?

      quelle version de spip et de php ?

    • Le site est avec :
      SPIP 3.2.11 [24473]
      Saisies pour formulaires 3.54.1 - stable
      Formidable 4.15.1 - stable
      PHP Version 7.3.27
      (même problème avec PHP Version 7.3.17)

      En local :
      avec PHP Version 7.4.3 et Formidable 4.14.3 - stable
      c’est bon

      mais avec Formidable 4.15.1 - stable
      ce n’est pas bon

      dd

    • hum, oui pour le chaine multi, il y avait bien un bug.

      Peux tu appliquer manuellement ce changement https://git.spip.net/spip-contrib-extensions/saisies/commit/69a98c0 ?

    • Oui merci ta modif remets d’aplomb le texte multi du bouton.

      Et sinon j’ai recalé mon formulaires.css pour prendre en compte les changements de classe du plugin. Il faut l’adapter selon le type de formulaire ; par exemple :

      .formulaire_formidable p.boutons button.submit,
      .formulaire_newsletter p.boutons input.submit  {... 
       }

      M’enfin mon cas est peut-être spécial vu que c’est un squelette qui vient de html5up.

    • Le mieux serait que tu ne cible pas spécifiquement le type, mais uniquement la classe

    • Oui ce serait plus simple mais selon le type de formulaire et son emplacement dans le site je n’ai pas toujours les mêmes règles.

    • une règle

      p.boutons .submit ne ferait-il pas l’affaire ? voire même .boutons .submit

    • Bonjour, je ne comprends pas ce qu’il faut modifier pour pouvoir traduire le bouton envoyer. Pourriez-vous m’indiquer le chemin exact du fichier svp ?

    • Bonjour,

      il aurait fallut commencer un nouveau sujet, plutot que d’en poursuivre un ancien.

      Mais du coup tu a 2 solution :
      -  au cas par cas, tu peux modifier formulaire par formulaire le texte du bouton d’envoi en cliquant sur “configurer les options globales” au moment où tu configure le champ
      -  soit surcharger la chaine de langue “bouton_enregistrer” et / ou “bouton_valider” dans ton fichier local_fr.php (on a changé par erreur la chaine de langue utilisée dans une version récente, et je ne serais pas étonné qu’on revienne en arrière)

    • Bonjour, merci pour votre réponse.
      En fait, si j’ai écrit ici c’est parce que je rencontre le même problème avec la balise multi . Elle ne fonctionne pas pour le bouton “Envoyer”.
      Je faisais référence à votre lien : https://git.spip.net/spip-contrib-extensions/saisies/commit/69a98c0

    • ah oki !

      alors

      1. Soit vous attendez demain quand j’aurais publié la nouvelle version de saisies
      2. Soit vous faites vous même les modifs “à la main” : dans plugins/auto/saisies/v<jenesaispascombiencadependdevotreinstall>/formulaires/inc-saisies-cvt-boutons.html, vous appliquez la modification qui est décrite dans le lien (à savoir mettre une asterisque quelque part)

    • Super merci beaucoup. Ca fonctionne. :)

    Reply to this message

  • 2

    bonjour

    cela faisait un moment que je n’avais pas utilisé formulaire, mais le réinstallant sur un nouveau site, j’obtiens ce message dans la partie privée

    Erreur SQL 1054
    Unknown column 'vu' in 'where clause'
    SELECT * FROM spip_formulaires_liens WHERE vu="oui" AND objet='newsletter' AND id_objet=644

    à propos du squelette /spipr/ecrire/action/editer_liens.php

    merci d’avance d’une piste
    spip3.3 avec soyezcreateur...
    pam

    • essaie une reéparation de la table dans maintenance technique. Je pense que tu a été victime d’un bug d’install (nitamment si tu es chez OVH)
      (note : spip 3.3 est une version non officielle de spip...)

    • merci
      3.3 c’était une erreur, je suis bien en 3.2...
      pam

    Reply to this message

  • 6

    Bonjour,

    Depuis quelques temps, j’ai un souci avec la dernière version du plugin, je suis en Spip 3.2.9 et quand je teste mes formulaires, en cliquant sur le bouton envoyer, il boucle et me donne une erreur : Gateway Timeout.

    J’ai désinstaller le plugin, puis je l’ai réinstallé, sans succès.

    J’ai également recréé un nouveau formulaire mais ça me donne la même chose. Si vous avez une idée pour résoudre ce bug, je suis preneur. Merci d’avance.

    • version de PHP ? de formidable? de saisies?

      quelle version marchait avant ?

    • Formidable 4.15.1
      Saisies pour formulaires 3.54.1
      Php 7.3

      Je me souviens plus.

    • bizarre, c’est ce que j’utilise et je n’ai aucun souci.

      De deux hypothèses
      1. Il y a quelque chose spécifique chez vous qui gêne
      2. Il y a quelque chose spécifique dans votre formulaire qui gêne.

      Pouvez vous

      1. Regarder les logs de PHP/apache
      2. M’envoyer un formulaire au format .yaml (monprenom@monprenom.net)

    • Merci pour votre retour !

      Je viens de vous envoyer l’export et je regarde dans les logs

    • le souci était lié à une mauvasie configuration de facteur.

    • merci encore Maïeul !

    Reply to this message

  • 2

    Bonjour,

    Le bouton « envoyer » n’apparaît plus sur mes formulaires et une erreur « Aucun squelette formulaires/inc-saisies-cvt-boutons n’est disponible... » apparaît.

    Je vois que le fichier /formulaires/inc-formidable-boutons.html fait effectivement appel à un fichier inc-saisies-cvt-boutons, mais que celui-ci est introuvable, non seulement dans cette version 4.15.1, mais aussi dans des versions plus anciennes que j’ai consulté : 3.49.1, 2.15.11, 1.9.13 et 0.9.2.

    Je précise que ce bug survient pour de vieux formulaires. Si j’en crée un aujourd’hui, le bug n’apparaît pas. J’aimerais cependant ne pas perdre les réponses liées à ce formulaire.

    Comment pourrais-je résoudre ce problème ?
    Merci.

    • le fichier en question est fournie avec le plugin saisies. Met le à jour (même si normalement cela devrait être bon, car les modifications de formidable ont impliqué une hausse des dépendance à saisie)

      si ton pb n’apparait que sur un formulaire ancien et pas sur un nouveau, c’est étrange, mais ca veut dire que le fichier est présent (sinon le nouveau ne s’en sortirait pas).

      vide ton cache

    • Ah super, c’était bien ça : j’avais une mauvaise version du plugin Saisies (alors que cvt ne m’indiquait pas de mise à jour possible de ce plugin, mais c’est un autre problème). Merci !

    Reply to this message

  • 12

    bonjour,
    J’ai du simplement enlever le formulaire de la page attaquée afin d’être tranquille, suite à de nombreuses attaques (20 remplissage par jour) de mes formulaires protégés par “Nospam”, cet anti-spam qui n’embête ni l’utilisateur ni les robots qui changent d’adresse toutes les minutes.

    Je me demande comment intégrer “FB antispam” dans Formidable ? Pour l’instant les robots n’arrivent pas à faire les opérations graphiques demandées par ce dernier dans les forums.

    Qu’en pensez-vous ?

    • Le mieux serait de rapporter cela à l’auteur de nospam.

      Nous n’envisageons pas d’assurer une compatbilité avec FBantispam, donc si vous voulez le brancher, ce sera à vous de chercher comment (en tout cas personnellement je ne prendrais pas une seule minute de mon temps bénévole pour cela).

      Cela étant les spams de formulaire étant souvent des liens, une solution possible est d’interdire les messages avec trop de lien. Ce que fait realet via les règles de verification en regexp.

      https://git.spip.net/spip-contrib-extensions/formidable/issues/63

      autre solution : si vous n’utilisez pas les afficher_si, utiliser la fonction d’encryptage des champs de nospam.

    • Merci bien de votre réponse.
      je vous avoue ne pas avoir vu le test que vous appelez en technicien “regexp” : donc en expliquant pour les autres : dans “configurer les champs” sous Validation>type de validation>expression régulière avec une coche pour la négation -
      bien fait merci, mais il va falloir décrypter son usage avec php... (je n’y connais rien)

      J’ai choisi pour le moment “d’offusquer” globalement avec le cryptage global sous nospam en mettant dans le fichier mes_options.php:

      define('_SPAM_ENCRYPT_NAME', true);

      je vais voir son résultat ce jour et ensuite passerai à la négation d’expression dans le champs texte si nécessaire.
      Merci encore des solutions et bon Dimanche !

    • oui regexp est un raccourci pour expression regulière.
      Dans le lien que j’ai mis, RealEt explique tout en bas quel regepx il utilise.

    • oui par ex :
      /.*(http:|https:|www\.|@).*/i
      merci.

    • bonsoir,
      je suis au regret de vous dire que rien n’a d’effet :
      -  ni l’offuscation,
      -  ni les validations de formulaire : deux demandées : champ téléphone avec 6 caractères mini :si on en met 1 : cela passe, et dans le champ texte, avec ce masque ci-dessus, si on met “http”, cela passe tranquillou.
      J’ai certainement oublié quelque chose ? Merci .

    • très certainement, mais là comme ca je ne peux pas dire.
      version de spip ? de saisies? de formidable? de verifier? export yaml du formulaire ?
      site de demo ?

      bref...

    • Bonjour,
      oui bien sur : ce sont des dernières versions en général : spip 3.2.11,
      Formidable 4.15.1 ,Saisies pour formulaires 3.54.0 (de cette nuit, retesté).NoSPAM 2.2.0
      vérifier ? API de vérification 1.16.0
      Alors site de démo, il y a une bonne nouvelle, j’ai fait encore plus de tests : j’ai celui de l’asso que je gère bénévolement (j’ai aussi ma part) , qui fonctionne .. et donc j’ai fait ce matin des tests sur celui de ma petite société dont certains formulaires ne vérifient rien du tout et bien sûr d’autres formulaires vérifient bien ...ah
      La différence entre le formulaire qui vérifie les champs et celui qui ne les vérifie pas est ..; multi
      Les deux sites sont multilingues (FR/GB) et sur le pro, afin de ne pas refaire 2 fois les mêmes formulaires (paresse et simplification), vu que cela s’affichait bien (super), j’ai mis dans chaque champ en label les valeurs en multilingue comme c’est instruit sur Spip : par ex pour demander l’email :

      <multi>[fr]Votre email[en]Your email</multi>

      sans vérifier, car avant ce passage international, cela bloquait bien si on ne mettait pas un email correct (je ne parle même pas des vérifications complexes de contenu de texte)
      et donc le tag “multi” suffit pour ne pas vérifier que la valeur saisie est bien un email (on tape “fff” et cela passe tranquilou),
      donc de même pour le titre du form, les messages, les explications , les valeurs possibles .. tout traduit. Voici le form exemple en pj pour vos tests.
      Au plaisir de vous aider et merci.

    • hum, si le multilinguisme bloque la verification (si j’ai bien compris) c’est très embetant.
      mais il manque la Pj.

      vous pouvez me l’envoyer directement a monemail@monemail.fr

    • oup, je veux dire monprenom(sanstrema)@monprenom(sanstrema).net

    • Et donc je viens de regarder. Le problème ne vient pas des chaines de langues, mais du fait que vous avez activé le multi etape SANS pour autant mettre au moins 2 étapes (aka 2 groupe de champ).

      Une optimisation trop rapide de mon côté faisait que ce cas .... zappait les verifications. C’est corrigé. Mais comme c’est un cas relativement rare, je ne releaserai pas avant ce week-end, pour éviter les multiplications des release.

      Donc : désactive le multie étape (ou met des vrais étapes) et tout remarchera dans l’ordre.

    • bonsoir,
      merci de votre réaction rapide. Le muti-étape : voulez-vous parler de “Formulaires de paiement 1.1.3” ? car effectivement dans le form de contact, je ne l’active pas .
      Comment le “déactiver” SVP (je n’ai pas trouvé l’option)? Est-ce par formulaire ou globalement je déactive “Formulaires de paiement”?merci

    • ah j’ai trouvé , c’est en tête du form > configurer les champs> configurer les options globales
      merci , c’est fait - on verra le résultat demain matin, s’il y a encore du spam. MERCI !

    Reply to this message

  • 3

    Je cherche à ajouter un identifiant unique dans un champ visible dans un formulaire.
    Problème je ne sais pas du coup comment faire cela.
    Serait-ce possible d’ajouter l’ID de la réponse dans un formulaire ?

    Reply to this message

  • 5

    Hello,
    Est-ce qu’il serait envisageable que l’option “Effacer régulièrement les résultats les plus anciens” affecte tous les résultats ?
    J’ai remarqué que les réponses au statut “proposé” ne sont jamais effacées ce qui peut poser problème pour la conservation des données personnelles, voire la taille de la base..

    merci.

    • je viens de regarder le code, et il n’y a rien qui test un quelconque statut des réponses. Donc tu dois avoir un autre problème chez toi.

    • J’essaie de trouver ce qui cloche.
      Ce qui est sûr c’est que cette incohérence se retrouve sur plusieurs sites (SPIP 3.2.11 [24473] / Formidable 4.14.4 - stable )

      Après rien n’est sûr .. :

      Est-ce que c’est géré par un cron ?
      Il y a sur la page ?exec=job_queue

      Tâche CRON formidable_effacer_enregistrements (toutes les 86400 s) | formidable_effacer_enregistrements(1618602334)

      Ce qui doit correspondre à 24h. Mais ce ne doit pas être ça puisque chaque formulaire peut avoir une config différente.
      J’ai dans ma config d’un formulaire : “Nombre de jours avant effacement : 365” et les réponses de plus de 2 ans sont toujours là.

      Je me souviens avoir eu un décalage du au délai de hashage des IP (qui du coup remettait le décompte à zéro), mais là c’est quand même étrange sur plusieurs années.

      dd

    • toutes les 24 heures on recherche les enregistrement trop vieux.

      regrde plutot du côté de mysql.log

    • Je n’ai rien dans les logs.
      Après quelques jours d’attente pour tests il semblerait que
      ticker “Ne pas conserver l’identifiant de la personne connectée.”
      et ne pas ticker “Enregistrer les IPs (masquées après un délai de garde)”

      permette l’effacement progressif des réponses au-delà d’un délai.

      Mais j’ai encore des réponses gardées bien au-delà du délai de 180 jours.

      dd

    • heu “ticker” ? connais pas ce verbe :p

      ca va être compliqué de dire ce qu’il en est en fait avec le peu d’info que tu nous fournis. Mais ce que je peux te dire c’est qu’on calcule l’age à partir du champ “maj”

    Reply to this message

  • 7

    Bonjour à tous, je suis sous Spip 3.2.11 et j’ai voulu mettre à jour Formidable : la version 4.14.3 m’a fait complètement planter mon site.
    J’ai mis du temps à trouver le plugin fautif, mais c’est bien Formidable.
    Heureusement, vous avez laissé les anciennes versions sur la page des plugins : je suis redescendu à Formidable 4.13.2 et tout refonctionne correctement.
    Lorsque j’activais Formidable 4.14.3 je me retrouvais avec une page blanche (y compris la page d’admin)
    Merci !
    Eric LM

    • oui, il y a visiblement un bug sur les vieilles versions de PHP, mais je n’arrive pas juste en lisant le code à comprendre quoi. Et impossible de reproduire.

      Si vous m’envoyer un accès à un site de test sur votre hebergeur, avec accèsftp, je pourrais regarder...

    • Si page blanche, ça veut dire erreur fatale PHP. Il faudrait activer l’affichage des erreurs sur un site qui a le problème pour déjà savoir ce que PHP en dit (quelle erreur dans quel fichier)

    • Oh là là... C’est un site que j’ai récupéré, et je n’ai pas la main sur la config PHP. Et effectivement, on est en 5.5 !!!
      Merci pour le retour. Je vois avec le client pour qu’il fasse évoluer cela dans son interface OVH.
      Bonne soirée !

    • Comme je disais, si j’avais un accès (en privé) à un site spip sur le serveur concernée, je pourais sans doute debuger (aussi : si on a les message d’erreur !!!)

    • Euh... le site est en fonctionnement, il n’est pas du tout en test. Je veux bien te passer tous mes codes d’accès, y compris FTP, mais je suis un peu hésitant...

    • non, non, ne le fais pas. C’est si jamais c’était simple pour toi de monter un autre site avec un compte ftp dédié, chez le même hebergeur.

      Mais sinon le plus simple reste encore d’envoyer le message d’erreur... https://www.spip.net/fr_article4453.html#Page-blanche

    • c’est corrigé dans la v4.14.4

    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 / PostgreSQL
  • 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 apparait.

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