SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

288 Plugins, 197 contribs sur SPIP-Zone, 182 visiteurs en ce moment

Accueil > Interactivité, échanges > Formulaires > Formidable > Formidable, le générateur de formulaires

Formidable, le générateur de formulaires

23 janvier 2012 – par RastaPopoulos – 2254 commentaires

171 votes

Un générateur de formulaires facilement configurable pour les non-informaticiens et facilement extensible pour les développeurs.

Introduction

L’objectif était de créer un plugin permettant de générer des formulaires. Historiquement, 2 plugins avaient déjà été développés précédemment pour remplir cette fonction :

  • Forms &Tables, qui n’a pas été complètement porté pour SPIP 2.
  • et spip-formulaire créé par artego mais qui n’est 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éveloppeurs.

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éveloppeurs.
    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.

Installation

Le plugin nécessite les plugins suivants :

Il faut installer le plugin jQuery UI pour pouvoir déplacer les champs à la souris pendant la création d’un formulaire.

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 depuis un squelette

À noter que dans un squelette, 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.

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

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 :

  1. 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.

Voir aussi sur le wiki

-  Complément de doc et exemples sur les boucles et balises de formidable
-  todoFormidable
-  Formidable, présentation aux Grottes (2010)

Voir en ligne : http://plugins.spip.net/formidable

