Vérifier la dernière version des plugins utilisés.

niqnutn · octobre 2015

Bonjour,

En regardant le plugin spxplugindownloader de Je-evrard, je me demande s'il n'est pas possible d'ajouter une fonction dans PluXml pour vérifier qu'on utilise bien la dernière version disponible.

Je pense à quelque chose de simple, dans la Gestion des plugins on pourrait simplement afficher si un plugin utilisé dispose d'une version plus récente.
Dans la page "Informations relatives à PluXml" il y a une fonction pour vérifier si on utilise la dernière version de PluXml. Est ce qu'on ne peut pas généraliser ça avec les plugins ?

Je pense que ça peut être utile à tous mais sans vouloir remplacer les fonctions de spxplugindownloader.

Draky · octobre 2015

Faudrait que les sites des auteurs mettent ça en place genre un fichier texte avec le numéro de la dernière version ET que chaque plugin puisse être interrogé (genre le plugin a aussi un fichier texte de version).

niqnutn · octobre 2015

j'ai vu qu'avec le plugin de Je-evrard, on a des fichiers sur un serveur pour vérifier la dernière version mais j'ai pas regardé comment on regarde la version du plugin utilisée.

je-evrard · octobre 2015

Bonjour,

La version du plugin est lue via le fichier infos.xml et est comparée a la version existante du plugin dans le dépot x ou y.

[== Indéfini ==]
$update=false;
if(isset($aPlugins[$plugName]))
   $update = version_compare($aPlugins[$plugName]->getInfo('version'), $plug['version'], "<");

Ce qui permet de savoir si le plugin est a jour ou pas.

a+

jéjé

bazooka07 · octobre 2015

Je suggère dans la prochaine version de Pluxml de rajouter des champs dans le fichier infos.xml :

lastVersion : (dernière version) contiendrait une url permettant de télécharger un fichier texte d'une ligne avec le numéro de la dernière version
repository: (dépôt) contiendrait une url pour télécharger le fichier zip de l'archive
frequency: frequence en jours pour vérifier s'il y a une nouvelle version

Il faudrait également créer une fonction suopplémentaire dans la classe PlxPlugin, nommée par exemple newVersion() qui renverrait False ou l'adresse pour télécharger le nouveau paquet zip du plugin. Cette fonction comparerait la version contenue dans infos.xml avec celle téléchargée avec le lien lastVersion.

Il suffirait ensuite d'appeler cette fonction avec le hook AdminFootEndBody quand l'administrateur du site est connecté pour lui afficher un message.

En attendant la prochaine version de Pluxml, il suffirait de convenir des champs supplémentaires pour infos.xml et éventuellement d'une fonction à rajouter à chaque plugin.

Je rajoute une autre idée. Cela serait bien s'il y avait sur pluxml.org un tableau ou une base de données contenant pour chaque plugin :
une date, un nom, une catégorie, un auteur, le numéro de la dernière version, un descriptif court, une url pour télécharger l'archive zip.

A++

niqnutn · octobre 2015

du coup, il faudrait ajouter dans le fichier info.xml, l'URL du dépôt dans lequel on peut vérifier si une version plus récente est disponible.

il me semble que spxplugindownloader centralise les URL des dépôts (puisque l'information n'est pas dispo ailleurs), mais le fonctionnement pourrait être similaire.
Il n'y a pas besoin de tout réinventer pour vérifier la version du plugin.

cfdev · octobre 2015

bazooka07 a écrit:

Je suggère dans la prochaine version de Pluxml de rajouter des champs dans le fichier infos.xml :

lastVersion : (dernière version) contiendrait une url permettant de télécharger un fichier texte d'une ligne avec le numéro de la dernière version
repository: (dépôt) contiendrait une url pour télécharger le fichier zip de l'archive
frequency: frequence en jours pour vérifier s'il y a une nouvelle version

Il faudrait également créer une fonction suopplémentaire dans la classe PlxPlugin, nommée par exemple newVersion() qui renverrait False ou l'adresse pour télécharger le nouveau paquet zip du plugin. Cette fonction comparerait la version contenue dans infos.xml avec celle téléchargée avec le lien lastVersion.

