47475387d8
(c'est à dire belle lurette), `spip_desinfecte()`, qui est appliqué sur
`$POST` à l'initialisation de SPIP, est récursif.
Inutile donc de l'appliquer à nouveau en amont.
Merci @rastapopoulos pour la fouille dans les archives.
des champs vides pour les options (`''`), ne pas enregistrer une option
vide en base (posait problème notamment pour les vérifications de
nombre).
Bug introduit en e3bed20205 lors de
l'ajout des vérifications multiples dans le constructeur.
+ simplification de code, notamment en cas d'absence de verif.
- Barre d'actions : utiliser les nouvelles icônes + ajustements CSS
- Boutons Spip 4
- Adaptations des styles pour Spip 4. On en profite pour ranger et reformater la CSS.
- plus d'emploi de `#DIV|sinon{<autrechose>}`
- plus d'emploi de `saisie_balise_structure_formulaire()`
- `saisie_balise_structure_formulaire()` est conservé pour pas conserver mais renvoie
systématiquement `div`
- idem pour `#DIV`
Ce qui m'étonne c'est que "cela marchait avant"...
+ un commentaire qui n'est plus valable avec le nouveau gestionnaire d'afficher_si.
Par contre le code qu'il commente reste valable, mais sa raison d'être
est autre.
Pour le name d'une saisie, utiliser la verification `slug` comme
vérification.
Qui a le mérite :
- de ne pas laisser passer les majuscules
- de proposer une alternative pour que les gens puisse proposer
facilement le bon name
Fix spip-contrib-extensions/champs_extras_interface#1
Au cas où une personne aurait la sombre idée de mettre 2 constructeur de formulaire sur la même page, se baser sur l'identifiant de session pour identifier de manière unique les fieldset d'une config d'un champ
* Fonctionne quelque soit la position du fieldset et son niveau d'imbrication
* Fonctionne avec l'option pour activer les étapes
* Incompatible avec l'option `pliable`
Par défaut, cela ne change rien au résultat de saisie_lister_disponibles() (pour ne pas casser), mais si on passe un paramètre $inclure_obsoletes = false, alors les saisies obsolètes seront exclues.
On s'en sert notamment pour ne pas afficher les saisies obsolètes dans le constructeur de formulaire. On pourra modifier les saisies obsolètes d'un formulaire, mais on ne pourra pas ajouter de nouvelle saisies obsolètes.
On met la saisie oui_non comme obsolète.
Lorsqu'on reprend la modification du formulaire, après avoir par exemple fermé un onglet, vérifier qu'il n'y pas de modification du md5 du formulaire initial. Si oui, alors le formulaire_initial prend le pas sur tout ce qu'il y avait en session, et remplace le formulaire qui était en session.
cf spip-contrib-extensions/formidable#8, cas 2 (vérification en amont du formulaire).
Reste à faire le cas 1, vérification à la fin du formulaire.
- De toute facon on n'en pas besoin
- Le transformateur de condition va peter un cable et produire des
conditions invalide du style data-afficher-si="||" lorsque la saisie est
configurée avec un afficher_si de type '<test> || <test2>'
- et du coup si jamais on a un afficher_si dans la description yaml
d'un type de saisie/de verification, elle ne marchera pas (ex. avec la
verification des types mimes de fichier)
historiques, que des saisies n'aient pas d'identifiant (@). Dans ce cas,
on les génère au moment du chargement du constructeur, avec
saisies_generer. Note : cela ne génère que pour les saisies qui n'ont
pas encore d'identifiant, et cela s'assure que l'identifiant est unique.
le problème venait du fait que saisies_verifier() n'était pas capable de
gérer les champs imbriqués (aussi parce que set_request n'en était pas
capable, cf https://core.spip.net/issues/4110).
Du coup il faut parser en profondeur le tableau.
Merci Rastapopoulos d'avoir signalé le problème et la piste de solution.
On peut vouloir normaliser les paramètres de saisies.
Cas concret : la saisie "choix d'événements" propose des dates min/max
comme paramètre. Il faut qu'on puisse normaliser les paramètres en
formats datetime (SQL).
Maïeul
tcharlss
RastaPopoulos
maieul@maieul.net