SVP, objectifs et mise en oeuvre

, par _Eric_

Préambule

L’idée de SVP est née de la conjonction de deux projets :

  • STEP, le plugin de gestion des plugins installés sur un site SPIP, développé par Marcimat,
  • et du prototype de recherche/présentation des plugins destiné à SPIP-Contrib et dont une maquette est toujours disponible sur le serveur de Denisb à l’adresse http://www.circaete.net/eric/step/.

Objectifs

SVP a donc pour but de :

  1. Tenir à jour une base de plugins/paquets utilisables dans les sites SPIP, en consolidant les contributions de divers dépôts comme SPIP-Zone.
  2. Offrir une interface de recherche et d’information sur les plugins, et de téléchargements de leurs paquets (pas d’installation !)
  3. Servir de base à la construction d’un site unique de consultation des plugins, l’idée originelle étant d’héberger ce site sur SPIP-Contrib mais...

A cet égard, dans sa version actuelle, SVP implémente les plugins nommés STEP BASE et STEP API (sauf l’interface distante) du prototype comme le montre la figure http://www.circaete.net/eric/step/#principes_2_page.

Remarque sur STEP vs SVP : il n’y a aucun recouvrement, à terme, entre ces deux plugins, SVP construisant et tenant à jour la base de données que STEP utilise pour définir les mises à jour à effectuer sur les plugins installés localement.

Modèle de données

Le cœur de SVP réside dans son modèle de données dont le point notable est la distinction entre le plugin et ses paquets. Les éléments manipulés par SVP sont donc :

Plugin
C’est une fonctionnalité additionnelle à SPIP, distribuée sous forme de paquets. Le plugin est déterminé par son préfixe, unique. Il possède et est aussi (re)connu par son nom, son logo et sa catégorie (et des tags dans le futur) qui doivent rester uniques et constants tout au long de la vie du plugin... Afin que le nom du plugin ne devienne pas une description, on adjoint au plugin un slogan (ce que Marcimat a désigné par « shortdesc » dans STEP). Exemple pour « Accès restreint » :

  • Préfixe : accesrestreint
  • Nom : Accès restreint
  • Catégorie : auteur (c’est l’alias, voir plus loin)
  • Slogan : Gestion de zones d’accès restreint (en français)
  • Logo (je n’ai pas trouvé le moyen simple de l’afficher dans SVP, une idée ?)
  • Tags : liste d’étiquettes pour préciser la catégorie (pour le futur)

Catégorie
Permet de classifier les plugins pour effectuer des recherches rapides. La catégorie doit devenir une information obligatoire pour le plugin. Il existe 13 catégories qui sont :

AliasLibellé en français
auteur Authentification, auteur, autorisation
communication Communication, interactivité, messagerie
date Agendas, calendrier, date
divers Objets nouveaux, services externes
edition Edition, impression, rédaction
maintenance Configuration, maintenance
multimedia Images, galerie, multimédia
navigation Navigation, organisation, recherche
outil Outil de développement
performance Optimisation, performance, sécurité
squelette Squelette
statistique Référencement, statistique
theme Thème

Paquet
C’est une instance d’un plugin, donc il possède toutes les caractéristiques du plugin comme son prefixe, son nom, sa catégorie... Il est identifié par ses autres caractéristiques comme sa branche (nouvelle notion pour distinguer Acces restreint et Acces restreint 3, par exemple), sa version, sa compatibilité SPIP, son auteur, sa description détaillée et toutes les autres informations incluses dans le plugin.xml. Il est matérialisé par une archive zip.

Par exemple, Accès restreint possèdent sur SPIP-Zone deux paquets correspondant à deux branches du même plugin :

  • acces_restreint_1_9, correspondant à la branche 1
  • acces_restreint_3_0, correspondant à la branche 2 qui d’ailleurs a un article de documentation sur SPIP-Contrib titré « Accès restreint 3.0 »

Par extension, les contributions qui ne sont pas des plugins seront aussi assimilées à des paquets matérialisées par une archive mais leurs données se limiteront aux informations de l’archive elle-même. Ces contributions sont les squelettes non distribués en plugin, les jeux d’icônes, certains outils, les librairies...

