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.

Retour avec message d'erreur si aucune réponse exportée.

bugfix utilisation des div au lieu de ul/li dans les formulaires en SPIP 3.1+, necessite saisies 2.3.0 minimum

Remonter le message de retour du formulaire pour que les traitements puissent l'utiliser, le modifier par exemple

pour un admin restreint à partir du formulaire de configuration de
Formidable et non plus à partir d'une variable globale

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.

Controle du numero d'id_reponse en base
Mise à jour du champ maj dans la table spip_formulaires_reponses
Vérification de l'id_auteur lorsqu'un id_formulaires_reponses est fourni pour éviter qu'un 
auteur modofie les réponses d'un autre

spip.php?page=formulaire&id_formulaire=2&var_mode=recalcul

On reduit les risques de sortie anormale de traiter() sans message d'erreur, et on log $_POST dans un post-mortem pour retrouver la trace du problème a posteriori et recouvrer eventuellement les donnees (on préfere utiliser json_encode qui ne cassera pas lors du decode malgré l'échappement des < par spip_log)

lors d'un retour de formulaire, renvoyer vers une ancre identifiant le formulaire. On met la référence à l'ancre dans l'attribut action dans tt les cas. En effet, même si on redirige vers une autre page une fois le formulaire validé, il faut prendre en compte le cas des erreurs dans la partie V du CVT

Statut archive (refuse) pour les formulaires : ils ne sont plus visibles en ligne mais on conserve le contenu et les reponses
+ la balise #FORMIDABLE n'affiche que les formulaires publies (ou prop en preview) dans le site public

- les traitements doivent noter qu'ils ont bien ete executes dans ['traitements'] pour ne pas etre executes plusieurs fois
- un traitement qui veut/doit passer apres un autre peut ne rien faire et rendre la main au premier tour pour laisser l'autre se faire
- on refait la boucle 5 fois au maximum pour executer tous les traitements
- si des traitements n'ont pas pu etre executes, on declenche un mail au webmestre avec l'erreur et un dump de  dans le mail pour ne pas perdre de donnees
- si aucun traitement n'a ete execute (defaut de configuration?) on declenche un mail au webmestre et un dump de  dans le mail pour ne pas perdre de donnees

Cette modification entraine une petite incompatibilite sur les traitements perso : ceux-ci seront executes 5 fois et une erreur sera generee si ils ne sont pas modifies pour renseigner ['traitements']

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

correction d'un bug dans l'utilisation de 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)

Le raccourci <formXX> injecte le titre du formulaire en tête pour assurer une migration en douceur (equivalent fonctionnel, ne pas obliger à reprendre les contenus à la main)

formulaire_formidable_#ID_FORMULAIRE
formulaire_formidable_#IDENTIFIANT

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

quand le formulaire n'a encore aucun champ de saisie, soyons un peu plus smart et convivial dans ce qu'on affiche : un message qui explique la situation plutot qu'un bouton "enregistrer" sorti de nulle part et incompréhensible

squelette HTML du formulaire d'edition, declaration champs_editables et champs_versionnes dans l'API tables_objets_sql, nommage génériques et implémentation des fonctions de editer/formulaire (avec support des vieux nommages)
+ ajout d'une chaine de langue sur erreur de format
+ bugfix verification unicité de l'identifiant

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.

Rectification de l'évaluation des options du formumlaire pour vérifier si un formulaire est modifiable à réponse unique et retrouver la réponse en cas d'anonymisation.
Je ne comprends pas comment ça pouvait marcher avant...