le $where ne sert que dans la requete juste dessous, on l'y intègre pour faciliter la relecture des requetes SQL

Dans r80736 l'erreur c'était moi puisque je n'avais pas vu que traiter() serializait les valeurs multiples en une seule pour le stockage.
On retablit donc l'unicité de (id_formulaires_reponse,nom) en unifiant prealablement les éventuelles valeurs multiples importées de f&t, et en conservant la clé primaire qui n'est par contre pas inutile.

on incrémente juste pour noter que la migration et l'installation sont validées sous SQLite également

Corriger une erreur de structure SQL : la clé primaire sur id_formulaires_reponse,nom de la table spip_formulaires_reponses_champs empechait l'enregistrement de plusieurs réponses pour un même champ. Corrolaire : seul le premier choix des choix multiples (cases à cocher) étaient donc enregistrés.

On ajoute une clé primaire simple sur la table, ce qui a l'avantage de faire fonctionner la recherche de manière plus robuste, et on migre en renommant la table, la recreant, et transferant les donnees de l'ancienne vers la nouvelle.
Migration et installation validée en MySQL, à valider en SQLite (mais devrait être OK)

correction d'un bug dans la balise #FORMULAIRE_FORMIDABLE

Securite : toujours utiliser l'id passé en argument de #FORMULAIRE_FORMIDABLE et non celui qui est posté et a pu etre corrompu. On centralise la conversion de l'id en id_formulaire

Extensibilite : fournir id_formulaire et id_formulaires_reponse si possible en sortie de la fonction traiter (pour les pipelines)

externaliser les boutons dans un inclure surchargeable, car il est parfois necessaire de pouvoir les surcharger pour respecter une charte graphique (boutons image par exemple)

A l'installation quand on migre les formulaires de f&t on conserve le meme id c'est beaucoup plus comprehensible (et tant pis si il y a quelques trous)

- lors de l'enregistrement d'un objet on reconnait les raccourcis qui inserent un formulaire et on maintient les liens
- sur la fiche d'un formulaire on affiche les objets qui l'utilise
- sur la fiche d'un objet on affiche les formulaires utilisés
- correction du modèle <formXX> pour ne pas mettre en cache le formulaire dans le site public tout en affichant le formulaire dans l'espace privé
- introduction du modèle <formidableXX> qui permet d'inserer un formulaire avec une syntaxe courte pour #ID_FORMULAIRE=XX
- chaines de langue et styles
- recreation des liens formulaires-articles lors de l'import f&t

Pour le moment, on ne rattrape pas les liens sur les formulaires déjà utilisés dans des contenus sur une installation existante de formidable. Pour forcer la mise à jour des liens il suffit d'enregistrer le contenu qui utilise un formulaire

- les formulaires a la poubelles
- les reponses associees a un formulaire supprimé
- les reponses a la poubelle
- les champs des reponses associés à une réponse supprimée

formulaire_formidable_#ID_FORMULAIRE
formulaire_formidable_#IDENTIFIANT

A l'installation les formulaires importés de f&t ont tous l'identifiant formXX avec XX l'ancien ID de form dans f&t
Du coup le modele <formXX> recupere le formulaire avec identifiant formXX et assure la compatibilte des contenus existants

Les actions supprimer ne font que mettre en statut poubelle/refuse, plus de risque de pertes de données à cause d'une action maladroite
on enleve le bouton "Supprimer" sur la page d'un formulaire

Lors de l'import f&t les formulaires sans réponses sont mis en statut proposé, les autres en publiés

on masque le gros message vert et le gros bouton "Reinitialiser" trop affordants qui sont proposés par saisies.
 A la place un message simple en haut, et le bouton "Revenir à la dernière version enregistrée" dans le cartouche en bas, qui apparaissent dès qu'une saisie est modifiée

Attention : on branche le trunk en v1 qui reste la version stable. Le trunk va subir du nettoyage/refactoiring et passe en v2-dev

Correction rapide des valeurs par défaut, lors du chargement, on insère les options "defaut" en tant que valeurs du charger() comme le fait d'ailleurs Saisies dans son API. Le mieux serait évidemment d'utiliser les "nouveautés" (plus tant que ça) de Saisies dans Formidable.

Cela devrait corriger toutes ces saisies "selection" ou "oui_non" qui n'affichaient pas les bonnes valeurs par défaut.

Les dernière modifs sur "date_crea" avait pété Formidable chez tous ceux qui l'avaient déjà et ne l'installaient pas à zéro.

En effet, au moins en MySQL, il *faut* indiquer le type de donnée quand on fait un CHANGE sur le nom d'un champ, on ne peut pas juste donner le nouveau nom.

Du coup ça ne jouait pas la requête et on avait toujours "date_crea" dans la base.

Ajout d'une date de création du formulaire (nommée date_crea parce que date est un mot reservé mysql)
Incrémentation mineure de version et de shéma

Mettre en stable, car même s'il y a quelques bugs à corriger, ça fait longtemps que c'est utilisé sans changement majeur.

Version 1.8.4 : report de r78009, passer le champ saisies de la table spip_formulaires en longtext pour permettre d'y stocker des formulaires longs

Ne pas laisser des entités dans les champs de mail qui ne gèrent pas le HTML : c'était déjà le cas pour le sujet mais pas pour le nom de l'envoyeur. On fait donc filtrer_entites().

puisque le message de retour passe par |propre, inutile de mettre un <br /> devant... cela évite d'avoir un <br /> en début de message

comme le fait remarquer cedric, il n'est pas très poli de ne mettre aucun message après la validation d'un formulaire. Mettons un message par défaut à l'enregistrement en bdd.

possibilité d'exclure certains champ de l'analyse (utile notamment lorsque on des champs qui sont uniquement là pour conditionner l'affichage d'autres champs)

pouvoir aussi exporter les stats sur choix_couleurs (remarque : il serait bon de prévoir un mécanisme générique en fonction de la description de la saisie

analyse des données : prendre en compte le fait que désormais les saisies de type sélection peuvent avoir des sous-saisies (optgroup)

Version 1.5.2 pour formidable et 3.0.3 pour facteur désormais.

après réflexion, on peut utiliser la constante cnil periode aussi, de toute facon la surcharge se fera ds tt les cas ds mes_options.php