Hello,
avec l’arrivée de SPIP 3, il a fallu commencer à migrer les plugins petit à petit.
Il existe d’ailleurs une page de Contrib qui tente de recenser tous les plugins qui ont été spécifiquement adaptés pour SPIP 3.
Pour beaucoup de ces plugins migrés la solution a consisté à prolonger la compatibilité de la version en cours, souvent en rajoutant une balise plugin supplémentaire source d’erreur (attribut + necessite spip dans la même balise, version différente entre les balises…) et surcroît souvent inutile de complexité.
Ce faisant, on s’est souvent privé de toute la puissance des nouveautés de SPIP 3 qui intègrent aujourd’hui nativement les itérateurs, une nomenclature de squelettes dans le privé, une configuration “type CFG” plus limitée mais souvent suffisante et la plupart des outils Bonux largement utilisés dans les plugins SPIP 2. Cela conduit à trainer des dépendances inutiles comme Bonux, Saisies et CFG pour le plugin jqueryCorner qui ne fait qu’encapsuler une librairie jQuery. Cet exemple est révélateur car c’est la compatibilité à SPIP 2 qui “oblige” finalement le développeur à nécessiter ces plugins même pour SPIP 3 (enfin presque car on aurait pu s’en passer complètement).
Donc pour des plugins qui utilisent des frameworks comme CFG, Saisies, Bonux… ou intègrent une interface privée, il me semble que la meilleure solution serait de systématiquement créer une branche. Mais pour cela il faut aussi brancher correctement certains de ces frameworks en SPIP 3.
Je serait d’avis d’avoir la stratégie bottom-up suivante :
- Les frameworks :
-
CFG : dans la plupart des cas, on peut migrer ces formulaires en formulaires configurer_xxx de SPIP 3, le stockage utilisé étant généralement celui par défaut. L’accès à la configuration se fait toujours par l’icône de config de l’admin des plugins mais la page CFG n’est plus alimentée. A voir si c’est un souci. #CONFIG fonctionne toujours. On applique aussi la nouvelle nomenclature des formulaires.
-
Bonux : est remplacé par Itérateurs intégré à SPIP 3 pour 90% des services proposés. Il reste cependant toujours à traiter le cas de la fonction _T_ou_typo() qui est utilisée dans une 12 de plugins très populaires. Y a t-il un souci à l’intégrer dans le core et si oui, y a-t-il une alternative ?
-
Saisies : le propos de ce mail n’est pas de savoir si Saisies devrait ou pas rejoindre le core mais a minima il faut créer une branche de Saisies débarrassée de Bonux. A ce propos, je ne sais pas si les briques de Saisies sont cohérentes avec la nomenclature SPIP 3 du privé ? Ensuite c’est vrai que réfléchir à quel framework pour SPIP 3 serait pas mal.
- Les autres plugins
A partir de la migration des outils, on continue la stratégie en branchant systématiquement les plugins destinés à fonctionner sous SPIP 3 en appliquant les nouveaux schémas : déclaration des objets, nomenclature du privé sous Z, configurer_xxx
Je ne sais pas si ma liste d’actions est exhaustive (surement pas) mais ça me parait le bon moment pour le faire, surtout qu’il n’y a pas de souci à faire ces actions petit à petit.