Lorque la compatibilité 3.0 ne sera plus là
Ticket pour mémoire, lorsque l'on décidera officiellement de ne plus supporter SPIP 3.0, des choses que l'on pourrait casser en sortant une vrai v4
#DIV|sinon{li}
.
simplifier les controleurs/vue pour ne plus avoir ce Maintenir le #DIV
comme déprécié pour les plugins qui s'appuieraient dessus.
En même temps saisie_balise_structure_formulaire
> conserver pour les plugins qui s'appuient dessus, mais simplifier en renvoyant div systématiquement.
Supprimer également l'option saisies_base_conteneur : définit la balise englobante de la saisie (balise div par défaut en SPIP 3.1+, et li avant)
-> fait
Ne plus supporter les clés numériques implicites dans saisies_chaines_2_tableau
Clés numériques implicites > porte ouverte à des erreurs d'affectation en cas de modification de la liste des options (+ ca complexifie le code).
-> On garde cette possibilité. Ca complexifie un peu un code mais qu'on manipule rarement, et si on casse ca peu créer des mauvaises surprises.
Ne plus surcharger les css pour afficher les labels dans l'espace privé
vu que spip le fait par defaut :
-> fait
supprimer les datas pour garder data ?
il faudrait prévoir à ce compte un script de migration (à appliquer par ex à formidable). Mais du coup ca necessite une synchronicité des versions...
-> discussion ici https://git.spip.net/spip-contrib-extensions/saisies/pulls/84
Corriger des chaines des langues
Avoir des labels des chaines plus cohréents avec les lieux où appelé.
Exemple : dans auteurs.yaml on a
description: '<:saisies:saisie_auteurs_explication:>'
ca devrait être par cohérence saisie_auteurs_description
une compat historique
// compat historique
if (isset($saisies['options']['poster_afficher_si']) and !isset($saisies['options']['afficher_si_avec_post'])) {
$saisies['options']['afficher_si_avec_post'] = $saisies['options']['poster_afficher_si'];
}
compat hist pour un code distribué pendant 3 jours... on pourrait largemenet supprimer dès maintenant, mais gardons pour l'instant et nettoyons au grand nettoyage
saisies_migrer_afficher_si_remplissage.php
fonction d'insertion d'assets
On a plein de code marqué comme "pour compatibilité".
De manière general > faire un grep pour les termes 3.0, 3.1, 3.2, compatibilite et voir le scommentaires à ce sujet
-> fait
li_class
même probématique que pour datas/data -> https://git.spip.net/spip-contrib-extensions/saisies/pulls/84
-> fait, on garde la compat
pipeline saisies_afficher_si_js_saisies_form deprécié
On pourra supprimer la compatibilité. C'était utilisé de toute facon que par agenda.
-> fait
des trucs de jquery ui dependant de la version de SPIP
formulaires_construire_formulaire_charger()
et sans doute dans le html
-> fait, on n'utilise plus jQueryUI
Utiliser #CONST plutôt qu'#EVAL
8029ff7f
-> fait
Supprimer la definition de array_walk_recursive, car sera en PHP 7.
-> fait
saisies_modifier()
:
nouveau_type_saisie
directement à la racine de la saisie, et pas dans options
. Supprimer la compatibilité historique.
-> fait
css/formulaire_constructeur.css
/* SPIP 3.0 compat avec li.selecteur_item */
-> fait
saisies_charger_champ()
Fais un test pour l'existence d'une fonction native en php 5.2
-> fait
Supprimer l'ancienne syntaxe des heritages
Jamais documenté. À voir sur la zone si on a des plugins qui l'utilise.
-> fait