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

  • 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

  • 3

    Bonjour,
    J’utilise Formidable 4.9.0.
    Dans les traitements, j’ai un souci sur l’exclusion de certains champs dans les notifications.
    Si j’indique dans le champs “Champs à exclure du contenu du message” quelque chose comme ceci:

    radio_1,radio_2,explication_1,explication_2,fieldset_1,input_1

    ou encore

    radio_1

    le message de notification au/à la destinataire ne contient plus aucun champ, et seulement les parties communes à tous les courriels de notification aux destinataires.

    Lorsque j’indique ceci:

    input_1

    le champ qui correspond à “input_1” n’est plus interprété dans le courriel destinataire (je l’ai mis dans ’objet du courriel) ni dans le courriel expéditeur·ice, par contre, il est bien présent dans le corps du courriel destinataire de façon automatique.

    Qu’est-ce que je fais qui ne va pas pour avoir ces comportements là?

    Reply to this message

  • 2

    Bonjour,
    Lorsque l’on exporte les réponses d’un formulaire la colonne “adresse IP” est vide, par contre il y a bien l’entête de la colonne (donc les valeurs des colonnes suivantes sont décalées),
    ceci même si la case “Enregistrer les IPs (masquées après un délai de garde)” est cochée.
    Pour la page “Tableau des réponses” la colonne “adresse IP” n’apparaît pas du tout (c’est peut-être voulu).

    C’est un vil détail mais je ne comprenais pas les réponses avant de trouver le hic.

    • Hum, il y a plusieurs choses

      1. Tu dois avoir un souci au niveau de ton tableur, car normalement un champ vide en csv va bien produire une cellule vide, et tu ne devrais pas voir le décalage
      2. Par ailleurs, l’export des adresses IP n’est pas activée par défaut, pour des questions de confidentialités. C’est une option de config de formidable.

      Pour autant il y a quelques améliorations que je viens d’apporter:
      -  sur la branche master de formidable : si jamais on n’exporte pas les IP, ne pas afficher l’info “IP” dans l’entête
      -  sur la branche master de formidable_tablesorter : afficher les IP si jamais on a coché l’option formidable pour l’export des IP

      Je ne release pas maintenant car on me reproche de le faire trop souvent. Peut être le week-end prochain si rien ne tombe entre temps.

      Tu peux recuperer les zip des branches sur git.spip.net pour faire ta propre install (ou bien utiliser git

    • Merci cela fonctionne maintenant.

    Reply to this message

  • 7

    Bonjour,

    Je souhaiterai avoir un formulaire avec plein de champs qui s’affichent de façon conditionnelles. Il s’agirait d’une sorte de FAQ dont l’aboutissement pourrait être une réponse toute faite, ou bien la rédaction d’un courriel et envoi avec le bouton de validation du formulaire.

    Sauf que pour la réponse toute faite, l’idéal serait de ne pas faire apparaître le bouton de validation bien sûre.

    Y’a t-il également moyen avec formidable ou autre chose, de faire apparaître ce bouton de validation de façon conditionnelle?

    • 1. Il est possible de configurer les champs pour que leur affichage dépendent d’autres champs (onglet “affichage”)
      2. Une version de dev que tu peux télécharger ici permet également de conditionner le bouton globale https://git.spip.net/spip-contrib-extensions/formidable/archive/afficher_si_button.zip
      Il faut se rendre dans la configuration des options globales des saisies (tout en haut de l’interface d’édition des saisies).

    • C’est une bonne nouvelle tout ça. Je teste ça tout bientot. Un besoin de retours sur cette fonctionnalité?

    • Eventuellement. Mais ca devrait rouler relativement bien (enfin bon courage pour tous vos tests conditionnels !).

      La seule vrai question que je me pose c’est si je ne devrais pas en plus ajouter une option pour mettre un message si jamais le bouton est masqué, car un formulaire sans bouton c’est chelou.

    • Salut, des petits retours sur cette fonctionnalité ?

    • Salut!
      J’ai pas explorer à fond la possibilité qu’il y ait des effets indésirables. Mais en attendant, ça fait bien ce que ça doit faire.
      Grand merci à toi.

      — 
      Ludo

    • oki ! super !

      bon j’attend avis formelle des copains/copines sur la PR, et on valide.

    • C’est intégré dans la version 4.9.0 de formidable. Attention, j’ai un peu changer la manière de procéder, et il faudra aussi mettre à jour saisies.

    Reply to this message

  • 10
    essaillon

    Bsr,

    Comment mettre en forme les réponses d’un formulaire dans le mail transmis au contact ?
    Pour l’instant je reçois en colonne

    * Label 1
    * réponse 1
    * Label 2
    * réponse 2
    * Label 3
    * réponse 3

    au lieu de

    * Label 1 : réponse 1
    * Label 2 : réponse 2
    * Label 3 : réponse 3

    Merci

    • Si c’est juste pour cela, tu peux mettre dans mes_options.php

      define('_SAISIES_AFFICHAGE_COMPACT', true);

      pour d’autres mises en forme, il faut surcharger le gabarit d’email.

    • essaillon

      Merci pour la réponse rapide mais aucun changement, hélas.

    • Je viens de tester, et je confirme que cela marche cehz moi,

      Pouvez vous me partager votre mes_options.php ?

    • essaillon

      Voilà

      <?php
      define
      ('_SAISIES_AFFICHAGE_COMPACT'true);
      ?>

    • oui, docn c’est correcte. Quelle version du plugin saisies?

    • essaillon

      Saisies pour formulaires 3.46.1

    • essaillon

      J’ai peut-être oublié d’indiquer que je sous sur une mutualisation.
      https://agha.fr

    • hum, je ne sais pas niveau mutualisation comment ca se passe pour le mes_options.php...

    • essaillon

      Bjr,

      Je reviens sur le sujet.

      En fait,
      <?php
      define
      ('_SAISIES_AFFICHAGE_COMPACT'true);
      ?>

      a bien amélioré la présentation dans l’email, merci.

      Mais je reçois, dans le même email la présentation ancienne avec les mêmes données brutes en colonne. :(

    • heu...
      il faudrait vérifier votre install, Peut être un plugin ou squelette qui surcharge ?

      Ou bien peut être votre lecteur de mail vous fait voir la version html et la versio0n simple texte ?

    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