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

simplifier les controleurs/vue pour ne plus avoir ce #DIV|sinon{li}.

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

dans `saisies_verifier_afficher_si()`

	// 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

->fait

saisies_migrer_afficher_si_remplissage.php

Ca date de 2018, les plugins qui pouvaient en avoir besoin ont largement eu le temps de s'en servir depuis lors. -> En même temps c'est un fichier à part, qui n'est jamais appelé en tant que tel > ok pour garder.

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