J’avance doucement sur le long chemin de la refonte de Contrib…
Là je viens de terminer une version fonctionnelle de SVP Typologie, le plugin connexe de SVP qui s’occupe de toutes les typologies de plugin, à savoir pour l’instant, les catégories et les tags.
Ces typologies sont gérées par mots-clés techniques (groupes spécifiques) et font appel à une table de liens spip_plugins_typologies pour les affectations.
Le plugin, en lien avec SVP API qui fournit une API REST pour les plugins de SVP, permet à tous les sites client qui le souhaitent de récupérer la liste des catégories ou des tags, leurs affectations ainsi que les plugins. Pour ces derniers l’API remonte aussi les typologies en se servant uniquement des données de SVP Typologie.
Pour vous rendre compte de son fonctionnement il est possible d’interroger un serveur de tests avec des requêtes comme :
Il faudrait maintenant développer un peu le privé de SVP Typologie pour créer, affecter plus simplement les types aux plugins (avis aux amateurs d’ergo !).
De fait, j’ai commencé à dépiauter SVP (branche 3.3-dev) de tout ce qui concerne la gestion des catégories et des tags:
les colonnes categorie et tags de spip_plugins ont été supprimées,
les fonctions d’insertion des plugins en base tiennent compte de ces suppressions même si pour l’instant la lecture du XML récupère toujours ces attributs/balises qui sont supprimés après le traitement de fusion éventuel.
le filtre de recherche sur la catégorie a été supprimé dans le formulaire mais les fonctions de recherche gardent encore l’argument categorie qui sera enlevé d’ici peu.
la balise SVP_CATEGORIE a été supprimée aussi
Il reste encore des API qui manipulent un argument categorie mais cela devrait disparaitre avec la refonte de Plugins SPIP.
Sauf remontée contraire, cette version est totalement compatible avec les sites de production (mode runtime) mais absolument incompatible avec Plugins SPIP ou le squelette d’annuaire SVP Skel.
Les prochaines étapes sont :
revoir l’API contenue dans svp_fonctions.php qui est essentiellement utile à Plugins SPIP et la ranger autrement.
Scinder le SVP obtenu en deux plugins, SVP pour gérer les installations et SVP Référentiel pour gérer la constitution de la base des plugins. Pendant un temps (plus ou moins long) SVP nécessitera le référentiel avant d’être remplacé par une version Composer.
De fait, j'ai commencé à dépiauter SVP (branche 3.3-dev) de tout ce qui
concerne la gestion des catégories et des tags:
- les colonnes categorie et tags de spip_plugins ont été supprimées,
- les fonctions d'insertion des plugins en base tiennent compte de ces
suppressions même si pour l'instant la lecture du XML récupère toujours ces
attributs/balises qui sont supprimés après le traitement de fusion éventuel.
- le filtre de recherche sur la catégorie a été supprimé dans le formulaire
mais les fonctions de recherche gardent encore l'argument categorie qui
sera enlevé d'ici peu.
- la balise SVP_CATEGORIE a été supprimée aussi
(y)
Les prochaines étapes sont :
- revoir l'API contenue dans svp_fonctions.php qui est essentiellement
utile à Plugins SPIP et la ranger autrement.
- Scinder le SVP obtenu en deux plugins, SVP pour gérer les installations
et SVP Référentiel pour gérer la constitution de la base des plugins.
Pendant un temps (plus ou moins long) SVP nécessitera le référentiel avant
d'être remplacé par une version Composer.
Donc l'API de svp_fonctions va migrer dans un plugin uniquement utile à plugins.spip ou directement dans plugins.spip ?
Merci pour le point d'étape, mais j'ai assez peu de dispo en ce moment, je n'ai pas suivi toutes les discussions sur la refonte, et je ne connais pas bien non plus l'existant de SVP.
Il faudrait maintenant développer un peu le privé de SVP Typologie pour créer, affecter plus simplement les types aux plugins (avis aux amateurs d'ergo !).
Là j'ai probablement raté un morceau : de quels types parles tu ? Les plugins ne se déclarent/qualifient plus eux même depuis les attributs (catégories et tags) du paquet ?
Il faudrait maintenant développer un peu le privé de SVP Typologie pour créer, affecter plus simplement les types aux plugins (avis aux amateurs d’ergo !).
Là j’ai probablement raté un morceau : de quels types parles tu ? Les
plugins ne se déclarent/qualifient plus eux même depuis les attributs
(catégories et tags) du paquet ?
Je parle des typologies ‹ catégorie › et ‹ tag › des plugins.
Ces deux typologies existaient dans la table spip_plugins (champs categorie et tags) mais seule la catégorie était utilisée.
Cette catégorie était récupérée via le XML (attribut dans paquet.xml ou balise dans plugin.xml).
Avec SVP Typologie, on peut reproduire les catégories et les tags mais en s’affranchissant complètement des XML et de la table spip_plugins.
Les typologies et affectations sont gérées dans des tables séparées qui ne sont utiles que sur le site serveur, a priori, Plugins SPIP ou à terme Contrib après réunification.
Ainsi on a une plus grande souplesse pour affecter ou modifier les affectations ainsi que la liste des types pour une typologie donnée car les plugins n’ont plus à être modifié.
Par contre, via l’API REST de SVP API, on peut récupérer à tout moment les plugins avec leur typologie, les typologies, les affectations…
De mon point de vue, on a tout en mieux et il va être possible aussi de mettre en place les tags assez facilement.
