c'est pas terminé mais j'ai maintenant la possibilité de gérer les versions d'un plugin.
Plus de pb avec le nom de l'archive ni du nom du dossier à l'intérieur.
Bien content que ma petite page PHP suscite ton intérêt. Et tu n'es pas le seul apparemment.
C'est donc bien qu'il y a un réel besoin d'avoir un outil pour gérer et afficher le dépôt de ses plugins.
L'idée sous-jacente est de pouvoir signaler à l'administrateur d'un site qu'un plugin dispose d'une nouvelle version et de lui dire où la récupérer (d'où l'intérêt de rajouter un champ repository dans infos.xml).
Conserver toutes les versions d'un plugin me parait d'un intérêt secondaire. Les nouvelles versions de plugin sont censées faire plus que les anciennes. Il me semble plus judicieux de tester les nouvelles versions sur 2 versions de Pluxml, actuellement 5.3 et 5.4. Car faire la mise à jour d'un site est toujours une opération périlleuse. Surtout si on fait des modifs comme j'ai l'habitude d'en faire.
C'est vrai que le nom de l'archive peut-être contraignant. Surtout s'il contient un numéro de version. Mais pour un premier jet, j'ai fait au simple pour avoir quelque chose qui commence à tourner. Je verrais comment corriger cela.
Attention aux archives extraites de github, il y a un dossier à renommer à l'installation.
J'avais pensé à faire un cache mais vu la vitesse actuelle des serveurs cela m'a paru superflu. Par contre afficher les icônes des plugins me parait plus vendeur. Et comme je voulais une réponse rapide à travers le net, j'embarque les images dans la page générée, comme cela, le navigateur envoie seulement une requête au serveur et qu'il recoit toutes les icônes dans la page. Laisser le soin aux visiteurs de remettre à jour le cache me laisse septique. 1000 visteurs qui remettent à jour en même temps le cache vont certainement occupér le serveur pour rien.
Je me suis plus qu'inspiré de ton travail.
L'objectif est de voir les points qui pose pb mais qu'on se mettent tous d'accord pour l'essentiel: récupérer la dernière version d'un plugin.
Oui, il y a intéret à ajouter un champ repository dans infos.xml
Garder les anciennes versions n'est peut être pas l'objectif principal mais j'ai eu des pb avec la dernière version d'un plugin qui ne marche pas avec la 5.3.
Du coup, c'est toujours pratique de retrouver facilement une ancienne version compatible. Si on peut tout gérer au même endroit c'est mieux .
Tu te bases sur le nom du zip et du dossier, ce qui pose pb si je récupère le plugin depuis Github avec son "plugin-master".
Je me suis basé sur le "title" du infos.xml mais je risque d'avoir un pb si le nom change.
Je pense qu'il faudrait ajouter un champ supplémentaire qui correspond à "plugin.php" car il ne changera pas.
Comme "repository", "plugin"serait un champ optionnel pour faciliter la gestion des dépôts.
Pour le moment, je ne vois pas comment faire pour identifier facilement un plugin.
Pour le cache, c'est plus pertinent si tu commences à gérer des archives, ce qui n'est pas ce que tu as envisagé.
Pour l'affichage des images, c'est plus agréable et je l'intégrerai par la suite.
Je ne sais pas s'il faut laisser ou non la possibilité de rafraîchir le cache et d'avoir une URL publique. Si ça peut éviter de supprimer le fichier via FTP, c'est ça de pris.
Le cache n'est plus ou moins que la concaténation des fichiers info.xml donc cela ne doit pas faire beaucoup de différence avec ce que tu as proposé.
J'ai changer le nom du fichier juste pour avoir un point de comparaison avec ton dépôt. Sur Github, j'ai bien mis ça dans index.php .
L'essentiel est déjà là.
Une fois terminé, j'aimerai faire le dépôt sous forme de plugin pour PluXml.
Le dépôt tient dans un seul fichier, il suffira de faire pointer le dossier "plugins" au bon endroit (/data/documents/plugin-repository ou /data/documents/plugin-repository par exemple).
Du coup, tout le monde pourrait avoir un dépôt qui ressemble à http://MonPluXml/plugins/repository/index.php
J'ai sorti une version 2 de mon gestionnaire de dépôts pour plugins. Elle gére :
[list=*]
[*]les multiples versions d'un plugin[/*]
[*]le non-respect du nom de dossier du plugin dans l'archive (cas typique des archives récupérées sur Github)[/*]
[*]le nom de l'archive peut-être différent de celui du plugin[/*]
[*]téléchargement du catalogue du dépôt au format json. J'ai mis une petite démo pour utiliser le catalogue[/*]
[/list]
Par rapport à la première version, cela est plus compiqué quand on accorde une certaine liberté au nommage et à la structure des archives.
Pour le catalogue, j'ai abandonné le format XML au profit du JSON car c'est d'une incroyable facilité. A étudier pour Pluxml ...
Je note que le dossier de l'archive doit obligatoirement contenir le nom du plugin (c'est pas gênant).
Est ce qu'il ne serait pas intéressant d'intégrer le nom du plugin directement dans infos.xml ? ça éviterai de passer par getPluginName()
[== XML ==]
<?xml version="1.0" encoding="UTF-8"?>
<document>
<title><![CDATA[Plugin pour PluXml]]></title>
<author><![CDATA[contributeurs PluXml ]]></author>
<version>9.7</version>
<date>25/10/2015</date>
<site>http://pluxml.com</site>
<description><![CDATA[description du plugin]]></description>
<requirements>PluXml 5.4</requirements>
<plugin>pluginTest.php</plugin>
<repository>http://repository.pluxml.com</repository>
</document>
La date affiché correspond à la date d'ajout dans le dépôt (c'est pas le choix que je ferai).
Je ne vois pas trop l'intérêt de garder la colonne infos ? on a déjà toutes les infos dans le tableau
sinon, je pense qu'on peut pourrait ajouter
/pluxml-plugins/index.php?plugin=xxxxxx&download pour récupérer l'archive du plugin. ça sera certainement par la suite.
Je pensai mettre les thèmes pour PluXml dans le même dossier en lui ajoutant un fichier infos.xml .
ça marche mais ça affiche "0" dans le nom du plugin. je vais regarder si on peut trouver quelque chose mais je pense que le mieux serait de récupérer le "title" dans infos.xml
Au final, pas grand chose à dire sur ton travail.
j'ai pas vu de pb avec les plugins que j'ai et tout s'affiche correctement.
Non, le dossier n'est pas forcément celui du plugin.
Quand je prends l'archive au départ, je n'ai aucune idée précise sur le nom du plugin.
Je suis obligé de parcourir toutes les entrées de l'archive pour en trouver une qui finit par infos.xml
Et à ce stade je n'ai pas encore le nom du plugin.
En informatique, on a coutume de dire que le plus gros problème se situe entre le clavier et la chaîne.
Dans infos.xml la balise title est un truc purement cosmétique qui ne sert à rien à part apporter un côté humain.
La valeur de title peut très bien être "Mon super plugin du siècle qui décoiffe les punks". Cela n'empêchera pas le plugin de fonctionner et on n'a toujours pas son nom.
Le seul truc fiable est de scanner les fichiers php dans le dossier de l'archive et de trouver une déclaration de classe dérivée de PlxPlugin. Il y a une expression régulière pour cela. D'où le besoin de getPluginName().
La date est celle de l'archive. Pas celle de la date de dépôt. J'ai un bout de script bash qui règle la date de l'archive sur celle du dernier fichier php modifié. En prime, il récupère le numéro de version dans infos.xml.
La colonne infos est juste pour vérifier que ce qui est affiché à l'écran est cohérent avec le contenu de infos.xml. Il y a des chances qu'elle disparaisse dans le temps mais rien ne presse.
On peut effectivement rajouter une option pour download. C'est pas un gros boulot. J'attends un temps pour voir s'il y a d'autres remarques.
On pourrait appliquer le même principe aux thèmes même si le besoin semble bien moins fort. Juste le problème du nom de thème à régler puisqu'il n'y a plus de classe.
Se baser sur le nom du dossier en le filtrant pour éliminer le numéro de version et les traces de Github.
P.S. : C'est bien plus agréable de travailler avec JSON plutôt que XML.
effectivement, le nom du dossier n'est pas important. J'avais 2 archives d'un plugin avec la même version mais des noms différents, seulement un seul est affiché. Je pensais que c'était à cause de ça.
pour la date, j'ai pas fait attention mais je voulais dire que la date de l'archive ne correspond pas nécessairement à la date de sortie du plugin.
la date affichée dans le tableau ne correspondra pas toujours avec ce qui est indiqué dans infos.xml (en supposant que les infos sont justes).
Au final, la date n'a pas grande importance et la version est plus importante. C'est juste une remarque.
ce que je suggérai c'est d'indiquer, en plus du nom du plugin (qui peut changer), le nom du dossier du plugin tel qu'il est sur le FTP et qui correspond avec le fichier PHP. Cela pourrait éviter dans lancer cette fonction mais c'est peut être plus efficace de lancer directement getPluginName().
Je suis désolé de réagir a votre débat mais je tiens a vous signaler qu'une équipe bosse déjà sur la gestion des plugins et des thèmes. Je ne pense pas qu'il soit nécessaire de refaire la roue et de travailler dans des directions différentes.
Il semblerait que l'orientation choisie soit un dépôt central (coté pluxml.org) ou chaque auteur pourra administrer ses thèmes et ses plugins via un compte utilisateur. Ce dépôt centralisé a l'avantage de simplifier complètement la problématique des dépôts externes. L'administration centrale permettra aux administrateurs de rajouter des catégories de filtre, d'avoir un contrôle sur les auteurs, les plugins et les thèmes.
Coté pluxml, un plugin permettra d'installer thèmes et plugins incluant un moteur de recherche par mots clefs, catégories, auteurs, version, hits... Quelque-chose d'assez complet (rien a voir avec spxplugindownloader).
Quelques mises à jour du gestionnaire de dépôt, plus quelques fonctionnalités supplémentaires (features) :
[list=*]
[*]ajout d'une aide pour installer son plugin[/*]
[*]et surtout gestion d'un flux RSS pour se tenir aux courants des dernières évolutions de vos plugins préférés[/*]
[/list]
On peut vérifier la validité du flux RSS généré ici : http://validator.w3.org/feed/check.cgi?url=http%3A//kazimentou.fr/pluxml-plugins2/index.php%3Frss
La suppression du nom de l'archive conduit à un lien pour télécharger moins intuitif.
Pour y remédier, j'ai rajouté un lien dans la colonne Plugin ou "nom du plugin"
J'ai également corrigé la fonction getPluginIcon :
manque un break dans la boucle for
les archives construites sous Mac générent un fichier ._icon.png. Je n'ai pas de Mac pour le vérifier. Je filtre de façon plus stricte le nom des entrées de l'archive zip.
J'ai créé aussi une constante VERSION pour faciliter le suivi.
Plus quelques retouches cosmétiques inévitables.
Et c'est toujours au même endroit : http://www.kazimentou.fr/pluxml-plugins2/
P.S. : Je garde le lien de ton dépôt sous le coude, J'ai dans l'idée de créer un plugin pour parcourir facilement le catalogue de différents dépôts et de surveiller la mise à jour des plugins installés qui était l'idée de départ.
On pourrait remplacer le nom de l'archive par une icône pour faciliter le téléchargement et épuré le tableau. On peut aussi rajouter un lien de téléchargement sur l’icône du plugin.
J'ai noté que tu avais ajouté
"/pluxml-plugins2/index.php?plugin=xxxxxx&download télécharge la dernière version du plugin xxxxxx"
ça devrait faciliter la suite.
oui, j'ai remarqué qu'il récupérait ce qui correspond à *icon.png et m'avait récupérer un fichier favicon.png .
pour info: en regardant la doc, il y a plusieurs type d'images autorisées pour les icônes.
"Formats autorisés : jpg, gif, png"
Au delà de l'aspect cosmétique, on peut maintenant récupérer toutes les infos d'un plugin directement depuis le dépôt.
C'est toujours RTFM (Read This Fucking Manual). Pour la jouer plus sûrement, j'ai regardé le source du fichier core/admin/parametres-plugins.php pour voir ce que Pluxml recherchait. C'est bien /icon.png ou /icon.jpg ou icon.gif. Manque /icon.jpeg. On s'en passera.
Je régle le problème comme ceci :
[== PHP ==]
if (preg_match('#/icon\.(?:jpg|png|gif)$#', $filename)) {...}
Non, je garde le nom du plugin pour les mal-voyants et les daltoniens.
Et je mets un lien avec l'icône pour ceux qui utilisent l'écran de leur petit smartphone avec leur gros doigt.
C'est un dialogue de sourd, rien n’empêche les membres de la communauté de se créer un outils s'ils veulent...
Après il faut qu'ils soient simplement au courant qu'un dispositif similaire plus élaboré verra le jours très bientôt.
Réponses
c'est pas terminé mais j'ai maintenant la possibilité de gérer les versions d'un plugin.
Plus de pb avec le nom de l'archive ni du nom du dossier à l'intérieur.
Bien content que ma petite page PHP suscite ton intérêt. Et tu n'es pas le seul apparemment.
C'est donc bien qu'il y a un réel besoin d'avoir un outil pour gérer et afficher le dépôt de ses plugins.
L'idée sous-jacente est de pouvoir signaler à l'administrateur d'un site qu'un plugin dispose d'une nouvelle version et de lui dire où la récupérer (d'où l'intérêt de rajouter un champ repository dans infos.xml).
Conserver toutes les versions d'un plugin me parait d'un intérêt secondaire. Les nouvelles versions de plugin sont censées faire plus que les anciennes. Il me semble plus judicieux de tester les nouvelles versions sur 2 versions de Pluxml, actuellement 5.3 et 5.4. Car faire la mise à jour d'un site est toujours une opération périlleuse. Surtout si on fait des modifs comme j'ai l'habitude d'en faire.
C'est vrai que le nom de l'archive peut-être contraignant. Surtout s'il contient un numéro de version. Mais pour un premier jet, j'ai fait au simple pour avoir quelque chose qui commence à tourner. Je verrais comment corriger cela.
Attention aux archives extraites de github, il y a un dossier à renommer à l'installation.
J'avais pensé à faire un cache mais vu la vitesse actuelle des serveurs cela m'a paru superflu. Par contre afficher les icônes des plugins me parait plus vendeur. Et comme je voulais une réponse rapide à travers le net, j'embarque les images dans la page générée, comme cela, le navigateur envoie seulement une requête au serveur et qu'il recoit toutes les icônes dans la page. Laisser le soin aux visiteurs de remettre à jour le cache me laisse septique. 1000 visteurs qui remettent à jour en même temps le cache vont certainement occupér le serveur pour rien.
Si la page s'appelle index.php ce n'est pas anodin. C'est le nom par défaut d'une page d'un dossier quand le visiteur ne précise pas le nom de la page.
http://www.monsite.com/plugins/?plugin=xxxx est beaucoup plus simple à retenir que http://www.monsite.com/plugins/repository.php?plugin=xxxx.
Par sécurité, j'isole tous les archives zip des plugins dans un dossier.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
L'objectif est de voir les points qui pose pb mais qu'on se mettent tous d'accord pour l'essentiel: récupérer la dernière version d'un plugin.
Oui, il y a intéret à ajouter un champ repository dans infos.xml
Garder les anciennes versions n'est peut être pas l'objectif principal mais j'ai eu des pb avec la dernière version d'un plugin qui ne marche pas avec la 5.3.
Du coup, c'est toujours pratique de retrouver facilement une ancienne version compatible. Si on peut tout gérer au même endroit c'est mieux .
Tu te bases sur le nom du zip et du dossier, ce qui pose pb si je récupère le plugin depuis Github avec son "plugin-master".
Je me suis basé sur le "title" du infos.xml mais je risque d'avoir un pb si le nom change.
Je pense qu'il faudrait ajouter un champ supplémentaire qui correspond à "plugin.php" car il ne changera pas.
Comme "repository", "plugin"serait un champ optionnel pour faciliter la gestion des dépôts.
Pour le moment, je ne vois pas comment faire pour identifier facilement un plugin.
Pour le cache, c'est plus pertinent si tu commences à gérer des archives, ce qui n'est pas ce que tu as envisagé.
Pour l'affichage des images, c'est plus agréable et je l'intégrerai par la suite.
Je ne sais pas s'il faut laisser ou non la possibilité de rafraîchir le cache et d'avoir une URL publique. Si ça peut éviter de supprimer le fichier via FTP, c'est ça de pris.
Le cache n'est plus ou moins que la concaténation des fichiers info.xml donc cela ne doit pas faire beaucoup de différence avec ce que tu as proposé.
J'ai changer le nom du fichier juste pour avoir un point de comparaison avec ton dépôt. Sur Github, j'ai bien mis ça dans index.php .
L'essentiel est déjà là.
Une fois terminé, j'aimerai faire le dépôt sous forme de plugin pour PluXml.
Le dépôt tient dans un seul fichier, il suffira de faire pointer le dossier "plugins" au bon endroit (/data/documents/plugin-repository ou /data/documents/plugin-repository par exemple).
Du coup, tout le monde pourrait avoir un dépôt qui ressemble à http://MonPluXml/plugins/repository/index.php
J'ai sorti une version 2 de mon gestionnaire de dépôts pour plugins. Elle gére :
[list=*]
[*]les multiples versions d'un plugin[/*]
[*]le non-respect du nom de dossier du plugin dans l'archive (cas typique des archives récupérées sur Github)[/*]
[*]le nom de l'archive peut-être différent de celui du plugin[/*]
[*]téléchargement du catalogue du dépôt au format json. J'ai mis une petite démo pour utiliser le catalogue[/*]
[/list]
Par rapport à la première version, cela est plus compiqué quand on accorde une certaine liberté au nommage et à la structure des archives.
Pour le catalogue, j'ai abandonné le format XML au profit du JSON car c'est d'une incroyable facilité. A étudier pour Pluxml ...
[del]La démo est visible ici: http://www.kazimentou.fr/pluxml-plugins/index2.php
Et il n'y a toujours qu'un fichier à installer sur vote site (Renommez index2.php en index.php)[/del]
La démo est visible ici: http://www.kazimentou.fr/pluxml-plugins2/.php
Et il n'y a toujours qu'un fichier à installer sur vote site
A+++
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Je note que le dossier de l'archive doit obligatoirement contenir le nom du plugin (c'est pas gênant).
Est ce qu'il ne serait pas intéressant d'intégrer le nom du plugin directement dans infos.xml ? ça éviterai de passer par getPluginName()
La date affiché correspond à la date d'ajout dans le dépôt (c'est pas le choix que je ferai).
Je ne vois pas trop l'intérêt de garder la colonne infos ? on a déjà toutes les infos dans le tableau
sinon, je pense qu'on peut pourrait ajouter
/pluxml-plugins/index.php?plugin=xxxxxx&download pour récupérer l'archive du plugin. ça sera certainement par la suite.
Je pensai mettre les thèmes pour PluXml dans le même dossier en lui ajoutant un fichier infos.xml .
ça marche mais ça affiche "0" dans le nom du plugin. je vais regarder si on peut trouver quelque chose mais je pense que le mieux serait de récupérer le "title" dans infos.xml
Au final, pas grand chose à dire sur ton travail.
j'ai pas vu de pb avec les plugins que j'ai et tout s'affiche correctement.
Non, le dossier n'est pas forcément celui du plugin.
Quand je prends l'archive au départ, je n'ai aucune idée précise sur le nom du plugin.
Je suis obligé de parcourir toutes les entrées de l'archive pour en trouver une qui finit par infos.xml
Et à ce stade je n'ai pas encore le nom du plugin.
En informatique, on a coutume de dire que le plus gros problème se situe entre le clavier et la chaîne.
Dans infos.xml la balise title est un truc purement cosmétique qui ne sert à rien à part apporter un côté humain.
La valeur de title peut très bien être "Mon super plugin du siècle qui décoiffe les punks". Cela n'empêchera pas le plugin de fonctionner et on n'a toujours pas son nom.
Le seul truc fiable est de scanner les fichiers php dans le dossier de l'archive et de trouver une déclaration de classe dérivée de PlxPlugin. Il y a une expression régulière pour cela. D'où le besoin de getPluginName().
La date est celle de l'archive. Pas celle de la date de dépôt. J'ai un bout de script bash qui règle la date de l'archive sur celle du dernier fichier php modifié. En prime, il récupère le numéro de version dans infos.xml.
La colonne infos est juste pour vérifier que ce qui est affiché à l'écran est cohérent avec le contenu de infos.xml. Il y a des chances qu'elle disparaisse dans le temps mais rien ne presse.
On peut effectivement rajouter une option pour download. C'est pas un gros boulot. J'attends un temps pour voir s'il y a d'autres remarques.
On pourrait appliquer le même principe aux thèmes même si le besoin semble bien moins fort. Juste le problème du nom de thème à régler puisqu'il n'y a plus de classe.
Se baser sur le nom du dossier en le filtrant pour éliminer le numéro de version et les traces de Github.
P.S. : C'est bien plus agréable de travailler avec JSON plutôt que XML.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
pour la date, j'ai pas fait attention mais je voulais dire que la date de l'archive ne correspond pas nécessairement à la date de sortie du plugin.
la date affichée dans le tableau ne correspondra pas toujours avec ce qui est indiqué dans infos.xml (en supposant que les infos sont justes).
Au final, la date n'a pas grande importance et la version est plus importante. C'est juste une remarque.
ce que je suggérai c'est d'indiquer, en plus du nom du plugin (qui peut changer), le nom du dossier du plugin tel qu'il est sur le FTP et qui correspond avec le fichier PHP. Cela pourrait éviter dans lancer cette fonction mais c'est peut être plus efficace de lancer directement getPluginName().
un plugin pour gérer le dépôt
http://blog.niqnutn.com/data/documents/011/pluxml-plugins/plugins/repository-0.1.zip
edit: pour la gestion des thèmes, si on peut juste afficher un nom plus explicite, éventuellement basé sur le nom du dossier ça ira.
Je suis désolé de réagir a votre débat mais je tiens a vous signaler qu'une équipe bosse déjà sur la gestion des plugins et des thèmes. Je ne pense pas qu'il soit nécessaire de refaire la roue et de travailler dans des directions différentes.
Il semblerait que l'orientation choisie soit un dépôt central (coté pluxml.org) ou chaque auteur pourra administrer ses thèmes et ses plugins via un compte utilisateur. Ce dépôt centralisé a l'avantage de simplifier complètement la problématique des dépôts externes. L'administration centrale permettra aux administrateurs de rajouter des catégories de filtre, d'avoir un contrôle sur les auteurs, les plugins et les thèmes.
Coté pluxml, un plugin permettra d'installer thèmes et plugins incluant un moteur de recherche par mots clefs, catégories, auteurs, version, hits... Quelque-chose d'assez complet (rien a voir avec spxplugindownloader).
Je pense que vous en serez plus très bientôt
A plus
jéjé
@je-evrard
Hey guy,
Pendant que certains sont plongés dans leur étude, notre roue continue de creuser son sillon sereinement
@tous,
Quelques mises à jour du gestionnaire de dépôt, plus quelques fonctionnalités supplémentaires (features) :
[list=*]
[*]ajout d'une aide pour installer son plugin[/*]
[*]et surtout gestion d'un flux RSS pour se tenir aux courants des dernières évolutions de vos plugins préférés[/*]
[/list]
On peut vérifier la validité du flux RSS généré ici : http://validator.w3.org/feed/check.cgi?url=http%3A//kazimentou.fr/pluxml-plugins2/index.php%3Frss
@niqnutn,
J'ai tenu compte de ta remarque pour virer la colonne infos et j'ai le lien sur la date de l'archive. Ca gagne un peu de place.
A++
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
personnellement, j'ai simplifié le tableau mais après c'est une question de goût.
ou http://blog.niqnutn.com/plugins/repository/index.php
sinon pour récupérer le nom du thème, j'ai rajouté dans getPluginName() ça me suffit largement.
@bazooka07
Que veux tu dire par la ?
a+
jéjé
La suppression du nom de l'archive conduit à un lien pour télécharger moins intuitif.
Pour y remédier, j'ai rajouté un lien dans la colonne Plugin ou "nom du plugin"
J'ai également corrigé la fonction getPluginIcon :
manque un break dans la boucle for
les archives construites sous Mac générent un fichier ._icon.png. Je n'ai pas de Mac pour le vérifier. Je filtre de façon plus stricte le nom des entrées de l'archive zip.
J'ai créé aussi une constante VERSION pour faciliter le suivi.
Plus quelques retouches cosmétiques inévitables.
Et c'est toujours au même endroit : http://www.kazimentou.fr/pluxml-plugins2/
P.S. : Je garde le lien de ton dépôt sous le coude, J'ai dans l'idée de créer un plugin pour parcourir facilement le catalogue de différents dépôts et de surveiller la mise à jour des plugins installés qui était l'idée de départ.
A++
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
"/pluxml-plugins2/index.php?plugin=xxxxxx&download télécharge la dernière version du plugin xxxxxx"
ça devrait faciliter la suite.
oui, j'ai remarqué qu'il récupérait ce qui correspond à *icon.png et m'avait récupérer un fichier favicon.png .
pour info: en regardant la doc, il y a plusieurs type d'images autorisées pour les icônes.
"Formats autorisés : jpg, gif, png"
Au delà de l'aspect cosmétique, on peut maintenant récupérer toutes les infos d'un plugin directement depuis le dépôt.
C'est toujours RTFM (Read This Fucking Manual). Pour la jouer plus sûrement, j'ai regardé le source du fichier core/admin/parametres-plugins.php pour voir ce que Pluxml recherchait. C'est bien /icon.png ou /icon.jpg ou icon.gif. Manque /icon.jpeg. On s'en passera.
Je régle le problème comme ceci :
Non, je garde le nom du plugin pour les mal-voyants et les daltoniens.
Et je mets un lien avec l'icône pour ceux qui utilisent l'écran de leur petit smartphone avec leur gros doigt.
J'ai créé un dépôt sur Github: https://github.com/bazooka07/Pluxml-repository
A++
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Le nom d'archive n'a pas vraiment d'utilité, on cherche d'abord la version et son lien.
et avec la cellule clicable
LOL t'es un étudiant jéjé
C'est un dialogue de sourd, rien n’empêche les membres de la communauté de se créer un outils s'ils veulent...
Après il faut qu'ils soient simplement au courant qu'un dispositif similaire plus élaboré verra le jours très bientôt.