Évolutions de l'administration des plugins - commentaires

Evolutions de l'administration des plugins

Les fonctions « _install » ne sont en fait que 116 actuellement, et même 99 car les autres ignorent leur argument, ce qui révèle un code obsolète car celui doit être impérativement testé pour savoir s'il s'agit d'installer, de dé-sinstaller ou de tester la présence. Sur les 99 on observe que

– le cas « test » est 58 fois l'application de « isset » sur une meta ;
– le cas « uninstall » est 49 fois l'appel de la fonction « _vider_tables » du plugin qui serait de toutes façons appelée ;
– le cas « install » est 25 fois l'appel de la fonction « _upgrade » du plugin qui serait de toutes façons appelée, et 23 fois une fonction « verifier_base » qui réalise le même travail (tout cela montre bien qu'une mise à jour des tables ne peut se faire que par l'enchaînement « désintaller-réinstaller »).

Chaque plugin gagnerait donc en taille et en clarté si on convenait que :

– la présence de la meta « base_version » du plugin suffit à assurer que le plugin est installé (pour un plugin ne gérant pas la base de données, le code standard d'administration pourrait forcer une valeur arbitraire) ;
– le code de la désintallatiin est assuré par « _vide_tables » et non par cette fonction « _install » (on se croirait chez M*cr*$*oft) ;

La fonction d'installation se réduirait donc bien à un code s'occupant de l'installation, et symétriquement à la dé-sinstallation, la déclaration des tables et l'initialisation de la meta « version_base » pourrait se faire dans le code standard d'administration des plugins.

Reste alors à trouver la bonne interface pour la fonction « _upgrade » : bien conçue, elle devrait se ramener à appeler la fonction standard « maj_while », mais reste à savoir quand provoquer cet appel.

Evolutions de l'administration des plugins

Dans Des DTD pour décrire et archiver les plugins j'avais incidemment parlé d'un problème qui a plus sa place ici et que je reformule avec plus de précisions. Il s'agit de l'installation et de la désinstallation d'un plugin. L'interface actuelle teste l'existence de 4 fonctions dont le nom commence par le préfixe du plugin et se poursuit par « _install », « _uninstall », « _upgrade » et « _vider_tablees ». En voici les statistiques :

– 178 fonctions « _vider_tables »
– 164 fonctions « _upgrade »
– 163 fonctions « _install »
– 17 fonctions « _uninstall »

Ce dernier chiffre se ramène même à 7, car 10 de ces 17 fonctions sont déclarées mais ne font rien (les 7 restantes sont les diffiérentes versions de Agenda, PIMAgenda, publiHAL, seo, spiplistecleaner). Côté « _vider_table », pratiquement toutes les fonctions appliquent « effacer_meta » sur la meta contenant leur numéro de version, et beaucoup appellent sql_drop_table sur des tables SQL spécifiques au plugin, certaines ayant été rajoutées à la liste des « tables principales » de SPIP, d'autres à ses « tables auxiliaires ».
On allègerait donc les spécifications et augmenterait les services rendus en introduisant une ncompatibilité que pour les 7 plugins mentionnés en considérant que :

– l'appel de la fonction de suffixe « _uninstall » n'est plus assuré ;
– l'appel de la fonction de suffixe « _vider_table » est suivi, dans le code standard d'administration des plugins, de l'appel à effacer_meta ci-dessus mentionné, et de l'application de « sql_drop_table » sur 2 listes de tables indiquées par deux globales dont les noms commencent par le préfixe du plugin et se terminent par « tables_principales » et « tables_auxiliaires » respectivement.

Il y a certainement une meilleure interface à trouver pour « install » et « upgrade », mais l'examen de ce que font les quelques centaines de fonctions actuelles est laborieux.

Evolutions de l'administration des plugins

Il y a un aspect de la mise à jour dont on n'a pas parlé, c'est le cas où les fichiers du plugin induisent de faire une mise à jour des tables SQL du plugin. Cette mise à jour n'est faite que si on désactive le Plugin et qu'on le réinstalle aussitôt, et aucun message nulle part prévient de la chose. C'est un gros manque de l'interface actuelle.

Réflexions sur l'interface d'administration des plugins

Concernant le terme extension ou distribution je n'ai pas de préférence. Par contre, il me semble important d'avoir une cohérence entre le nom du répertoire où elles sont stockées, le nom évoqué dans la doc et l'interface utilisateur. On doit toujours utiliser le même nom pour parler de la même chose. Sinon, c'est très perturbant pour un nouvel utilisateur.

Réflexions sur l'interface d'administration des plugins

Yep Joseph,

Tu es allé plus loin que je ne suis allé dans ma proposition mais je vais essayer de te répondre :

Il faut pouvoir mettre à jour les plugins en un minimum de clics

Oui, je retiens donc l'idée d'un bouton pour sélectionner toutes les mises à jour.

C'est quoi les filtres distribution / hors distribution ? Tu veux dire extensions ? Inutile de rajouter un nouveau terme qui va différer de celui de la doc. Ca perturbe l'utilisateur.

Alors là, moi ce qui me perturbe c'est plutôt le terme extensions ! c'est incompréhensible quand on pense que tous les plugins (terme anglais) sont des... extensions ou greffons en français. Donc je crois plutôt qu'il faille renommer ce terme.

Prévoir les icones visuelles de STEP pour l'état des plugins (dev, test, stable...).

Ben concernant les icônes il y a les pour et les contre. Moi je suis ni pour ni contre, bien au contraire ;-).