Il suffirait ensuite d'appeler cette fonction avec le hook AdminFootEndBody quand l'administrateur du site est connecté pour lui afficher un message.

En attendant la prochaine version de Pluxml, il suffirait de convenir des champs supplémentaires pour infos.xml et éventuellement d'une fonction à rajouter à chaque plugin.

Je rajoute une autre idée. Cela serait bien s'il y avait sur pluxml.org un tableau ou une base de données contenant pour chaque plugin :
une date, un nom, une catégorie, un auteur, le numéro de la dernière version, un descriptif court, une url pour télécharger l'archive zip.

A++

SPXPLUGINDOWNLOADER fait déja tout ça, centralisation de plugin, téléchargement et installation automatique, vérification de la dernière version des plugins...

niqnutn · octobre 2015

@cfdev: sauf que tout est centralisé dans le plugin alors qu'on propose quelque chose de générique et décentralisé.
personnellement, je n'ai pas besoin des fonctionnalités de SPXPLUGINDOWNLOADER mais simplement de savoir si je suis à jour.

En plus, le fait d'ajouter des infos sur le dépôt pourrait être utilisé par le plugin de Je-evrard et n'a pour objectif de le remplacer.

@bazooka07: il y a déjà une page http://wiki.pluxml.org/index.php?page=Plugins+non+officiels même si on pourrait mieux structurer l'information sous forme de tableau.
sur la date et numéro de version, c'est trop volatile et ça sera difficilement à jour. pour le reste c'est une bonne idée et j'ajouterai la version de PluXml concernée.

Draky · octobre 2015

En effet, ça fait penser à spxdownloader mais faudrait p'tête plutôt, juste pour le numéro de version, rajouter l'URL du fichier à interroger, avec un fallback en cas d'absence si le créateur n'a pas de site pour son plugin.
Et un lien vers ledit site juste pour ne pas chercher sur le Net où se trouve la mise à jour.

niqnutn · octobre 2015

c'est ça, il faut pouvoir interroger un fichier en ligne pour vérifier la présence d'une nouvelle version.
si tu n'as pas de site, je ne vois pas comment on peut gérer ça. de toute façon, je vois ça comme une option du plugin.

il faudrait effectivement avoir le lien vers la version la plus récente du plugin.

ça ressemble à spxdownloader mais en gardant une fonction très basique. si quelqu'un a une bonne idée, pourquoi ne pas s'en inspirer mais surtout qu'on définisse comment gérer les versions pour tous les plugins.

bazooka07 · octobre 2015

Supposons que les archives Zip des plugins soient stockées dans le dossier /plugins du site http://www.monsite.com, il suffit de déposer le script php suivant dans ce dossier :

[== PHP ==]
if (isset($_GET)) {
	$result = 'false';
	if (isset($_GET['plugin'])) {
        $plugin = $_GET['plugin'];
        $filename = dirname(__FILE__).'/'.$plugin.'.zip';
        if (is_file($filename)) {
			$zip = new ZipArchive();
			if ($res = $zip->open($filename)) {
				$infos = $zip->getFromName($plugin.'/infos.xml');
				if (isset($_GET['infos'])) {
					// send content of infos.xml
				    header('Content-Type: text/xml');
					echo $infos;
					exit;
				} else {
					// send version of plugin
		            $doc = new SimpleXMLElement($infos);
	                $result = $doc->version;
				}
			} else
				$result = $res;
        } else
            $result = 'unknown';
    }
    header('Content-Type: text/plain');
	echo $result;
} else {
	header('Content-Type: text/plain');
	echo 'Bad boy !';
}

Ensuite pour obtenir le numéro de version du plugin XXXXXX en ligne, il suffit de consulter l'adresse:
http://www.monsite.com/plugins/version?plugin=xxxxxx

De la même façon, pour obtenir le fichier complet aux format xml du fichier infos.xml, il suffiit de faire:
http://www.monsite.com/plugins/version?plugin=xxxxxx&infos