Deux paquets issus de plugin sont désignés identiques si et seulement si leur préfixe, version, version de base et état sont identiques. Par extension, les autres informations devraient être identiques mais elles ne sont pas vérifiées. Une différence serait a priori révélatrice d’une erreur.
Pour les autres contributions le nom de l’archive et le dépôt doivent être discriminants.

Dépôt
C’est un lieu d’hébergement d’un ensemble de paquets. Il est défini par une adresse et un fichier XML contenant la description de tous les paquets hébergés.

Par exemple, le dépôt SPIP-Zone est localisé à l’adresse http://files.spip.org/spip-zone/ et est décrit par le fichier archives.xml (http://files.spip.org/spip-zone/archives.xml).

Les archives sont stockées à partir de l’adresse de dépôt et de préférence dans le répertoire racine. Un paquet est distribué par un seul dépôt.

Collection (pour un usage futur)
C’est un ensemble de paquets hébergés par des dépôts différents ou pas et distribué sous la forme d’une archive unique. Elle contient des plugins compatibles, entre eux et avec une version de SPIP donnée.

Implémentation

La Base

Le pipeline de création installe :

  • les 4 tables spip_depots, spip_depots_plugins, spip_plugins et spip_paquets
  • une meta nommée “svp_categories” qui contient le tableau sérialisé des alias de catégories

La table spip_depots_plugins permet de créer la liste des plugins hébergés par un dépôt sans passer par la table spip_paquets.
Les champs des tables sont présentés ci-après :
Modèle de données de SVP
Remarque : contrairement à ce qui est fait aujourd’hui, STEP aurait peut-être intérêt à ne rien modifier dans ces tables mais à créer une table spip_paquets_installés pour gérer les mises à jour et autres actions d’installation.

L’interface privée

Elle propose (via le menu Configuration) :

  1. Une interface principale réservée au webmestre et composée de :
    • Un onglet « gérer les dépôts » pour ajouter, supprimer ou actualiser manuellement un dépôt
    • Une page d’édition d’un dépôt (comme tout objet SPIP) qui permet d’ajuster les informations non disponibles dans le fichier XML comme le logo par exemple.
  2. Un formulaire de recherche de plugins qui reproduit en privé ce qui sera accessible en public (non encore développé, mais je pense que l’accès privé est plus un besoin STEP pour l’installation de nouveaux plugins).

Il est aussi possible de déclencher un CRON pour actualiser les dépôts suivant une période à fixer entre 1h et 24h (tache CRON déclenchée par défaut toutes les 6h).

Concernant les informations du dépôt, il est possible de rajouter dans le fichier XML de description des paquets un bloc pour définir lors de l’ajout du dépôt son titre et son type (svn, git, manuel - usage futur). Ensuite, le formulaire d’édition du dépôt permet de presque tout modifier (sauf l’adresse) en gardant la priorité sur le fichier XML : en effet, les actualisations ne remettent jamais à jour les informations du dépôt mais seulement les paquets.

Interface publique

SVP offre des pages Z qui permettent de valider le principe du plugin plus que de proposer une interface léchée comme celle du prototype de SPIP-Contrib. Les pages concernées sont :

  • Page des Téléchargements (telechargements), qui propose, par dépot, la liste des paquets à télécharger en distinguant les plugins et les autres contributions. La colonne navigation propose de filtrer cette page par catégorie, dépôt et dans le futur par version SPIP (mais je pense qu’il me faut créer un critère pour cela)
  • Page des dépôts (depots et depot), qui propose soit la liste des dépôts disponibles, soit le détail sur un dépôt donné et en particulier la liste des plugins regroupés par catégorie et celle des autres contributions. La colonne navigation permet cette fois de naviguer entre dépôts.
  • Page des plugins (plugins et plugin), qui propose, le fameux formulaire de recherche avancée multi-critères et en regard :
    • soit la liste de tous les plugins avec les informations de base et la liste des paquets disponibles
    • soit la liste des plugins d’une catégorie donnée
    • soit la liste des plugins résultant d’une recherche

L’état d’avancement du développement de SVP est consultable sur ce site.