Cf : http://thread.gmane.org/gmane.comp.web.spip.zone/36491

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

Vérification que les réponses sont bien contenues dans une variable de type tableau et que le nombre d'éléments n'est pas nul

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

Changement de méthode d'obtention de l'id_formulaire pour calculé l'id_auteur scrambled. Avant il était toujours vide et c'était seulement l'id_auteur et le mot de passe qui servait au scramble.

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

Une nouvelle balise qui sera peut-être utile à celleux qui veulent afficher leurs réponses enregistrées.

#VOIR_REPONSE{champ} à utiliser dans une boucle (FORMULAIRES_REPONSES).

Par défaut ça afficher la même chose que #VOIR_SAISIE. Mais on peut faire des variantes pour ne sortir que la valeur (en HTML mais sans le label et l'entourage) ou que la valeur brute dans la base.

#VOIR_REPONSE{selection_1, brut}
#VOIR_REPONSE{selection_1, valeur_uniquement}

En troisième argument on peut aussi passer la chaîne qu'on veut afficher pour les champs qui n'ont pas de réponse (champ vide). Sinon c'est le truc par défaut "Sans réponse". On peut y mettre la chaîne vide si on ne veut rien.

les bornes doivent êtes de type x.y.z, de plus, quand un plug n'est que pour spip 3.0.* alors les bornes mini des necessite doivent êtes ceux des versions qui fonctionne sous spip 3.0.x

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

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