Dernière modification de cette page le 21 octobre 2017

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 20 octobre à 23:52, par DomH En réponse à : Formidable, le générateur de formulaires

    Bonjour,

    J’utilise Formidable version 3.5.3 (la mise à jour vers 3.5.4 ne fonctionne pas, mais ce n’est pas le propos).

    Lorsqu’un formulaire est rempli, la base de donnée est bien peuplée, les mails envoyés contiennent toutes les variables.

    Cependant, si le nombre des réponse est fourni pour chacun des formulaires, lorsque je veux voir les réponse dans l’espace privé, onglet formulaire, il n’y a aucune réponse.

    Je ne sais pas quel est le fichier qui lit la BD et je n’arrive pas à comprendre pourquoi cela coince (tous les champs sont mentionnés « sans réponse »).

    Pour ce site, c’est la version Spip est 3.1.7 [23768] + écran de sécurité 1.3.2 et le squelette sarkaspip version 3.4.7.

    Merci par avance de vos suggestions.

    Bonne journée ou bonne soirée

    Répondre à ce message

  • Le 13 octobre à 11:22, par spipheure En réponse à : Formidable, le générateur de formulaires

    Bonjour

    j’ai installé ce formulaire qui est très pratique sur de nombreux sites internet.
    j’ai malheureusement 3 sites internet qui sont spammés depuis ce formulaire.

    Existe t’il un moyen de mettre un captcha ou autres techniques permettant de faire face à ces spams qui sont très nombreux

    Merci par avance pour votre réponse.

    • Le 13 octobre à 11:25, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Le captcha est une technique que dans globalement la communauté SPIP n’apprécie pas, car elle se fait au détriment des utilisateur·trice·s et de l’accessibilité.

      Cependant le plugin antispam est connecté au plugin formidable et réduit considèrablement les spams, sans recourir au captcha

    • Le 13 octobre à 11:32, par spipheure En réponse à : Formidable, le générateur de formulaires

      Bonjour et merci beaucoup pour votre rapide réponse.

      Je comprends et partage tout à fait votre point de vue, mais là je suis confronté à une situation où nous recevons plus de 100 spams par jour et il faut vraiment une solution.

      Quand vous dites que le plugin antispam est connecté, cela se fait il dès l’installation du plugin formidable ou faut il l’installer par la suite.

      Avez vous une idée de ce que nous pourrions mettre en place pour éviter ces spams

    • Le 13 octobre à 11:38, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      Tout d’abord, est-ce que tu as le plugin Antispam activé bien partout ?

    • Le 13 octobre à 11:46, par spipheure En réponse à : Formidable, le générateur de formulaires

      Merci pour RastaPopoulos pour votre réponse
      non justemment, en réaction à votre réponse je recherche sur cette page https://contrib.spip.net/Protections-antispams quel est le plugin à installer ?

      Merci

    • Le 13 octobre à 11:49, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Aha ! Le plugin s’appelle nospam et pas antispam…
      hehe.

      C’est donc le plugin NoSPAM

    • Le 13 octobre à 11:51, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Pour information : le plugin nospam est un plugin indépendant de formidable qui peut se « brancher » sur plusieurs formulaires (forum, formidable, etc). Il est déjà configuré pour marcher de concert avec formidable-

    • Le 13 octobre à 12:11, par spipheure En réponse à : Formidable, le générateur de formulaires

      Merci beaucoup pour votre aide
      Je vais installer et tester cela et vous tiens au courant

      J’ai une dernière question, comment supprimer définitivement les réponses du formulaire formidable car après avoir demandé à supprimer toutes les réponses, elles basculent effectivement en statut supprimés mais elle reste dans le système.

      Bonne journée

    • Le 13 octobre à 12:22, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Comme pour tous les objets supprimés/à la poubelle dans SPIP, un cron les efface à intervalle régulier (si ce n’est pas le cas, c’est soit qu’il y a un bug sur formidable - mais j’ai vérifié cela il n’y a pas longtemps - soit un bug sur votre site).

      Mais le plugin « corbeille » permet de gérer une vraie corbeille.

    • Le 13 octobre à 14:59, par spipheure En réponse à : Formidable, le générateur de formulaires

      Merci beaucoup pour l’information concernant « no spam » ca fonctionne

      Bravo

    Répondre à ce message

  • Le 7 octobre à 11:07, par Jérôme En réponse à : Formidable, le générateur de formulaires

    Bonjour,

    J’ai un problème avec ce plugin. Je souhaiterais faire apparaître dans un article la liste complète des réponses à un formulaire. J’ai inséré ce code dans mon article :
    <formulaires_reponse|id_formulaire=1>

    La page reste vide. J’ai vérifié en utilisant <formulaire_analyse|id_formulaire=1> et <formulaire_aide_memoire|id_formulaire=1>, et ces codes là fonctionnent. Je ne comprend donc pas d’où vient le problème. Avez vous une piste pour m’aider ?

    Merci.

    • Le 7 octobre à 11:21, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      formulaires_reponse comme son nom l’indique est au singulier, c’est pour UNE réponse, en donnant l’id de la réponse pas du formulaire. Il n’y a actuellement pas de modèles pour afficher une liste complète de réponses (avec des liens ? vers quoi ? ou avec tous les champs de toutes les réponses ?) pour afficher en public.

    • Le 9 octobre à 10:37, par Jérôme En réponse à : Formidable, le générateur de formulaires

      En fait j’ai donné à mes élèves un travail de dépouillement à faire, et chacun d’eux doit compléter une quinzaine de fois le même formulaire. Comme ce travail se fait sur une longue période (un mois), ils ne savent pas toujours où ils en sont lorsqu’ils reprennent le dépouillement.
      L’idéal serait d’afficher dans un article où en est le dépouillement pour l’élève actuellement connecté sur le site. Si c’est trop complexe, je me contenterais d’afficher le résultat total du dépouillement.
      J’ai essayé de bidouiller le fichier formulaire_analyse, mais je ne suis arrivé à rien...

    Répondre à ce message

  • Le 7 octobre à 15:53, par Bruno En réponse à : Formidable, le générateur de formulaires

    Bonjour,
    merci pour ce plugin.
    Je débute et j’ai besoin de renseignements et d’aide.
    1 - Comme pour les courriers de notifications ou l’on peut avoir plusieurs squelettes en fonction de l’identifiant du formulaire, peut-on avoir plusieurs squelette de formulaire de saisie en fonction de l’identifiant

    2- Si on choisit « rediriger vers une nouvelle page » peut-on passer une variable saisie dans le formulaire.
    J’ai un champ masqué id avec une variable pré remplie
    Mon but est de récupèrer cette variable sur une autre page

    Merci d’avance
    Bruno

    • Le 8 octobre à 20:22, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      résumé : non et non :)

      C’est Saisies qui s’occupe de la génération du HTML et il n’y a pour l’instant pas de mécanisme dans l’API pour chercher une variante en priorité et se rabattre sur le truc par défaut ensuite.

      Et pour la redirection, non ya juste un champ avec l’URL tel quel. On pourrait imaginer le faire passer dans le même filtre que d’autres champs en remplaçant les @truc@ par les valeurs du champ, c’est une idée.

    Répondre à ce message

  • Le 23 septembre à 01:47, par DD En réponse à : Formidable, le générateur de formulaires

    Hello,

    Après le mise à jour de ce plugin vers 3.5.3 la page exec=formulaires_reponses&id_formulaire=2
    était blanche (pas de liste des réponses) sur le site en production.

    Sur une version en local c’est bon. (les 2 sur un SPIP 3.1.6)

    La différence, mais je ne sais pas si c’est la cause du problème, c’est le nombre plus important de réponses en production (382)

    J’ai réinstallé la version 3.5.0 et la liste des réponses s’affiche à nouveau.

    Répondre à ce message

  • Le 20 septembre à 09:35, par Emmanuel En réponse à : Formidable, le générateur de formulaires

    Bonjour,
    J’ai un souci avec un formulaire créé par formidable. Il s’agit d’une case à cocher, pour une participation facultative à une partie d’un événement.
    J’ai mis une case à cocher, non-cochée par défaut, à cocher en cas de participation. Elle n’est pas obligatoire. La « valeur oui » est « Présent », la « valeur non » est « Absent ».
    Et pourtant, quel que soit l’état de la case, cochée ou non, la valeur enregistrée dans la base est « Oui ».
    Quelqu’un a une idée de ce qu’il faut paramétrer pour avoir ces « Présent » / « Absent » ou au moins « Non » quand elle n’est pas cochée ?
    Merci d’avance,

    • Le 20 septembre à 10:43, par Maïeul En réponse à : Formidable, le générateur de formulaires

      peux tu faire un export yaml de ton formulaire que je regarde ce qu’il en est ?

    • Le 20 septembre à 10:50, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Export fait… Mais ici, je ne peux joindre que des images. Où puis-je vous l’envoyer ?

    • Le 20 septembre à 10:52, par Maïeul En réponse à : Formidable, le générateur de formulaires

      monprenomsansletrema@monprenomsansletrema.net

    • Le 20 septembre à 11:07, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Envoyé à l’instant, merci !

    • Le 20 septembre à 21:46, par Maïeul En réponse à : Formidable, le générateur de formulaires

      C’est un bug uniquement à l’affichage (donc c’est bien, parce que cela veut dire que les infos sont bien stockées).

      J’ai corrigé en local, mais je ne peux envoyer pour le moment sur la zone car elle est en panne. Mais je retenterai demain.

    • Le 21 septembre à 08:30, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Merci d’avoir regardé.
      Le problème doit aussi être dans l’export CSV, car dans le fichier exporté, je n’ai que des « Oui » dans la colonne…

    • Le 21 septembre à 08:33, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      et dans le courrier électronique automatique envoyé en validant le questionnaire…
      J’imagine que tout est lié, mais on ne sait jamais, je préfère tout signaler ;)

    • Le 21 septembre à 10:11, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Oui, tout est lié, car cela fait in fine appel aux mêmes fichiers du plugin saisies.

      La version 2.18.22 du plugin saisies résoud ce problème.

    • Le 21 septembre à 15:27, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Je viens de faire la mise à jour, effectivement l’export CSV a une bien meilleure tête. Merci beaucoup pour cette solution rapide et efficace !

      Par contre, il reste un truc bizarre : il n’y a qu’une case à cocher, donc j’attends deux réponses possibles : « Présent » (case cochée) ou « Absent » (case non-cochée).
      Pourtant, j’ai (en plus des « Présent ») un mélange de « Absent » et de *Sans réponse*. Il me semblait bien pourtant avoir indiqué que la valeur en cas de case décochée était Absent et que la réponse par défaut était « Non ». Je ne comprends pas bien comment il peut ne pas y avoir de réponse…
      Est-ce que cela veut dire que quelqu’un qui ne clique pas sur la case est sans réponse et quelqu’un qui clique deux fois (coche puis décoche) est compté « Non » ? Si c’est cela, comment éviter ce comportement ? Un réglage m’a échappé ?

    • Le 21 septembre à 15:33, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Avez vous changé les réglages du formulaire après une première soumission ? Cela pourrait expliquer ceci. Il y a un problème conceptuel dans la manière dont est géré les valeurs sur une case à cocher, mais résoudre ce problème risque de casser l’historique et implique donc une discussion collective.

    • Le 21 septembre à 15:56, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Oui, car au début la réponse était obligatoire ce qui revenait à obliger à cocher la case, erreur de ma part détectée tardivement… Mais je ne suis pas certain que cela explique, car ces mélanges n’apparaissent que dans les toutes dernières réponses, après avoir enlevé cette obligation (forcément, avant, tout le monde répondait forcément en cochant pour pouvoir valider…) — sauf la 2e réponse qui a réussi, je ne sais comment à être sans réponse.
      Bon, en l’occurrence, tant que l’on peut dire que toute valeur autre que « Présent » implique une case non-cochée, tout va bien !

      Ce qui a pu jouer aussi peut-être, c’est que j’ai essayé de faire des affichages conditionnels en fonction de la valeur de cette case à cocher, et que j’y ai renoncé n’y arrivant absolument pas (pas compris quelle valeur il fallait mettre dans la comparaison après le @checkbox_1@==), il est possible qu’il en reste des traces qui perturbent aussi ?

    • Le 21 septembre à 16:00, par Maïeul En réponse à : Formidable, le générateur de formulaires

      ouais, c’est encore lié à un problème de conception initial du système. Le problème est qu’en gros le http en envoie « on » si la case est cochée, et rien si elle n’est pas cochée.

      Donc faut tester @checkbox_1@==on
      Ensuite en bdd c’est converti en « si coché » / « si pas coché », alors que cela devrait rester tel quel, et être géré uniquement au niveau de l’affichage (car sinon on a le problème que vous rencontrez en cas de changement)

    • Le 21 septembre à 16:08, par Maïeul En réponse à : Formidable, le générateur de formulaires

      A mon avis il faudrait supprimer cette option, mais le problème est la compatibilité ascendante.

    • Le 21 septembre à 16:59, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Bon, je viens d’essayer le @case_1@==on, ça ne marche pas (puisqu’en fait c’est une case à cocher, et pas une « checkbock ») — ou alors, je ne le mets pas au bon endroit (dans le champ « Affichage conditionnel lors du remplissage » de l’objet du formulaire qui ne doit apparaître que si la case est cochée…). Pas encore clair pour moi tout cela, désolé...

    • Le 21 septembre à 17:05, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Voir le fil du dessus (je me suis embrouillé dans les fil).

      A mon avis il faut tester @case_1@=='Présent', mais je continue à penser qu’il y a un problème dans cette fonctionnalité, puisque tu a compris que valeur_oui et valeur_non était pour l’affichage final, ce qui n’est pas le cas, si on en croit Rastapopoulos.

    • Le 21 septembre à 17:18, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      Ouais, bon il n’empêche que de facto cela embrouille les utilisateur·trice·s, et que c’est confusionnant. Donc il y a un problème. Si une fonctionnalité n’est pas clair dans sa destitnation, c’est qu’elle est problématique. Cela peut se résoudre en changeant les chaines de langue, peut être, mais il faudra aussi remodifier la vue pour afficher oui/non en fonction de la valeur stockée.

      Ça n’a jamais été prévu pour être mis dans le YAML et donc dans le constructeur au départ. Mais cela dit, comme expliqué précédemment ça peut AUSSI servir pour formidable (pour les exports et stats et pour formiTable et autres traitements persos).

      Depuis le début de Saisies tout ce qui s’appelle « valeur… » concerne… les valeurs, et ce qui s’appelle « label… » concerne… l’affichage humain. C’est comme ça partout depuis le tout début.

      Là les champs de config « valeur_oui » et « valeur_non » sont deux configs à la fois techniques et rares. Ça devrait même pas être dans l’onglet général principal de la config (et pas dans « affichage » non plus évidemment) et après faut changer le label des configs et surtout ajouter une explication pour chaque indiquant que c’est pour mettre à la place de la valeur par défaut qui est « on » (ou vide pour l’autre), etc.

    • Le 21 septembre à 17:18, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Ça fonctionne ! Merci !
      Je me demande si cela ne fonctionnait pas avant pour la même raison que les problèmes d’affichage précédents… Mais c’est lointain, peut-être me manquait-il une subtilité comme les apostrophes.
      J’ai du mal à juger s’il y a un problème ou pas, mais en tout cas un peu de documentation ou des exemples seraient utiles ;)

      Tant que j’y suis : est-ce que l’on peut utiliser des opérateurs logiques, par exemple un truc du style « @case_1@==’Présent’ & @radio_1@==[le choix n° 2 parmi 2] » ? [ici, ne pouvoir indiquer ses préférences alimentaires que si l’on vient au dîner et avoir indiqué que l’on en a]

    • Le 21 septembre à 17:28, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Je sais pas/plus pour les opérateurs logiques.

      De toute facon, si tu suis le fil du dessus, tu verra que en fait ce n’est pas prévu pour la gestion de l’affichage, mais pour des opérations techniques internes. Cela veut dire qu’on va surement casser prochainement ma correction d’hier pour avoir quelque chose de normalisé.

    • Le 21 septembre à 17:31, par Maïeul En réponse à : Formidable, le générateur de formulaires

      @Rastapopoulos : ton explication me convient, et ta proposition de modification aussi.
      Mais clairement, vu le besoin d’Emmanuel au départ de ce fil, faudra aussi ajouter des champs pour l’affichage (il n’y aucune raison que seules les technicien·ne·s aient droit à des valeurs perso, et pas les utilisateur·trice·s)

    • Le 21 septembre à 17:37, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      On verra à la prochaine version... Pour l’instant ça marche, c’est l’essentiel ;) Avec un truc pas clair qui reste ce mélange de « Sans réponse » et de « Valeur_non » dans la base, pour une case à cocher qui semble ne pouvoir renvoyer que on ou rien. J’ai changé des réglages, mais jamais le type de champ !

      Ceci dit, pour une case à cocher de ce type, j’ai un peu de mal à faire la distinction entre valeur technique et valeur d’affichage. Après tout, de toute façon, même si on code le statut de la case en (0, 1), il faudra bien avoir quelque part les valeurs utiles correspondantes, alors pourquoi ne pas les avoir directement dans la base ? Mais pour traiter les résultats, la valeur d’affichage est quand même nettement plus pratique que du (0,1), surtout si la personne qui doit traiter n’est pas celle qui a créé le formulaire !

    • Le 21 septembre à 17:42, par Maïeul En réponse à : Formidable, le générateur de formulaires

      non, la case à cocher envoie :
      -  valeur_oui si coché. Valeur oui par défaut = on
      -  valeur_non si non coché. Par défaut, valeur_non=’rien’

      Si je résume, au départ tu voulais avoir valeur_oui/valeur_non à l’affichage. Mais en fait c’était prévue pour la base. J’ai modifié pour que cela soit affiché, mais en fait non c’est pas bien, il faudra que je revienne en arrière (demain ?).

      Ensuite ajouter une option pour qu’à l’affichage on puisse avoir autre chose.

      Personnellement je pense qu’en base on ne devrait stocker que 1/0 (ou on, null), car sinon on se retrouve avec des problèmes si on change les réglages. Et c’est uniquement au cas du traitement de vue qu’on devrait avoir une valeur « humaine ». Mais Rastapopoulos ne partage pas mon opinion.

    • Le 21 septembre à 17:55, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Je n’ai rien contre le 0/1 dans la base… mais avec une option alors pour l’export CSV aussi pour choisir un export brut ou un export pré-traité en remplaçant les codes par leurs signification.
      En revanche, je suis entièrement d’accord avec le fait que vide pour une case non-cochée est trompeur par confusion avec une valeur manquante, ce qui va gêner les reprises du CSV dans R ou tout autre logiciel de stats après.

      Bref, de loin, il me semble qu’il y a deux solutions simples possibles :
      — soit les valeurs dans la base sont imposées à 0 (case non-cochée) et 1 (case cochée) [ou toute autre convention clairement définie] + il y a un filtre, optionnel, qui les convertit en valeurs définies appropriées lorsque l’on extrait de la base. Dans ce cas, valeur_oui et valeur_non ne devraient pas exister et label_oui et label_non doivent pouvoir être facilement modifiés (si je comprends bien la nomenclature de Rastapopoulos) ;

      — soit on a la main-mise sur les deux valeurs stockées dans la base, et dans ce cas je ne voie pas l’intérêt d’une distinction entre valeurs techniques et valeurs d’affichage… Pour ce cas particulier d’une case à cocher, en tout cas.

      J’aurais tendance à préférer la 2e solution, mais ce n’est qu’un avis très personnel. D’autant plus que je n’ai aucune vision de ce que cela implique vis-à-vis des diverses strates de plug-ins impliquées...

    • Le 21 septembre à 17:59, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Une raison pour laquelle on pourrait distinguer valeur technique/d’affichage est par exemple dans le cas d’un formulaire qu’on souhaite afficher en plusieurs langues.

    • Le 21 septembre à 18:03, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Pour répondre plus spécifiquement : quand j’ai conçu le questionnaire, je ne me suis pas posé la question d’une différence entre valeur dans la base et valeur à l’affichage. Je ne sais pas si je suis représentatif des utilisateurs ou pas, mais je n’avais simplement même pas imaginé qu’il y avait une différence entre les deux.
      Je voulais juste que ces textes apparaissent dans le fichier CSV que je génèrerai à la fin de la collecte des réponses (ou sur une vue des réponses au questionnaire sur le site, mais comme je n’ai pas encore réussi à la faire pour l’instant, c’est un autre problème)... J’ai juste vu ces champs en espérant que cela fasse ce que je voulais, ne voyant rien d’autre qui aurait pu jouer ce rôle. Sans trop me préoccuper de savoir comment techniquement cela se ferait ;)

    • Le 21 septembre à 18:06, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      OK pour la traduction, je n’avais pas pensé à ce cas. C’est un problème absent dans les bases que je gère habituellement, ça a biaisé mon appréciation.
      Au temps pour moi…

    • Le 21 septembre à 18:15, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      Pas juste, comme donné précédemment, ce n’est pas du tout juste pour Formidable, et même pour Formidable il n’y a pas que le traitement d’enregistrement par défaut, il y a FormiTable ou d’autres gens qui codent des traitements persos. Et pour des trucs avec plusieurs choix comme ça, on veut souvent que le formulaire poste des valeurs *précises*. D’ailleurs en fait je suis bête, le plus évident c’est même Champs Extras. Le constructeur ne sert pas qu’à Formidable, c’est exactement le même pour Champs Extras. Et quand les gens cochent tel ou tel truc, on veut que Champs Extras enregistre dans la base la valeur « truc » très précisément. Après c’est utilisé dans les squelettes, les boucles, les critères, n’importe quoi d’autre ! Et dans l’interface d’admin, sur la page de l’objet, bah ça sera affiché un truc humain, pas l’identifiant technique.

    • Le 21 septembre à 18:19, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Qu’est ce qui n’est pas juste ?

      Et dans l’interface d’admin, sur la page de l’objet, bah ça sera affiché un truc humain, pas l’identifiant technique.

      cela devrait (mais actuellement ce n’est pas le cas : avant mon commit d’hier cela affichait oui, après mon commit cela affiche l’identificant technique)

    • Le 21 septembre à 18:47, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      C’est une coquille, ya un doublon, je disais ce n’est pas juste pour Formidable.

      L’affichage humain il se faisait déjà lisiblement et sans « faute » sémantique en utilisant le « label_case » et en disant si oui ou non cette case était cochée.

      Je voulais surtout signaler que c’est bien une différence majeure entre la valeur en base et l’affichage humain, car pas forcément dans un export de Formidable, mais dans une table quelconque avec Champs Extras, et l’affichage du champ de manière humaine sur la page d’admin de l’objet où on a mis ce champ.

    • Le 21 septembre à 18:49, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Bon, admettons que la correction qui résolvait mon problème soit annulée, pour les raisons évoquées.
      Cela ne me dérange pas plus que cela d’avoir oui/non à la place de présent/absent dans le fichier CSV, mais il doit/devait y avoir une erreur ailleurs quand même si le remplacement de la valeur technique par la valeur humaine donnait tout le temps « Oui », quelle que soit la vraie valeur technique, non ?

    • Le 21 septembre à 18:53, par Maïeul En réponse à : Formidable, le générateur de formulaires

      @Emmanuel : oui, effectivement il y avait un bug.
      @Rastapopoulos : encore une fois, je ne vois pas pourquoi techniquement on aurait droit à une valeur autre que on/vide, mais que au niveau de l’affichage on aurait droit qu’à oui/non.

    • Le 22 septembre à 16:24, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Bonjour,
      J’ai médité un peu depuis hier… histoire d’être sûr de bien comprendre. L’idée est donc, si j’ai tout bien suivi, pour une case à cocher (et par extension pour des champs radio, j’imagine), de distinguer entre une valeur unique pour chaque réponse qui est dans la base et qui est intangible et une valeur « souple » qui est interprétable pour l’utilisateur.
      J’imagine que cela implique, techniquement, une table qui fait la correspondance entre les deux, avec — pour le cas de la traduction — un champ langue en plus pour choisir la bonne correspondance.
      J’avoue que, à partir du moment où cette table de correspondance existe, j’ai un peu de mal à concevoir ce que cela change d’imposer les valeurs techniques dans la base à 0 ou 1 ou à un couple de valeur définissable par l’utilisateur. En revanche, il me semble essentiel de pouvoir accéder à la correspondance côté utilisateur entre la valeur technique, quelle qu’elle soit, et la valeur que veut l’utilisateur.
      Il me semble donc que pour satisfaire aux désirs de tout le monde, il faudrait avoir
      — deux valeurs techniques (valeur_Oui et valeur_Non actuellement, si j’ai bien compris) avec des valeurs par défaut (1 et 0 serait j’imagine la convention la plus largement répandue) ;
      — cette table de correspondance éditable valeur_Oui/fr = label_Oui et valeur_Non/fr=label_Non avec par défaut une correspondance label_Oui = Oui et label_Non = Non (par exemple) ou label_Oui = valeur_Oui et label_Non = valeur_Non ;
      — la possibilité de modifier les deux, avec la contrainte que si l’on modifie les valeurs techniques, il faut penser à adapter la table de correspondance en conséquence, la réciproque étant fausse.
      Est-ce que c’est faisable en l’état actuel ?

      Je n’ai pas compris la réponse de Rastapopoulos qui explique pourquoi on aurait envie de modifier les valeurs techniques si la table de correspondance existe, mais je ne voie pas non plus de raison de l’interdire, du moment que la table de correspondance suit…

      En revanche, en tant qu’utilisateur, je veux pouvoir changer mes affichages et je me fiche complètement de la valeur technique (je pense que comme moi, beaucoup d’utilisateurs n’imaginent même pas qu’il y a une distinction entre les deux et s’en fichent même un peu du moment que le formulaire fonctionne et _affiche_ ce qu’ils veulent), donc pouvoir changer la valeur technique sans changer l’affichage me paraît incompréhensible !

    • Le 22 septembre à 16:40, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Techniquement pour les boutons radios, l’utilisateur·trice doit déjà définir une valeur technique et une valeur d’affichage

      cle|affichage
      cle2|affichage2

      Pour des raisons historiques, les valeurs technique par défaut seront on et rien (comme de toute facon tu le signale, un case à cocher ne peut déjà pas faire la différence entre pas de réponse et réponse négative)

      Il n’y a pas besoin de table de correspondance, puisqu’est dans du binaire. On aura juste du label oui et du label non, et après c’est la tambouille interne de saisie de savoir que valeur_oui s’affiche en label_oui et valeur_non en label_non

    • Le 22 septembre à 16:53, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      OK, c’est plus clair. Merci !

    • Le 30 septembre à 19:21, par Maïeul En réponse à : Formidable, le générateur de formulaires

      La version 2.19.0 de saisies enterine les résultats de la discussion.
      -  Prise en compte de valeur oui/non pour l’affichage des résultats
      -  Déplacement de la config + explication plus détaillés
      -  Nouvelle config pour l’affichage utilisateur.

      A voir avec ton historique du coup. Je pense qu’il faudra sans doute que tu modifie les valeurs stockées en bases pour avoir de la cohérence.

    • Le 2 octobre à 09:36, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      OK ; comme l’événement a lieu dans trois jours, j’avoue que je préfère attendre avec la base dans l’état actuel, figée (les inscriptions sont closes), avant de faire des essais, mais je regarde ensuite.
      Merci en tout cas pour le suivi de tout cela et l’aide apportée !

    • Le 2 octobre à 10:28, par Maïeul En réponse à : Formidable, le générateur de formulaires

      C’est parfaitement compréhensible.

    Répondre à ce message

  • Le 25 septembre à 15:22, par Julich En réponse à : Formidable, le générateur de formulaires

    Bonjour,

    Afin d’améliorer l’accessibilité de mon site, je souhaiterais mettre en place le fonctionnement suivant :
    Lorsque le formulaire est envoyé, en complément des messages (message_ok ou message_erreur) qui apparaissent dans la page, j’aurais voulu donner directement l’information de succès ou échec directement dans le titre de ma page.
    Ex :
    <title>Confirmation d'envoie - Nous contacter </title>
    ou
    <title>Erreur de saisie - Nous contacter </title>

    Malheureusement quand je suis dans mon squelette, les valeurs des variables #ENV*message_ok et #ENV*message_erreur (utilisées dans le formulaire) semblent inconnues. Comment dois-je donc procéder ?

    Merci par avance pour vos retours.

    Julie

    Répondre à ce message

  • Le 5 septembre à 02:35, par julien schwartz En réponse à : Formidable, le générateur de formulaires

    Bonjour à tous,

    Il m’arrive un truc bizarre sur un site (ffjs.org), lorsque sur la même page (page d’accueil par exemple) j’ai à la fois le formulaire de recherche de Spip (appelé par une loupe dans le header) et un formulaire Formidable (inscription à la newsletter en base de page), les deux semblent entrer en interférence et Formidable se comporte bizarrement.
    Si on appuie sur la touche ’entrer’ pour valider l’inscription à la newsletter tout se passe bien, mais si on utilise le bouton ’submit’ pour valider le formulaire, on arrive sur la page de résultat du moteur de recherche ! (d’ailleurs en regardant la source HTML c’est bien ce que prévoit l’attribut action du formulaire.)
    Je précise que cela ne se produit pas sur une page où il n’y a pas le formulaire de recherche.

    J’avoue ne rien y comprendre, si quelqu’un a une idée, je suis preneur !
    Merci

    • Le 21 septembre à 16:17, par Maïeul En réponse à : Formidable, le générateur de formulaires

      J’ai parlé trop vite. C’est bien Présent/absent qui est envoyé. Mais cela reste à mon avis une mauvaise conception de départ. On devrait envoyer une information binaire qui est ensuite traduite à l’affichage, sinon on a ces problèmes de ruptures en cas de changement de réglage.

    • Le 21 septembre à 16:22, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      Mais non ça ne doit pas être à l’affichage, et justement l’affichage ne doit PAS être ce qu’on met dans « valeur_oui » et « valeur_non », ça c’est justement des configs pour dire quelle est la valeur TECHNIQUE enregistrée dans la base, pas du tout le label humain. C’est exactement comme pour les boutons radios, pour chaque choix, la valeur technique enregistrée pour le champ. Dans une case à cocher, le label bah c’est le label_case du champ, et c’est ça qu’on affiche, pas du tout « valeur_oui » et « valeur_non » qui sont des choses cachées dans la base.

    • Le 21 septembre à 16:37, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Levons un malentendu, je parle ici de l’affichage des résultats, pas de l’affichage de la saisie, qui lui utilise effectivement label_case.

      Par contre je pense qu’en base (ou tout autre système de stockage des résultats) on doit avoir un valeur technique boolen (du type « on » ou « rien » comme c’était le cas avant) qui ensuite est converti en valeur_oui, valeur_non.

      Typiquement dans le cas à l’origine de ce file, la configuration de la saisie était la suivante :
      -  label_case « Je serait présent »
      -  valeur_oui « Présent »
      -  valeur_non « Absent »

      Or ici, contrairement à une liste de choix type bouton radio, on a que deux possibilités. Et comme par ailleurs on n’est jamais à l’abris d’une personne qui change valeur_oui / valeur_non en cours de route, il faut juste avoir « case cochée/pas cochée » dans la base, et au moment de l’affichage du résultat « présent » ou « absent ». Comme cela si jamais la personne change par exemple valeur_oui en « Présent·e », et bien on a pas un affichage faussée.

    • Le 21 septembre à 16:48, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      Mais je réitère, à aucun moment valeur_oui et valeur_non ne servent et de doivent servir à l’affichage humain. Ça a toujours été les VALEURS (le nom est explicite hein, c’est pas « label ») techniques qu’on veut enregistrer en base quand on veut surcharger celles par défaut (qui sont « on » et vide), justement pour pouvoir les utiliser dans des scripts, des statistiques après export tableur, etc. Donc c’est NORMAL que ça soit affiché « Oui » et « Non » (traduit) dans l’affichage des réponses : ça sert juste à dire « Oui la case est cochée » et « Non la case est pas cochée » du label_case humain (« Je serai présent » => « Oui » / « Non »).

      S’il doit y avoir en plus un truc d’affichage ça ne soit évidemment pas être en utilisant « valeur_XXX » (valeur…) mais à ce moment il faudrait rajouter « label_oui » et « label_non »… Bref, encore une config en plus, relou, et rajout de complexité au form de config de la saisie. Ça me parait lourd pour pas grand chose mais c’est possible…

      À part ça, un autre problème c’est que l’export en tableur export en utilisant la vue humaine. Il faudrait absolument ajouter une option pour pouvoir exporter avec les valeurs brutes (souvent un identifiant unique) pour pouvoir vraiment traiter les donner ensuite (et là dans son tableur il y aurait « present » et « absent », plutôt sans accent rien, juste valeurs brutes pour traitement).

    • Le 21 septembre à 16:53, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Admettons que cela soit le cas que c’était prévu pour cela, à savoir uniquement la gestion technique. Il n’empêche que ce n’est pas intuitif, puisque de facto Julien (et moi même en regardant le formulaire de configuration) me dit que c’est pour des valeurs humaines.

      A mon sens, c’est du reste plus logique de pouvoir avoir des réglages pour les humains que des réglages techniques : un·e technicien·ne sera parfaitement capable de convertir à la volée un « on » en « présent » ou autre pour son script, alors qu’un·e humain·e aura sans doute envie (comme Julien) de voir « présent » et pas « oui ».

    • Le 21 septembre à 16:59, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      Bah non, puisque justement le premier cas était pour résoudre « valeur_non » afin de pouvoir renvoyer autre chose qu’une saletée de valeur vide, qui est la norme partout dans les saisies par défaut depuis le début. Comme toujours, ça n’a pas forcément de rapport avec Formidable et là ça n’en avait pas. Il fallait que la saisie de ce type puisse avoir autre chose que VIDE dans l’attribut « value ».

      Le « valeur_oui » a été rajoutée ensuite par symétrie, tant qu’à faire, si on peut personnaliser pour l’un, logique de pouvoir personnaliser pour l’autre. Donc non, la valeur vide pose problème dans plusieurs cas utiles, et il fallait pouvoir la changer.

      Ensuite quelqu’un (pas moi) a ajouté cette option dans le YAML donc l’a rendu configurable pour Formidable, ce qui a moins de sens, même si ça peut en avoir : pour avoir des valeurs choisies à traiter ensuite, et aussi pour d’autres traitements que l’enregistrement par défaut de Formidable, par exemple quand on enregistre des réponses dans d’autres tables (FormiTable ou autre traitements persos métiers).

    • Le 21 septembre à 17:02, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Ouais, bon il n’empêche que de facto cela embrouille les utilisateur·trice·s, et que c’est confusionnant. Donc il y a un problème. Si une fonctionnalité n’est pas clair dans sa destitnation, c’est qu’elle est problématique. Cela peut se résoudre en changeant les chaines de langue, peut être, mais il faudra aussi remodifier la vue pour afficher oui/non en fonction de la valeur stockée.

    • Le 21 septembre à 17:31, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Avec ma casquette de statisticien, je dirais que fondamentalement, c’est la case à cocher elle-même qui a un problème, car on ne peut pas savoir si elle n’a pas été cochée volontairement (donc il faut « valeur_non ») ou si elle n’a pas été cochée car on ne veut pas répondre/n’a pas lu la question… (et là, il faut une valeur vide ou NA).
      Et que donc, il n’y a pas de solution satisfaisante possible... et qu’elle ne devrait servir que pour des cas où on veut forcer la coche, tout le reste devrait être en deux boutons oui/non dont aucun n’est choisi initialement.
      Mais bon, en tant qu’utilisateur du questionnaire, c’est lourd, une case à cocher est plus simple, et souvent pas de réponse ou pas coché, c’est pareil.
      Et puis, je n’ai pas trouvé comment faire un champ qui ressemble à « je serai O présent O absent au dîner », ma connaissance du CSS et des formulaires n’est pas assez poussée...

    • Le 21 septembre à 17:35, par Maïeul En réponse à : Formidable, le générateur de formulaires

      @Emmanuel : je suis d’accord avec toi, mais on a eu il y a un certain temps une discussion sur les boutons radios sans valeur de départ, et beaucoup trouvaient cela totalement contre ergonomique.

      Personnellement j’utilise cette technique sur un site où je dois demandais aux gens s’ils acceptent qu’on les prennent en photo durant une rencontre.

      Il suffit juste de prendre les entrées « radios » (et pas oui/non), et de créer ses propres label de radio.

    • Le 21 septembre à 17:39, par julien schwartz En réponse à : Formidable, le générateur de formulaires

      Salut à tous,
      Je me permets de faire un petit up de ma question initiale vu que les réponses ont servi à résoudre un autre problème (extrêmement important par ailleurs).
      Je vous en remercie par avance !
      Julien

    • Le 21 septembre à 17:44, par Maïeul En réponse à : Formidable, le générateur de formulaires

      @Julien : désolé, aucune idée. J’imagine que cela doit être un conflit au niveau des noms des inputs, mais en l’absence d’exmple concret/visuel dur à dire.

    Répondre à ce message

  • Le 2 février à 11:49, par karine En réponse à : Formidable, le générateur de formulaires

    bonjour,

    de nouveau je reviens vers vous car j’ai un petit soucis.. J’ai pourtant bien lu vos posts mais je ne sais pas. Je vous explique

    J’ai un formulaire que j’ai intégré à un article qui fonctionne parfaitement puisque les infos saisies sont bien sauvegardées dans ma base de données.

    maintenant, je dois pouvoir afficher tous les résultats sous forme de tableau dans un autre article, comment procéder ? Je suis un peu perdue, cela fait 2 jours que je cherche.

    Merci à vous :)

    • Le 2 février à 11:57, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Un tableau c’est long, c’est compliqué, cela dépend de ce qu’on veut mettre ou pas, du type de saisies etc.

      Donc avant de donner une réponse, j’aimerai savoir

      1. Comment serait orienté le tableau.
      2. Si toutes les saisies seront mises, et quels sont le type de saisie
      3. Si vous connaissez ou pas le HTML et le fonctionnement des boucle SPIP.

    • Le 3 février à 08:24, par Karine En réponse à : Formidable, le générateur de formulaires

      c’est un tableau horizontal avec :

      (Nom | Prenom | Profession | Missions | Date entrée | Date sortie | Date diplome | Tel | Mail | Témoignage)

      Après je peux indiquer que le nom et prénom avec possibilité en cliquant dessus d’afficher sa fiche !!

      Je ne sais pas quelle solution serait la meilleure.

      Oui le connais le html, SPIP bcp moins. En fait je veux faire un annuaire d’ancien élèves.

    • Le 3 février à 09:46, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Bon, c’est déjà plus simple qu’un tableau dans l’autre sens.

      Je suis en ce moment littéralement débordé de travail. Mais normalement le week-end en huit, je peux m’occuper de créer un modèle générique de tableau. J’en ai du reste besoin pour mes propres activités.

    • Le 3 février à 11:13, par karine En réponse à : Formidable, le générateur de formulaires

      ce serait super !!
      merci d’avance

      je vais continuer à regarder si je trouve et vous tiendrais au courant !!

    • Le 3 juillet à 22:24, par Emmanuel En réponse à : Formidable, le générateur de formulaires

      Bonjour,
      J’aurais le même genre de choses à réaliser... Est-ce que vous avez pu aboutir à une trame pour faire cela ?
      Merci par avance,

    • Le 3 juillet à 22:27, par Maïeul En réponse à : Formidable, le générateur de formulaires

      Franchement non, je n’ai finalement pas eu le tps. J’ai pas mal de boulot à faire en ce moment.

    • Le 3 juillet à 22:35, par RastaPopoulos En réponse à : Formidable, le générateur de formulaires

      Juste pour garder en tête : dans l’admin Cédric avait rajouté un truc pour permettre de choisir quelles colonnes on voulait dans les résultats d’un formulaire précis, dans sa config, en listant les @input_1@ etc séparés par des virgules ou pipes je ne sais plus.

      Du coup ça pourrait être un modèle

      <formulaire1234|reponses_tableau|champs=input_1, select_1, input_2, textarea_1>

      (et plus tard on pourra imaginer une aide à l’insertion avec Insérer Modèles)

    Répondre à ce message

  • Le 26 juin à 17:29, par DD En réponse à : Formidable, le générateur de formulaires

    Une disparition pas inquiétante mais bizarre :
    Dans un formulaire j’ai deux champs date (avec horaires) obligatoires et sur la page : ?exec=formulaires_reponse&id_formulaires_reponse=xx

    Ces 2 champs n’apparaissent plus (depuis au moins le 15 mai dernier)

    Plugin à jour et SPIP 3.0.25

    Répondre à ce message