Je vous ai mis une démo en ligne chez http://www.kazimentou.fr/pluxml-plugins/ si vous voulez tester.
Sur le site j'ai rajouté un autre script php qui génére un tableau des plugins dans ce dossier plugins.
Les scripts sont en ligne si vous voulez les employer.

Reste plus qu'à créer la fonction magique à insérer dans la classe de votre plugin ou dans plxPlugin

Des suggestions ?

niqnutn · octobre 2015

je pense que c'est mieux de tout gérer coté site et n'avoir que des fichiers texte à consulter sur le dépôt du plugin.
en utilisant github tu peux consulter un fichier type texte mais pas sûr que tu puisse avoir un script PHP. en plus si ton script doit être modifié, c'est plus contraignant que de modifié les données de ton plugin.

@bazooka07: ton site n'est pas accessible

kowalsky · octobre 2015

Juste un aparté : j'suis parti de WordPress parce que cela devenait une usine à gaz en "core", je préfère donc que la fonctionnalité que vous évoquez reste de l'ordre du plugin et ne passe pas en "core" dans PluXml car j'y vois (au moins) deux inconvénients :

Chaque auteur de plugin pourra ainsi savoir qui l'utilise en examinant ses requêtes de connexions -> problème de vie privée.
Cela va générer des requêtes externes depuis le site, donc induire du délai dans les temps de réponses de la partie admin -> sur une installation locale sans accès au net, faudra attendre la fin des timeout vers chaque dépôt pour accéder à la page des plugins.

A titre de comparaison, quand je change d'onglet dans SPXPLUGINDOWNLOADER ça me prends facilement entre 5 et 7 secondes car il y a 7 dépôts à contacter et consulter. Quand l'un d'eux a un soucis, cela prends encore plus de temps. Je l'accepte car j'ai installé ce plugin (pour profiter de la fonctionnalité évoquée).
En "core", il est hors de question d'attendre aussi longtemps pour afficher la page des plugins. ]:D

niqnutn · octobre 2015

pour le pb de "vie privée" j'ai un doute mais il faut voir ce qu'on peut faire. de toute façon tu pourrais très bien enlever l'URL du dépot à contacter si c'est stocker dans le fichier infos.xml . ça pourrait ếtre désactivé par défaut.

après si ton serveur n'est pas capable de récupérer quelques fichiers, il doit y avoir un pb. au pire tu n'as pas de résultat.
pluxml va vérifier si tu utilises la dernière version donc c'est à peu près pareil.
cette fonctionnalité serait au mieux appeler quand on est sur /core/admin/parametres_plugins.php ou éventuellement sur /core/admin/parametres_infos.php donc pas de quoi fouetter un chat.

@kowalsky: c'est une discussion et je ne suis pas le responsable de projet. si effectivement cela ne peut pas être intégré au projet rien n’empêche de discuter de la meilleure solution pour gérer ça au sein d'un plugin.
actuellement SPXPLUGINDOWNLOADER ne gère pas tous les plugins et ça pourrait améliorer cette partie et éventuellement pas besoin de développer autre chose en parallèle.

bazooka07 · octobre 2015

Mon site chez OVH est long à répondre ce soir.

Vous pouvez consulter cette adresse chez LWS en remplacement:
http://echecs-annonay.fr/pluxml-plugins/

niqnutn · octobre 2015

si on l'url du dépôt dans infos.xml , il suffit d'utiliser ce qui a été fait par @bazooka07 coté PluXml. Du coup, il suffit simplement d'héberger l'archive du plugin.
par rapport à ce qui a été dit par @kowalsky, on pourrait faire la vérification uniquement sur un bouton "Rechercher une nouvelle version du plugin".

bazooka07 · octobre 2015

@kowalsky,

A) mon idée était qu'une fonction équivalente à version_compare() de je-evrard soit intégré à la classe plxPlugin pour éviter que chacun aille bidouiller un truc dans son coin. Mais pour une autre raison, je pense ne pas en avoir besoin

