Les outils de base SVP / STEP / SMART-PAQUETS

En premier lieu il faut finaliser les fonctions essentielles de SVP et brancher STEP (à l’occasion pourquoi ne pas le renommer STP) sur la base de plugins constituée par SVP :

• SVP - une todo rappelle la liste des tâches à terminer pour obtenir une première version opérationnelle Développement de SVP v0.
  • Changer le mode d’actualisation d’un dépôt en utilisant des update pour éviter l’incrémentation sans fin des id
  • Ajouter une date de création pour la première insertion d’un paquet en base de données
  • Ajouter une date de dernière mise à jour d’un paquet basée sur le dernier commit
  • Trouver une méthode pour récupérer les logos
• STEP - limité à l’installation et la mise à jour des plugins utilisés par le site en s’appuyant sur la base SVP et sur un module de chargement.
  • revoir la base STEP sans redondance ni modification de celle de SVP
  • limiter STEP à la constitution d’une liste de plugins à installer ou à mettre à jour
  • créer un module de chargement opérant soit par zip, soit en SVN, soit en Git suivant le dépôt et le choix du webmestre.

Suite à ces évolutions, SVP et STEP intègrent la liste des extensions du core. La question : que proposer par défaut sans ces extensions ?

Pour la génération des zips et des fichiers xml de description des dépôts SVP il est nécessaire de faire encore évoluer smart-paquets pour :

• autoriser les dépôts multiples - consiste à rajouter des arguments au script
• ajouter la date du dernier commit
• que devient smart-paquets pour un dépôt non SVN ?

L’interface privée des plugins

La proposition d’amélioration de cette interface est détaillée dans l’article Évolutions de l’administration des plugins. En substance :

• les onglets Plugins actifs et Liste des plugins sont fusionnés
• les extensions ne sont plus présentées dans un bloc séparé mais peuvent être filtrées de la liste des plugins actifs
• l’onglet Ajouter des plugins est motorisé par le formulaire de recherche de SVP
• l’onglet Gérer les dépôts est rajouté par SVP
• STEP permet de gérer les mises à jour possibles et les dépendances entre plugins

En outre, ne faudrait-il pas revoir les metas utilisées par l’interface des plugins ?

La DTD des fichiers de description des plugins

Une nouvelle DTD pour les fichiers plugin.xml est décrite dans l’article Des DTD pour décrire et archiver les plugins. Cette DTD permet de valider le contenu des fichiers xml de chaque plugin. Pour implémenter cette nouvelle DTD il faut :

• adopter la DTD proposée ou l’amender
• générer des nouveaux fichiers xml - paquet.xml - pour chaque plugin afin de faciliter la transition. Avec un script, en utilisant smart-paquets ou à partir de la base SVP ?
• migrer le nouveau fichiers core.xml dans cette nouvelle syntaxe et en profiter pour intégrer la modification correspondante déjà disponible dans la branche dev (cf http://core.spip.org/trac/spip/changeset/4aae616, http://core.spip.org/trac/spip/changeset/155b2dd6)
• générer les items de langue des slogans et descriptions à partir des informations contenus dans les plugin.xml ou la base SVP si la solution de traduction proposée par la DTD est adoptée.
• modifier l’interface d’admin des plugins pour qu’elle prenne en compte le fichier paquet.xml en priorité sur plugin.xml. Ne faudrait-il pas utiliser aussi la base SVP ?
• prendre en compte les impacts liés à la disparition des balises <fonction> et <install>
• faire sauter la limitation sur le préfixe des thèmes et adopter des préfixes du type theme_xxxx. L’activation d’un seul thème à la fois peut être conservée en utilisant la catégorie
• développer smart-paquets pour qu’il génère un fichier archives.xml conforme à la DTD et contenant, en particulier, les slogans et descriptions des plugins calculés à partir des items de langue.

Le site plugins.spip.net

Le plan de rénovation du site est décrit dans l’article Rénovation du site Plugins SPIP. En substance, le design est conservé - en particulier la coloration des pages en fonction de la catégorie de plugin - et le site est intégralement géré par SVP sous Zcore. Il reste cependant beaucoup de travail :

• revoir chaque page du site comme le précise la todo
• finaliser le formulaire de recherche de SVP pour l’espace public
• transférer les articles de certains plugins dans un autre site (Contrib, par exemple) afin de ne pas avoir à ouvrir le site aux contributions ou au forums.

En outre, il faut aussi mener une réflexion sur l’utilisation des dépôts SVP afin de mieux segmenter la zone actuelle ou intégrer de nouvelles zones.