Répondre à cet article

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 Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • ScolaSPIP 4

    19 janvier 2016 – 257 commentaires

    ScolaSPIP est plugin-squelette responsive personnalisable pour sites Web d’établissements scolaires basé sur SPIPr Présentation de ScolaSPIP Ce plugin pour SPIP 3 est développé par la Dane de l’académie de Versailles pour les webmestres de cette (...)

  • Import ICS 2 et supérieur (agenda distant)

    2 août 2016 – 56 commentaires

    La version 2 du plugin « import ICS » en reprend la principale fonctionnalité, à savoir l’ajout automatique d’évènements distants dans la liste des évènements d’un site. À la différence de la première version, elle ne dépend pas du plugin « Séminaire » et est (...)

  • Utilisez le framework Foundation dans vos squelettes !

    13 août 2013 – 95 commentaires

    Foundation est un framework CSS et Javascript très complet pour réaliser des sites sur une grille propre et homogène. Mais surtout, il permet de rendre un site responsive très facilement ! Ce plugin ajoute le framework Foundation sur l’espace (...)

  • Champs Extras 3

    16 janvier 2012 – 602 commentaires

    Ce plugin permet de créer et/ou de gérer des champs supplémentaires dans les objets éditoriaux de SPIP. Il permet donc de prendre en compte et d’afficher de nouveaux éléments dans n’importe quel objet éditorial de SPIP. Screencast Vous n’aimez pas (...)

  • Optimiser les URLS pour google actus

    19 juin 2012 – 28 commentaires

    Les sites publiant de l’information de type « nouvelles » peuvent prétendre à être indexés par le site google actualités. Pour cela il faut qu’ils répondent à quelques caractéristiques précises qui sont énoncées ici par google. L’une de ces caractéristiques (...)