- 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).
uniquement par le plugin `formidable_quizz`, actuellement non maintenu
et non publié.
Ce pipeline n'était pas générique, car le remplacement des `@@` ne
concerne pas que l'affichage résumé des réponses, mais aussi en
différent endroit (message de retour par exemple).
On créé deux pipelines plus générique :
- `formidable_pre_raccourcis_arobases`
- `formidable_post_raccourcis_arobases`
On supprime donc le pipeline `formidable_affiche_resume_reponse`.
On simplifie par ailleurs la signature de la fonction
`formidable_raccourcis_arobases_2_valeurs_champs()`.
1. En supprimant les deux derniers arguments passés par références (`$valeurs` et
`$valeurs_libellees`).
La seule raison de ce passage par référence, qui n'était utilisé sur
toute la zone que dans **UN** appel à la fonction, était précisement
de passer les valeurs libellées en arguments du pipeline `formidable_affiche_resume_reponse`. Puisqu'on supprime ce pipeline, plus besoin de ces valeurs.
2. On regroupe tout les paramètres en troisième arguments, dans
$options, tout en assurant une rétrocompatibilité (pas d'autre usage de
`formidable_raccourcis_arobases_2_valeurs_champs()` sur la zone, mais j'ai
du code perso qui l'utilise, et il n'est pas impossible que d'autres
fassent de même.
3. On ajoute une option `'contexte'` pour indiquer le contexte d'appel
de `formidable_raccourcis_arobases_2_valeurs_champs`, ce qui permet de
remplacer utilement le pipeline `formidable_affiche_resume_reponse`.
`traiter_email_destinataires` : reçois un tableau d'emails (ou une liste
séparée des virgule).
Se complète avec l'option `traiter_email_destinataires_methode_methode`
qui peut être :
- `remplacer` pour que les destinataires passés par squelettes
remplacent ceux de config
- `ajouter` (valeur par défaut) pour qu'ils viennent compléter la liste.
Exemple d'appel
````
#FORMULAIRE_FORMIDABLE{coordonnees,#ARRAY{input_1,plop}, #ARRAY{traiter_email_destinataires,22@22.fr,traiter_email_destinataires_methode,remplacer}}
````
qu'on ne veut pas, par ailleurs, disposer d'un lien et d'une information
sur "à quel champ correspond les fichiers".
D'autant plus que cette suppression dans le corps du mail ne marchait plus depuis un
certains temps (lorsqu'on a séparer `$saisies` et
`$saisies_notifications`).
En supprimant cette suppression (!), on bugfix le cas où :
- `_FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION` était sur `false`
- mais on disait de mettre les fichiers dans le corps du mail
=> `_FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION` à false ne changeait
rien.
Cf. https://discuter.spip.net/t/formulaire-formidable/160827/6
Sauf pour les importes depuis f&t, vu que tjr en .yaml + chaine de
langue + maintien compat historique
On en profite pour passer systématiquement datas à `saises_chaine2tableau()`, afin
de profiter systématiquement de `_T_ou_typo()` (même si en l'occurence,
ca passait deja tout le temps, on ne sait jamais pour l'avenir si on
stocke autrement les saisies de formidable...)
hop @rastapopoulos
en faisant de l'archéologie dans la doc de de formidable, j'ai suis tombé sur https://contrib.spip.net/ecrire/?exec=article&id_article=3486
j'ai vu que prévoyais au départ une fonction `update` pour les traitements. Et de facto cette fonction existait pour le traitement enregistrement.
Mais par ailleurs il n'y a aucun appel à cette fonction dans le code. De plus il me semble que c'est piégeux, car ca risque de demultiplier le code. Comme par ailleurs j'avais moi même ajouté `$retours['modification_reponse'] = true` au retour du traitement enregistrer, permettant aux traitements ultérieurs d'avoir l'info, je ne vois pas la logique de cette fonction distincte.
Je supprime donc.
date_soumission devient date_envoi, plus proche du langage courant, tout
en évitant de confondre avec date_reponse qui pourrait être la date de
l'objet.
On fait pas de migration de structure SQL car il s'agissait d'une branche de dev qui n'a existait que 24h et n'a a priori été déployé que chez le dev.
Permet d'ajouter automatiquement ses propres destinataires.
Exemple d'usage :
- j'associe via cextras un email aux evenements
- je crée un formulaire formidable avec une saisie evenements
- je notifie automatiquement tout les emails associés aux évenements
choisis par l'internaute
effacer TOUT les anciens résultats, et pas uniquement pour les champs
qui viennent d'être postés.
En effet, les nouvelles valeurs peuvent conditionner le non-affichage
d'un champ pour laquelle une valeur avait été enregistrée avant. Dans ce
cas il faut aussi effacer cette valeur.
Exemple
- Le formulaire est configuré de sorte que si la case_1 est cochée, alors afficher le champ input_1.
- Premier enregistrement de la réponse : case_1 cochée, champ input_1
valant 'toto'
- Modification de la réponse : case_1 décochée.
- Avant ce commit, la valeur 'toto' restait associée à case_1 en base,
faussant tableau d'analyse et autre
- après ce commit, ce n'est plus le cas
Maïeul
RealET
nicod_
nicod@lerebooteux.fr
yohooo