- saisies d'un formulaire
- traitements d'un formulaire
- réponse pour un champ multivalué

Sont désormais en json, via
```
$formidable_serialize = charger_fonction('formidable_serialize', 'filtre');
```
C'est un filtre pour faire le sysmétrique à `|formidable_serialize`,
même si en fait on n'a pas vraiment de raison de l'utiliser en filtre.

Sont gardés en serialize_php :
- les paramètres passées en url pour l'action de recup de fichier
- la base du calcul des hash md5 dans les sessions (utilisés pour
s'assurer qu'on ne perd pas des données en cas d'interruption de config
d'un formulaire -> il faut surtout pas rompre la compat).

- Le filtre `|tenter_unserialize` est déprécié.
- Il est remplacé par `|formidable_deserialize`.
- Ce filtre peut recevoir au choix :
  * Un tableau, qu'il retourne tel quel
  * Un tableau serializé via `json_encode`
  * Un tableau serializé via `serialize`
- Dans les deux dernier cas, il renvoie la version deserializé, en cas
de réussite, sinon l'argument passé.

Exemple

````
include_spip('formidable_fonctions');
'filtre');
$a = ['a' => 'a'];

$a = json_encode($a);
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);

$a = serialize($a);
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);

$a = serialize($a).'plop';//Serialisation corrompu
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);
````

Ainsi, pas besoin de convertir tous les formulaires de `serialize`  à
`json_encode`  à la mise à jour du plugin formidable :
on peut le faire au fur à mesure qu'on modifie les champs/traitements
d'un formulaire.

On utilisera donc ce filtre à chaque fois que l'on veut déchiffrer
depuis la BDD :
- * traitements d'un formulaire
- * saisies d'un formulaire
- * réponse d'un champ multivalué (ex: checkbox)

Crayonnage des champs. Pour que WHERE des requete SQL multitable fonctionnent correctement, il faut passer par des alias.
Cf. spip/spip#5112

- pour les checkbox, stocker de manière sérialisée
- pour les choix_grille, stocker correctement, tout court, et déjà
permettre l'édition

Attention on s'appuie sur `saisies_est_tabulaire()` qui a été corrigée
dans saisies@2e507635

Eviter un warning lors de l'upgrade pour cause de lien mort, et optimiser les liens morts dans formidable_optimiser_base_disparus()

Ceci a pour but de mieux profiter des futures évolutions des markups
des saisies `radio`/`checkbox` (passage en `<fieldset>`), sur lesquels `champ` s'appuie.

crayons sur les champs d'une réponse : passer par objet_modifier, afin de pouvoir profiter si besoin des pipelines (cas du plugin formidable_participation)

Issue 42 : améliorer la liaison des formulaires avec un champ vu comme pour les documents : il FAUT savoir quels liens ont été mis à la main et lesquels sont automatiques suivant les modèles dans les textes. Surtout qu'il y avait un bug : ça virait les liens même ceux mis à la main si on les trouvait pas dans les textes. Maintenant ça fait tout comme les documents : si le form n'est plus en modèles dans les textes, ça passe juste en vu=non, mais le lien reste.

Lors de la réception d'un crayon, utiliser saisies_verifier() pour vérifier la saisie, et pas l'appel direct à verifier_xxx(). Cela permet de tester si la saisie est obligatoire. Fix #31

Reconnaitre la signature <formulaire|formidable|identifiant> (un modèle formidable ne contient pas forcément id=identifiant)

enregistrer les config de formidable dans #CONFIG{formidable} et pas dans #CONFIG{formidable/analyse}

pouvoir effacer régulièrement les réponses d'un formulaire. Évite de conserver plus qu'il ne faut des données potentiellement privées

- un statut poubelle -> est supprimé
- un statut refusé -> n'est pas supprimé
Ca correspond en gros à ce qui existe pour les articles

mettre dans un génie à part l'effacement des fichiers de réponse stockés sous forme de timestamp, dès fois que corbeille sera là

pour que les hashage des réponses fonctionne, on passe par un génie à
part

Un pipeline qui permet de gérer l'ordre des traitements par formidable. On l'appelle par défaut, pour que les emails partent APRÈS l'enregistrement, ce qui permet le cas échéant d'avoir le numéro d'enregistrement.

Après des années avec une table de liaison générique, on ajoute enfin le formulaire editer_liens… uniquement sur les objets configurés pour ça évidemment.

- 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