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

761 discussions

  • 1

    Bonjour,
    Pour la version 4.15.2
    La définition des numéros de version des dépendances me paraissent étranges, les braquets fermantes sont à l’envers:

    <necessite compatibilite="[3.3.8;[" nom="spip_bonux"/>
           <necessite compatibilite="[3.53.3;3.*.*]" nom="saisies"/>
    <necessite compatibilite="[1.12.0;[" nom="verifier"/>
    <necessite compatibilite="[1.5.2;[" nom="yaml"/>
    <necessite compatibilite="[3.6.2;[" nom="facteur"/>
    <necessite compatibilite="[1.6.1;[" nom="nospam"/>
    <utilise compatibilite="[1.5.0;[" nom="collectionjson"/>
    <utilise compatibilite="[1.23.3;[" nom="cvtupload"/>
    <utilise compatibilite="[3.1.0;[" nom="corbeille"/>

    Cela résulte en une mise à jour impossible vers la 4.15.2 car impossible de mettre à jour la dépendance ...

    Reply to this message

  • 1
    Etienne J

    Bonjour,

    Petit signalement de bogue migratoire spip 4 (je fais quelques tests). Lors de l’ouverture des formulaires dans l’espace d’administration sous spip 4, l’erreur en capture d’écran jointe apparait.

    Numéro Message squelette boucle Ligne
    1 Aucun squelette saisies/listes_diffusion n’est disponible... ../plugins/auto/saisies/v4.0.2/saisies/_base.html / 0

    Amicalement.

    • c’est que tu a du mettre une saisie “liste de diffusion” et que entre temps le plugin mailsubscriber qui la fournie a été desactivé.

    Reply to this message

  • 1
    Etienne J

    Autre signalement (je ne sais pas si c’est propre à l’extension Formidable ou plus généralement étendu à spip 4) :
    Les dépendances entre les extensions Formidable et Facteur ne sont pas automatisées, c’est à dire que l’installation de Formidable n’embarque pas celle de Facteur.
    Aussi, Facteur n’est pas référencé dans les extensions compatibles, il faut aller en chercher le lien manuellement.

    • heu... facteur étant marqué comme compatible spip 4, j’aurais tendance à penser que le souci vient plus de svp le gestionnaire de paquet qui n’a pas mis à jour automatiquement facteur.

    Reply to this message

  • 5

    Bonjour ,
    ma question est sur l’utilisation d’un champ conditionnel dont l’affichage dépend de la valeur d’un champ radio ’radio_1’.
    SPIP 3.2.11 [24473] , Formidable 4.15.2 - stable , Saisies pour formulaires 3.54.7 - stable
    j’ai mis dans “Affichage conditionnel” de mon champ conditionné la valeur : @radio_1@==“prix” , et “Uniquement lors du remplissage” est décoché.
    Quand j’affiche le formulaire et je coche “prix” : rien ne se passe .
    Ce qui m’intrigue , c’est dans le code source de la page, il y a :

    <div class="choix choix_prix">
    		<input type="radio" name='x_K1UwTm16RnkwRjVJb1E9PQ' class="radio"    required="required" id="champ_radio_1_3" value="prix" aria-describedby="explication_radio_1" />
    		<label for="champ_radio_1_3">un devis, un prix</label>
    	</div>

    on y retrouve bien “prix” mais “champ_radio_1_3” comme ID

    bien entendu le YAml peut vous être envoyé.
    merci d’avance .

    • C’est parcr que tu as activé l’option encrypt de nospam (via une constante) qui n’est pas compatible avec les afficher_si (ou reciproquement).

    • effectivement, je comprends. Merci bien.

    • je dirais quand même “dommage” car nospam n’est plus une option à présent.

    • bah oui mais l’encryption ci.

      J’ai une piste pour rendre compatible, mais faut des modifs dans nospam, et j’attend un retour de son auteur (pas mal pris ses derniers temps)

    • ah oui l’“Obfusquer les name” , effectivement j’ai du mettre cela car les spammeurs aiment trop mes formulaires visiblement - il y aussi le multilangue dedans mais cela n’a pas d’impact- je pourrais tester en version bêta si vous voulez. - merci d’avance.

    Reply to this message

  • 8

    Bonjour

    J’ai configuré le formulaire pour que le résultat me soit envoyé en y intégrant les fichiers téléversés. Si la taille max est dépassée, un lien est inséré à la place. OK.
    J’ai programmé dans connect.php pour que le lien soit valide 10j.

    J’ai reçu une réponse, il y a 3 jours, Quand je clique, cela ouvre une page de mon site avec le message : formidable_recuperer_fichier_par_email : Accès interdit
    Je suis pourtant bien connecté et webmaster.

    • dans connect.php? normalement c’est mes_options.php

      une possibilité est que le lien soit coupé par le lecteur de mail.

      Il faudrait me transférer le mail en privé pour que je vois ce qu’il en est.
      En tout cas comme cela je n’ai pas d’outil explicatif.

    • Message privé envoyé.

    • Pour mémoire : on suspecte une interaction avec le plugin spip_thelia et son authentification unique.

    • J’ai le même problème.
      Le doc joint est récupérable dans l’admin du site dans la réponse au formulaire mais pas par le lien du mail qui est :

      Formulaire “Fête 2019” posté le 18/06/2019 à 15:45:58.

      Fichier(s) : [Lien expirant dans 15j 0h 0min 0s] received_345391132790639.jpg (JPG - 24 ko) 
      https://www.site.fr/spip.php?action=formidable_recuperer_fichier_par_email&arg=a:4:%7bs:10:%22formulaire%22;s:1:%227%22;s:7:%22reponse%22;s:3:%22792%22;s:7:%22fichier%22;s:28:%22received_345391132790639.jpg%22;s:6:%22saisie%22;s:10:%22fichiers_1%22;%7d&hash=6b836b1cbfd35667a93c01b52bcc3eae924a9291

      message erreur sur le lien : “formidable_recuperer_fichier_par_email : Accès interdit” (je suis webmestre mais pour les autres admins c’est pareil)

      Il n’y a pas de Thélia sur le site

      Merci

    • difficile de dire comme cela. il faudrait voir les logs et autres...

    • Alors dans formidable_post.log j’ai ça qui correspond à la saisie par l’utilisateur :
      2019-06-18 15:45:57 92.167.184.55 (pid 6423) :Pub:!INFO: {"post":{"page":"evenement","id_evenement":2996,"formulaire_action":"formidable","formulaire_action_args":"QWb1uO1UbmAjZ6nluD2Y3fbJM0V2l0mXAs9\/ovHs6WtMAzuQyHyP26v\/mUlPWjTNm+Cg3GRRkwyyAtKrogE36JYK","id_formulaire":7,"formidable_afficher_apres":"rien","_jeton":"0e703f7a51fc46906d31ae7ef302ba068c9e9c07","input_1":"LC ","input_2":"G'h ","email_nobot":"","textarea_1":"56 rue","email_1":"ndy@hotmil.fr","mechantrobot":""},"files":{"fichiers_1":{"name":["received_345391132790639.jpg"],"type":["image\/jpeg"],"tmp_name":["\/home\/site\/www\/tmp\/cvtupload\/formidable_NmIrJ9.jpg"],"error":[0],"size":[24526]}}}

      S’il y a d’autres fichiers log sur le serveur pour l’erreur de lien dans l’email je n’y ai peut-être pas accès.

      Merci

    • Bonjour,

      J’ai actuellement le même soucis sur un formulaire :
      formidable_recuperer_fichier_par_email : Accès interdit

      Le délai est fixé à 15 jours dans le fichier mes_options.php :
      define(’_FORMIDABLE_EXPIRATION_FICHIERS_EMAIL’, 1296000);

      J’utilise actuellement formidable en version 4.7.1

      Avez-vous pu résoudre le problème ?

      Cordialement,

    • Il y a quelques temps j’ai fait une partie des correctifs. Mettez deja à jour. A noter que les liens ne seront valide que pour les nouveaux emails.

      On m’a cependant signalé une piste potentielle d’un autre bug, mais il serait intéressant de tester cela : un delain long + attendre au moins 12 h avant de tester sur ce lien. Pas trop le temps de debuguer cependant en ce moment.

    Reply to this message

  • 1

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

    • Aucune idée, ça sort du cadre de ce plugin en tout cas, mais je n’ai pas vent d’un sous-plugin qui permettrait ça de manière automatique. Dans tous les cas les réponses sont exportables en format standard tableur CSV, donc importables ensuite ailleurs.

    Reply to this message

  • 1

    Est-il possible passer le ou les e-mails des destinataires depuis le frontend (balise spip) plutôt que dans les paramètres du formulaire dans le back office ?

    Merci.

    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

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