Réflexions sur l’installation de plugins

Des notes, pour pas oublier pendant les vacances !!!

Gérer des dépots de plugins

L’idée générale est que chaque site spip puisse, gràce à un plugin, proposer de télécharger les plugins qu’il a développé.

En trois mouvements :

Un : J’imaginais un squelette zone-depots.html renvoyant un xml (certains préfèrent atom - moi je ne trouve pas cela lisible), le xml contenant grosso modo : <zone><depot+><paquet*>

Sur un spip « client », sur la page d’installation de plugins, proposer d’ajouter une nouvelle zone, soit en entrant l’adresse du site spip serveur (récupérera alors spip.php ?page=zone-depots, soit en rentrant l’adresse du xml (si généré par un autre moyen)

Deux : Un site pourrait accueillir plusieurs dépots, par exemple, la zone pourrait recevoir les depots ’officiels’ et ’communaute’. Je voyais cela par la présence dans un répertoire, disons /depots de fichiers de type archivelist, et nommes archivelist.depot.txt, soit pour l’exemple archivelist.officiels.txt et archivelist.communaute.txt.

Trois : Sur appel du squelette zone-depots.html, generation du xml en fonction des archivelist, si nécessaire (date des zips), avec au préalable creation des zips dont la version d’un plugin a change (comment savoir ? si svn installé (et plugin issu d’un checkout), facile, sinon, version dans plugin.xml ? et si le paquet est pas un plugin mais un squelette (a envisager ?))

structure xml

<zone>
  <id /> // identifiant du serveur, un nom tout simplement ?
  <depot+>
    <nom />
    <description? />
    <paquet*>
      <type /> //(plugin|squelette|je sais pas quoi)
      <zip>
        <url />
        <date_creation />
        <arborescence /> //spip/plugins/mon_plugin /!\ cf note a)
        <revision /> // utile ? si zips generes suite a svn:revision (on doit pouvoir utiliser la chose sans svn surtout)
      </zip>
      <cmd?>
         <svn? /> //adresse svn
         <cvs? /> //adresse cvs
      <cmd>
      <plugin?>
        <nom />
        <version />
        <version_base? />
        &lt;prefix  /> 
        &lt; description &lt;description ? />
        <necessite* />
        <tag* /> // marquer des mots cles ?
      </plugin>
    </paquet>
  </depot>
</zone>

-  Note a) :
Je suis partisan de ne pas mettre les dossiers depuis le repertoire plugins/nom_plugin, mais depuis nom_plugin/ directement, de sorte que même en mutualise, ça puisse être installé dans _DIR_PLUGINS si permis.
Par ailleurs, il faudrait permettre de cumuler les dossiers de plugins pour la mutualisation afin d’avoir des plugins fournis par /plugins, et installer des nouveaux dans /sites/lesite/plugins ... surtout valable pour des hébergeurs voulant proposer spip facilement installable.

Remarque : on sait faire et lire des flux RSS, on sait encloser des documents, notament des zip. Donc la structure et l’api pour l’explloiter existe déjà.

Coté client, gérer les l’installation et la mise à jour des plugins

Sur un onglet de la configuration des plugins, proposer « installation de plugins » et « gerer les serveurs » (un nom plus clair...).

Gerer les serveurs :

Proposer l’ajout, suppression de serveurs (adresse site ou adresse xml).

Installation de plugins : en 3 temps...

Un : lire les xml des serveurs, remplir un/des tableaux de paquets, comparer avec les paquets présents sur le site. Sur quels critères baser la comparaison ? date de création du zip, version du plugin ?, revision svn (si possibilité) ?

Deux : afficher la liste des plugins, comme sur exec=admin_plugins (un gadget possible, le tri : par serveur/depot, par tag, par ordre alphabetique, par mises à jour... ? ), marquer les plugins nouveaux, presents à jour, présents à mettre à jour... Cocher ceux que l’on veux installer et valider

Trois : Télécharger les paquets zip et dézipper (en utilisant spip_loader) OU si svn/cvs et infos svn/cvs dans le paquet, le récupérer comme cela.

James a dit que spip_loader pouvait loader plusieurs zips d’un coup, je n’ai pas regardé. Mais, si on enlève /spip/plugins/ de l’arborescence des zip, il faut indiquer à spip_loader dans quel répertoire décompresser le zip, selon le champ type dans paquets ?

— James dit : Oui, et il sait le faire, il y a une constante de prévu pour ça, que le plugin maj exploite déjà

Stockage des infos :

Là, il peut y avoir un grand débat : est-ce que l’on stocke des infos sur les paquets telecharges ou pas, et où... Ou simplement, la liste des plugins presents sur le site en plus de ceux activés. Dans le plugin maj, James stocke des infos dans une table sql, ça peut être une bonne idée, sauf que comment fait-t-on une réinstallation ? est-ce que l’on transmet au dump la liste des serveurs de plugins installes ?

Si on connait dans une base la liste de tous les plugins présents sur le site, il est certainement plus facile de faire des requetes lors de l’activation d’un plugin pour activer les dépendances (ou proposer de le faire en jQuery ?)

Multilinguisme de tout ça

Deux choix non ? mette toutes les infos de langues dans le xml, ou envoyer un xml dans la bonne langue si présente (?page=zone-depots&lang=xx) ...

Personnellement, je préfère mettre tout dans le xml et que ce soit le client qui s’occupe de traiter les champs multi... Sauf que...
Si un jour on arrive à utiliser les codes langues pour plugin.xml (<:langue :> ou [:langue :] pour pas casser la validité du xml), ces informations ne seront connues que par le serveur qui a les plugins dans sa poche (lui seul peut donc récupérer les codes de langue)...