Trier les traitement par ordre alpha, on aura ainsi toujours le meme ordre, et non pas quelque chose qui change en fonction du path et des plugins actifs

[Salvatore] [source:_plugins_/formidable/trunk/lang/ formidable] Export depuis http://trad.spip.net de la langue es

L'explication est un texte avec des raccourcis SPIP possible, on passe dans propre() (comme déjà dans la saisie d'ailleurs).

liste des reponses : on affiche l'IP uniquement si pas d'auteur connu, ca fusionne les 2 colonnes, et quand l'IP est un hash on affiche que les 8 premiers caracteres, ca suffit

+ par defaut les formulaires avec le plus de reponses en tete
(il faudrait peut etre ceux avec les reponses les plus recentes en fait, a voir)

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

En SPIP3 les fonctions d'édition ne marchent plus pareil, notamment je crois qu'avant le set() ne prenait pas en charge les champs "saisies" et "traitements" alors que la fonction modifier() de l'API si.

Du coup, il faut bien sérialiser en amont, et faire une seule fois la modif.

suppression du echo devant $exporter_csv, qui rajoute le nom du fichier à la fin de l'export sur certains serveurs
incrémentation mineure de version

report de 81164

Retrouver l'édition des formulaires dans le privé, maintenant qu'ils ont un statut (je vais pas y arrriver tout seul :-p)

- 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']

[Salvatore] [source:_plugins_/formidable/trunk/lang/ formidable] Export depuis http://trad.spip.net de la langue es

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

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)

[Salvatore] [source:_plugins_/formidable/trunk/lang/ formidable] Export depuis http://trad.spip.net de la langue es

[Salvatore] [source:_plugins_/formidable/trunk/lang/ paquet-formidable] Export depuis http://trad.spip.net de la langue es

[Salvatore] [source:_plugins_/formidable/trunk/lang/ formidable] Export depuis http://trad.spip.net de la langue es