C'est sûr que ça doit frustant d'attendre la réponse du dépôt de plugins qui bloque Pluxml pendant la génération des pages Web. Par contre, si on consulte le dépôt pendant que tu lis la page HTML générée, l'éventuelle lenteur du dépôt peut te passer inarperçue. De plus, on peut se limiter à conserver un dépôt par page web
C) Conséquence il faut mixer plusieurs techniques : php pour controler l'administrateur et récupérer quelques infos sur les plugins installés sur le serveur, javascript, ajax et json pour consulter les dépôts depuis le navigateur et envoyer des messages d'alerte, la session pour mémoriser les dépôts à parcourir. C'est un peu plus complexe que les solutions déjà évoquées mais cela me semble jouable.

A++

je-evrard · octobre 2015

Bonjour,

Je voudrais éclaircir le fonctionnement de spxplugindownloader pour chasser toute ambiguité dans un premier temps.

Comment ça fonctionne ?

La première fois dans l'admin du plugin

[list=*]
[*]récupère le numéro de version des magasins[/*]
[*]récupère la liste de plugins des magasins[/*]
[/list]

Ayant récupéré la liste des magasins, il appel les différents magasins

[list=*]
[*]récupère le numéro de version du magasin[/*]
[*]récupère la liste des plugins du magasin[/*]
[/list]

Le plugin met tout en cache dans le dossier plugins/cache/

Que se passe t-il les fois suivantes ?

Le plugin ne fait des requetes que sur :

[list=*]
[*]numéro de version des magasins[/*]
[/list]

il le compare avec celui en cache, si c'est le meme, il ne fait rien, sinon il recharge la liste.

Il fait de meme avec les versions de magasins.

On a donc pour chaque magasin :

[list=*]
[*]récupère le numéro de version du magasin[/*]
[/list]

il le compare avec celui en cache, si c'est le meme, il ne fait rien, sinon il recharge la liste du magasin en question.

Ceci permet de gagner du temps dans les requêtes. Je pourrais meme mettre un système en place pour que les requetes de version se fasse une fois par heure en plaçant un flag date-H dans le répertoire temporaire. Il y aurait donc aucune requete pendant une heure et une fluidité parfaite, la mise à jour d'un auteur se fera dans l'heure maxi. on pourrait meme imaginer que ce paramètre d'une heure soit mis dans la config du plugin lui-meme mais c'est une autre histoire.

Ceci étant dit tout ceci reste temporaire. De mon coté, dans mes installations pour des clients je n'ai de base qu'un plugin a mettre à la main (devinez lequel), le reste est automatique et c'est bien pratique. Mais c'est parce qu'aujourd'ui nous n'avons pas de gestionnaire de ressource qu'il existe des solutions temporaires ou des futures solutions temporaires (le sujet de ce forum par exemple).

Le gestionnaire de ressources va arriver tot ou tard sur pluxml.org. Chaque auteur pourra avoir son compte en frontend, administrer ses plugins et ses thèmes en lui joignant des propriétés (catégories, mots clefs..) qui seront bien utiles par la suite. Tout le problème d'avoir plusieurs dépots aura disparu. Un seul dépot centralisé et un controle de la team en backend (catégories, auteurs, plugins, thèmes...).

Coté pluxml un plugin et un seul pourrait répondre à la problématique d'installation et de mise à jour des thèmes et des plugins via un moteur de recherche par tags, auteurs, catégories, par nom, par notoriété... mais ce ne sera pas spxplugindownloader (bien sur) mais un autre plugin. Petit a petit l'oiseau fait son nid et c'est déja pas si mal.

a+

jéjé

Draky · octobre 2015

Je trouve que le fait de mettre cette option en option est bien mais... tous les CMS/blogs/forums ont maintenant un fonction genre SPXplugindownloader intégrée.
Avec une vérif. de version.

Faudrait voir ce que Stéphane veut

sachant qu'il y a le risque d'alourdir... mais que ça peut aider les gens à installer des plugins facilement.

DjbWebmaster · octobre 2015

Bonjour à tous,

Je pense aussi que le fait de vérifier les versions des plugins ne peut qu'alourdir la backend du CMS.

Si cette fonction était installée, il faudrait avoir l'option pour l'activer ou pas.

je-evrard · octobre 2015

@Draky

Je vais rajouter l'option dans spxplugindownloader rapidement.

Pour le reste le plugin officiel orienté ressource peut-etre déja installé quand on télécharge pluxml et ça allourdie rien du tout.

Draky · octobre 2015

Le tien est plus complet, mais c'est aussi parce qu'il faudrait que celui de base inclue autant de choix via le site ressource.

kowalsky · octobre 2015

@niqnutn : concernant la potentielle intrusion dans la vie privée, il est fort probable que les auteurs de plugins ne fassent rien de tout cela avec les données de connexions, mais c'est à prendre en compte. C'est sur le même principe que l'avertissement sur l'usage des cookies traceurs externes évoqués dans une autre discussion. A titre personnel, et sans rapport avec le sujet en cours, ça ne me plait pas du tout de voir toute une flopée de requêtes externes partir de mon site quand je m'y connecte ou que ma télé connectée envoie des informations sur ce que je regarde à je ne sais qui ou encore que mon OS m'espionne et renvoie tout un tas d'informations vers la NSA. ]:D

niqnutn · octobre 2015

pour moi, l'idée de base est de savoir si mon plugin est à jour.
on pourrait lancer cette fonction manuellement, ce qui limiterai certains pb de vie privée et autres (éventuellement désactivable dans un paramètre).
on pourrait gérer ça sous la forme de plugin un certain temps et voir si l'intégrer au projet est intéressant.
le plugin de je-evrard est déjà dispo mais si on veut se baser sur son travail, il faudra savoir comment gérer TOUS les plugins (pour ceux qui veulent bien). pour ça, il faut définir clairement comment le gérer et que ça soit documenter.

j'entends bien l'argument que ça peut alourdir PluXml, bien qu'on peut faire ça proprement, mais en terme de sécurité et de simplicité d'utilisation c'est pas non plus un gadget et comme dit plus haut, ça peut être fait uniquement manuellement.

personnellement, si ça doit être un plugin plus ou moins officiel ça me va. Il faut qu'on puisse gérer ça pour tout le monde et pas dépendre de quelqu'un pour ajouter son dépot perso. si on arrive à faire évoluer spxplugindownloader ça me conviendrait aussi.
Il y a bien des manières de faire ça et faudrait trouver la plus intéressante. Il faut que les responsables de PluXml et les autres arrivent à définir les orientations.

Je pense que ça intéresse plus d'une personne et qu'il y a un véritable besoin derrière.

bazooka07 · octobre 2015

Bonjour,

Nouvelle version de mon gestionnaire pour le dépôt de plugins.
Il tient maintenant en un seul petit fichier PHP.

Dans le fichier infos.xml de mes plugins, je rajoute 2 champs optionnels :
repository
requirements

C'est par ici : http://www.kazimentou.fr/pluxml-plugins/

Enjoy it !

niqnutn · octobre 2015

c'est intéressant et surtout minimaliste.
après je sais pas si l'utilisation de ziparchive ne peut pas être source de pb.

reste à gérer ça du coté de PluXml pour lancer la vérification des versions.
après on pourra créer un plugin pour la gestion des dépôts (avec l'ajout des archives via backend)

edit: je viens d'avoir un pb avec un plugin qui fonctionne uniquement avec PuXml 5.4 et je me demandais comment faire pour garder les versions d'un plugin proprement.
ce que propose bazooka07, c'est d'avoir une entrée par plugin mais je ne vois pas comment on peut gérer les versions successives.
edit2: j'ai quelques pistes d'améliorations.

@bazooka07: je pense qu'il faudrait mieux récupérer la date présente dans infos.xml plutôt que prendre la date d'ajout du fichier dans le dépôt.
au moins, il faudrait libellé: ajouté au dépot le xx/xx/xxxx .
on pourrait également ajouté une colonne avec "plugin créé le xx/xx/xx" mais je suppose que c'est le format de date qui risque de posé un petit pb à un moment donné.

niqnutn · octobre 2015

Quelques idées pour alourdir la version proposée par @bazooka07:

Gérer les différentes versions d'un plugin
- parce que certains plugins marchent avec 5.3 et pas 5.4 et inversement (cf data/media)

Du coup, il faudrait obligatoirement que les différentes versions de plugin intègrent leur numéro dans le nom d'archive.
- autoriser uniquement les caractères [0-9][.] après le "-" ( et peut être master pour github)
- nom de fichier possible: pluginA.zip ou plugin-1.0.zip (on doit retrouver "1.0" dans infos.xml)

Contenu possible d'une archive:

pluginA.zip

|_ pluginA (dossier)
|_ infos.xml
|_ pluginA.php

ou

pluginA-1.0.zip

|_ pluginA (dossier)
|_ infos.xml
|_ pluginA.php

ou

pluginA-1.0.zip

|_ pluginA-1.0 (dossier)
|_ infos.xml
|_ pluginA.php

Dans le tableau, il ne faudrait afficher que la dernière version du plugin.
Fonction pour lister les versions disponibles d'un plugin donné:
http://www.kazimentou.fr/pluxml-plugins/index.php?plugin=xxxxxx&versions

Fonction pour télécharger la dernière version du plugin: (si on utilise un nom de fichier du type "pluginA-1.0.zip")
http://www.kazimentou.fr/pluxml-plugins/index.php?plugin=xxxxxx&download

Utiliser la date de infos.xml plutôt que la date d'ajout dans le dépôt.
actuellement on a la date d'ajout du plugin dans le dépôt mais pas la date de création du plugin.
- pb avec le format de date -> on l'affiche sous forme de texte mais c'est pas uniformisé dans le formulaire

Pb performance ?
Ajouter un cache au lieu de récupérer les infos dans les .zip
- on crée le cache en vérifiant que le fichier cache.xml est plus récent que les plugins présents dans le dépôt.

Pendant qu'on est dans les propositions, il faudrait voir si on a besoin de différencier plugin et thème.
en ajoutant simplement un fichier infos.xml dans l'archive du thème ça fonctionne très bien.
http://blog.niqnutn.com/data/documents/011/pluxml-plugins/index.php

bazooka07 · octobre 2015

Bonjour,

Petite mise à jour de mon gestionnaire de dépôts :
[list=*]
[*]affichage des icônes des plugins[/*]
[*]retouches cosmétiques[/*]
[*]numéro de version dans le source[/*]
[/list]

Cela se voit ici : http://kazimentou.fr/pluxml-plugins/

Si vous regardez le code source de la page, pas de panique à la vue de gros paquets incompréhensibles d'octets.
Les logos sont embarqués dans la page html pour économiser de la base passante du serveur.
Cela devrait s'afficher plus vite car le serveur ne répond qu'une fois.

A++

niqnutn · octobre 2015

bazooka07 a écrit:

[list=*]
[*]numéro de version dans [del]le[/del] la source[/*]
[/list]

j'ai pas compris

bazooka07 · octobre 2015

Numéro de version de la page qui affiche la liste des plugins.

Bon, j'ai rajouté la possibilité de télécharger un catalogue contenant l'ensemble des infos.xml au format xml.
Cela évitera de charger les fichiers infos.xml de tous les plugins, un par un.

A+

niqnutn · octobre 2015

Je suis en train de bidouiller ton dépôt.
L'idée est de ne pas se préoccuper du nom de l'archive, on récupère directement le fichier infos.xml .
Après on enregistre toutes les infos.xml dans un cache, l'équivalent de ton catalogue.

L'objectif final est de pouvoir gérer les différentes versions d'un plugin.
Pour le moment, j'ai le tableau avec les infos de tous les plugins.
Je m'attaque aux pb de versions: afficher la dernière version dispo (/index.php?plugin=xxxxxx ), lister toutes les versions présentes dans le dépôt et afficher seulement la dernière version dans le tableau.

en cours

Vérifier la dernière version des plugins utilisés.

Réponses