Formidable 2.9.4 : On permet d’avoir un champ où les valeurs sont uniques. Par exemple un champ email où 2 personnes ne peuvent pas remplir le même email.

Les listes de reponses sont par defaut non signifiantes car n'affichant aucune autre information que la date de saisie et l'IP source.
On permet de configurer pour chaque formulaire une chaine qui sera utilisee pour afficher un resume de chaque reponse (les champs @input_1@.. etant remplaces par leur valeur).
Ceci rend les listes de reponse beaucoup plus utilisables.

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.

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)

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

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

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

bugfix sur breadcrumb des reponses et formulaires non publies
formulaire de recherche dans la page des formulaires
nombre de formulaires et de reponses dans les listes

a l'installation de formidable, import automatique de tous les formulaires et sondages de forms&tables
(mais il manque la prise en compte du statut, qui serait mieux, et surtout l'import des données, prochain step)

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

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

- paquet.xml et administration nouvelle mode
- un peu de phpdoc.