Par sécurité, le bouton ....
...Quand on déplie un plugin pour voir sa description, est-ce que le chemin physique est affiché ?

Pour l'instant je n'avais pas l'ambition de modifier la présentation actuelle de chaque plugin, sauf à remplacer le bout de description sous le nom par le slogan (nouvelle balise).

Si on veut supprimer un plugin, sera-t-il possible de l'effacer du serveur via un bouton ou doit-on toujours le supprimer physiquement par FTP ?

Bonne question, ça serait donc le bouton Désinstaller. Là dessus je ne saurais me prononcer si c'est faisable ou souhaitable mais si on peut faire des vraies mises à jour... ça doit être possible.

Pourrait-on ajouter un filtre rapide par catégories ? Quand on a beaucoup de plugins installés, ca facilite la recherche.

J'ai hésité à le rajouter mais ok.

Pourquoi relister tous les plugins sous l'onglet ajouter un plugin ? Les plugins déjà actifs ne devraient pas y être listés.

C'est de la fainéantise de ma part. J'ai repris les mêmes plugins par commodité mais tu as raison c'est très trompeur. Je corrige l'image ce soir.

On perd la possibilité d'ajouter un plugin en donnant le lien de son Zip. Cette option doit rester possible, notamment pour les plugins n'ayant pas de dépôt.

Ah ? Il faudrait donc le conserver bien que je ne vois pas avec le fonctionnement de SVP ce qui empêcherait de créer un dépôt.

Réflexions sur l'interface d'administration des plugins

Il manque un bouton actualiser les dépôts dès l'onglet Plugins installés ainsi qu'un bouton sélectionner les mises à jour qui sélectionne toutes les mises à jour.

Il faut pouvoir mettre à jour les plugins en un minimum de clics.

C'est quoi les filtres distribution / hors distribution ? Tu veux dire extensions ? Inutile de rajouter un nouveau terme qui va différer de celui de la doc. Ca perturbe l'utilisateur.

Prévoir les icones visuelles de STEP pour l'état des plugins (dev, test, stable...).

Par sécurité, le bouton Désactiver et vider les tables ne devrait pas être accessible directement mais seulement une fois qu'on a cliqué sur le nom du plugin pour voir son descriptif. Enfin, prévoir un message d'avertissement (Vous êtes surs ? Cette action est irréversible.) Il faudrait ajouter une icône triangle à coté du nom du plugin pour comprendre qu'on peut déplier.

Il faut préciser dans la colonne de gauche que l'ajout automatique d'un plugin nécessite un répertoire plugins/auto.

Quand on déplie un plugin pour voir sa description, est-ce que le chemin physique est affiché ?

Si on veut supprimer un plugin, sera-t-il possible de l'effacer du serveur via un bouton ou doit-on toujours le supprimer physiquement par FTP ?

Pourrait-on ajouter un filtre rapide par catégories ? Quand on a beaucoup de plugins installés, ca facilite la recherche.

Pourquoi relister tous les plugins sous l'onglet ajouter un plugin ? Les plugins déjà actifs ne devraient pas y être listés.

On perd la possibilité d'ajouter un plugin en donnant le lien de son Zip. Cette option doit rester possible, notamment pour les plugins n'ayant pas de dépôt.

Voici mes quelques remarques.

Vivement cette gestion des mises à jours en standard dans SPIP !!!

Réflexions sur l'interface d'administration des plugins

Salut Emmanuel, en quelques mots, STEP a pour but :

– de gerer des dépôts multiples de paquets afin de les proposer au téléchargement (mode auto de SPIP)
– d'identifier et d'autoriser les mises à jour des plugins déjà installés
– et à l'instar de Synaptics de Linux, de gérer les dépendances entre plugins pour l'installation et les mises à jour.
C'est donc une évolution du chargeur de plugins de SPIP, évolution essentielle à mon avis compte tenu des limitations actuelles de celui de SPIP.

Pour ce faire STEP crée des tables plugins et zones dans la base afin de conserver les infos de tous les plugins disponibles à tout moment. Il tient aussi à jour dans ces tables les infos sur les plugins installés sur le serveur. STEP utilise aussi les notions de catégories et tags pour chercher des plugins.

A cet égard, SVP implémente la partie « statique » de STEP cad celle concernant les informations sur les dépôts et les plugins ainsi que la recherche de plugins. Mon idée présentée dans le proto ici http://www.circaete.net/eric/step/#principes_2_page en décembre passé était de découper STEP en deux modules principaux : la gestion des plugins disponibles dans la galaxie, SVP, et la gestion des plugins installés, STEP. Mais ce n'est pas le cas actuellement.

Donc maintenant que SVP et STEP tournent de façon satisfaisante mais indépendante, il faudrait reprendre STEP pour l'adapter à SVP. La proposition sur l'administration des plugins s'appuie sur cette idée d'un STEP « refondu ».

Réflexions sur l'interface d'administration des plugins

Y a-t-il quelque part une description un peu précise de STEP ? Je ne trouve pas sur le Web une description précise de ses fonctionnalités.

Réflexions sur l'interface d'administration des plugins

Il faudra voir à l'usage, mais au vu de ton article et des captures d'écran, cette proposition d'organisation semble chouette.