🌍
Français
Gotcha a écrit:
Je ne sais pas si lors de vos essais avec vos différentes versions de vos plugins, vous avez pensé à changer la ligne correspondante (dans main.inc.php) à l'URL du dépôt.
raahhhhh..... quel imbécile ! snif !
Bon il est trop tard pour ce soir mais je referais une tentative à mon retour de voyage (pas avant quatre jours)
Merci beaucoup, je ne sais pas si c'est la seul chose qui manque mais ça va m'aider.
(je vais mettre à jour le guide sur mon site pour ne pas oublier)
Bonne soirée
Je ne sais pas si lors de vos essais avec vos différentes versions de vos plugins, vous avez pensé à changer la ligne correspondante (dans main.inc.php) à l'URL du dépôt.
Merci Gotcha pour ta réponse.
Il n'y a pas de problème, je comprends bien que cela ne doit pas être un sujet simple à expliquer.
Il me manquait peut être pas grand chose pour y arriver.
Au final, j'ai quand même réussi à installer PEM ;).
Cela me sera surement utile avec la version de Piwigo 2.2 si je continu à faire évoluer le plugin.
Encore merci à tous.
Note: la prochaine fois je négocierais un peu plus pour garder mon nom de plugin quitte à faire moi même les démarches au près de canal+ ;).
C'est Grum qui s'y connait bien aussi avec PEM en local. Il est très occupé par son travail cependant.
[EDIT]
Je me suis permis de rajouter un lien vers votre page, dans notre [wiki]
Merci.
flop25 a écrit:
je te conseille de lire ces sujets là
topic:19778 puis topic:19784
J'ai regardé les sujets.
Cela m'a aidé à comprendre que c'est plus compliqué que prévu ;) et que je dois codé le comportement dans mon plugin.
Je me suis vite rendu compte que sans un PEM en local pour des tests je ne pouvais pas m'en sortir.
J'ai donc installé PEM :D
J'ai lu l'aide (un fichier readme dans le répertoir doc) suivante :
Installation
========
1. extract files from the archive
2. place de source files on your website in the directory of your choice
("extensions" for example)
TODO...
How to start
=========
TODO...
Là, j'ai vraiment compris que j'allais en baver :(
Mais bon! au final ca c'est pas trop mal passé. J'ai documenté les étapes que j'ai effectué pour installer PEM en local sous windows sur mon site.
J'ai réussi à installer mon la version du plugin Piwishadow 0.1.9 sur mon PEM puis sur ma version local de Piwigo.
J'ai renommé le plugin sous PEM en Shadogo et ajouté une nouvelle révision (0.1.10) à partir d'un zip du code sous SVN.
Le problème est que sous Piwigo je ne vois pas ma nouvelle révision comme une mise à jour de Piwishadow version 0.1.9 mais comme un nouveau plugin (i.e la révision est affichée que dans l'onglet 'Autres plugins disponibles').
J'ai donc une différence de comportement entre le Piwigo sur mon serveur (2.1.6) et ma version local (trunk).
J'ai donc installé la version 2.1.6 en local pour voir si ma supposition était la bonne.
Je refais le test et la ... bah... il ne me trouve pas mon PEM local.
Je crois comprendre que l'option $conf['alternative_pem_url'] n'est pas disponible avec la version 2.1.6 de Piwigo.
Donc... sans environnement de test, j'abandonne :'(
Au final, je ne sais toujours pas comment faire pour gérer correctement le changement de nom que vous m'avez demandé.
J'opte pour la solution grade (celle du début).
1. Je renomme le plugin en Shadogo
2. j'ajoute une révision
3. j'ajoute une note pour dire qu'il vaut mieux désinstaller le plugin pour le re-installer proprement :(
je te conseille de lire ces sujets là
topic:19778 puis topic:19784
C'est tout ce que je peux te répondre pour ma part
bonne lecture
J'ai fait le test suivant:
1) J'ai Renomer l'ancien plugin Piwishadow en Shadogo
2) Ajout d'une nouvelle révision avec Shadog à partir de SVN dans Piwigo.org
3) Mise à jour du plugin à partir de la console d'administration dans Piwigo
4) ... ca ne c'est pas passé comme je le pensé :p
5) Suppression de la nouvelle révision dans Piwigo.org
Le nom du plugin reste Piwishadow dans l'onglet contenant la liste des plugins à mettre à jour.
Il n'y a pas de nouveau répertoire de créé avec le nouveau nom du plugin
L'ancien répertoire du plugin (Piwishadow) n'est pas supprimé.
La mise à jour ce fait dans le répertoire du plugin avec l'ancien nom.
Je n'ai peut être pas bien compris ce qu'il fallait faire ?
Si ce n'est pas possible de renommer une extension pourquoi cette option est disponible dans le gestionnaire d'extension ?
Faut-il que je crée une autre extension avec le nom de Shadogo?
Merci pour votre aide.
Bonsoir,
J'ai modifié le code pour prendre en compte le changement de nom du plugin et je souhaiterais faire le changement de nom et de code en ajoutant une révision à Piwishadow.
Si je modifie l'extension Piwishadow (via le gestionnaire de Piwigo.org) pour en changer le nom en Shadogo et que j'ajoute une nouvelle révision à partir du code sous SVN de Shadogo, est ce que cela va fonctionner ?
Est-ce-que j'ai un moyen de forcer une re-installe avec cette révision ?
(i.e suppression de tous les fichier et répertoires de la version n-1)
Note: Je souhaiterais éviter la solution qui serait de créer un nouveau plugin avec un nouveau nom et de laisser l'ancien mourir sans proposer un nettoyage.
Merci.
Merci Zaphod pour ton message d'encouragement ;)
Je pense que l'utilisation de fichier est viable d'autant plus si on la couple avec un cache.
Mais le fait est qu'il est préférable de profiter de l'optimisation faite dans Piwigo sur la gestion de la configuration. Je pense que si tout les plugins partent sur des solutions différentes au final c'est l'ensemble qui en pâtit.
binaryworld a écrit:
Bon... je digère le changement de nom de mon plugin et les modifications de code associé... je pleure sur le code que j'ai écrit pour ma super idée de double fichier ini... et quand j'aurais repris mes esprits après cette double perte... je vois comment changer mon code pour utiliser la DB.
J'avais utilisé le même genre de truc sur mon thème (sauf que je n'avais pas écris le code - j'en aurais été incapable - je l'avais repris sur les thèmes gally) parce que j'avais trouvé le principe très bon.
Et puis je viens de changer pour des paramètres stockés en DB, c'est finalement beaucoup plus simple.
Mais les deux marchent très bien.
binaryworld a écrit:
Bon... je digère le changement de nom de mon plugin et les modifications de code associé... je pleure sur le code que j'ai écrit pour ma super idée de double fichier ini...
Tu stockes tes paramètres de configuration comme tu veux, l'essentiel, c'est que le plugin fonctionne!
binaryworld a écrit:
et quand j'aurais repris mes esprits après cette double perte... je vois comment changer mon code pour utiliser la DB.
Le code sera forcément simplifié! Tu accèderas directement à tes paramètres via la variable globale $conf. Pas de requete SQL à faire, ni de fichier à lire. Et pour mettre à jour la configuration, il y a la fonction conf_update_param().
P@t a écrit:
La table de configuration de piwigo est systématiquement chargée en entier (1 requête SQL). Le ou les paramètre(s) de ton plugin seront compris dedant si tu stocke dans cette table: pas de requête SQL supplémentaire.
Bon... je digère le changement de nom de mon plugin et les modifications de code associé... je pleure sur le code que j'ai écrit pour ma super idée de double fichier ini... et quand j'aurais repris mes esprits après cette double perte... je vois comment changer mon code pour utiliser la DB.
binaryworld a écrit:
Reste que l'idée de proposer les deux choix "une mise à jour" ou "une réinstallation" dans l'onglet de Mise à jour des plugins dans Piwigo en fonction des capacités du plugin ne serait pas une mauvaise chose, non?
Je ne suis pas d'accord du tout. L'installation ou la mise à jour d'un plugin doit rester la plus simple possible pour un utilisateur. C'est pour ça que j'avais fait le plugin manager. Un auto upgrade intégré au main.inc.php est de loin ce qu'il y a de plus facile pour l'utilisateur, puisque c'est complètement transparent. Et c'est pas trop compliqué à mettre en oeuvre (cf Additional Pages).
binaryworld a écrit:
Edité: Oups! pas la peine de répondre. Je test l'upgrade sur mon serveur en 2.1.6. Je viens de comprendre quand 2.2 il est possible re-installer le plugin à partir du 3e onglet.
Non, ce n'est pas possible de réinstaller directement un plugin à partir du troisième onglet. Un plugin déjà installé n'apparait plus dans le troisième onglet, sauf erreur dans le main.inc.php du plugin.
binaryworld a écrit:
Blague à part, je ne sais pas trop ce qui est le plus efficace entre DB ou fichier par rapport à la configuration géré dans mon plugin. En plus cela doit surement dépendre de la plateforme ou est installé Piwigo.
La table de configuration de piwigo est systématiquement chargée en entier (1 requête SQL). Le ou les paramètre(s) de ton plugin seront compris dedant si tu stocke dans cette table: pas de requête SQL supplémentaire.
Si tu stocke dans un fichier, c'est un accès au filesystem supplémentaire! Donc côté performances, c'est incomparable, il faut mieux utiliser le stockage en base de données.
binaryworld a écrit:
Toutefois que ce soit DB ou fichier, une solution basé sur un cache (en mémoire) serait intéressante (par exemple avec APC).
Je ne connais pas APC, mais je peux voir que ce n'est pas une extension PHP courante, et que celle-ci sera probablement absente chez la plupart des hébergeurs (à confirmer quand même). Mieux vaut oublier...
Ok je note dans le coin de ma tête qu'il faut gérer la mise à jour des données en base différemment de la mise à jour du plugin dans Piwigo.
Reste que l'idée de proposer les deux choix "une mise à jour" ou "une réinstallation" dans l'onglet de Mise à jour des plugins dans Piwigo en fonction des capacités du plugin ne serait pas une mauvaise chose, non?
Edité: Oups! pas la peine de répondre. Je test l'upgrade sur mon serveur en 2.1.6. Je viens de comprendre quand 2.2 il est possible re-installer le plugin à partir du 3e onglet.
plg a écrit:
Corriges moi si je me trompe, mais le fichier de l'utilisateur est sauvegardé en tant que PIWISHADOW_PATH .'config.inc.php', ce n'est pas le bon endroit. Soit c'est dans $conf['local_data_dir'] (_data par défaut) soit dans PHPWG_ROOT_PATH.PWG_LOCAL_DIR (en version 2.2 seulement). Sinon ton plugin ne fonctionnera pas en mode multisite et tu obliges à avoir le fichier config.inc.php autorisé en écriture.
Zut... je n'avais pas vu que vous aviez une variable globale pour ca.
Ok je vais mettre mon fichier de conf utilisateur dans ce répertoire c'est bien mieux.
Merci pour l'info.
plg a écrit:
Certes... je ne recommande pas du tout de faire cela, mais c'est ton plugin, tu codes comme tu le sens :-)
Bon alors ça... si ce n'est pas de la provoque...
Effectivement c mon miens à moi rien qu'a moi, même si on me demande de changer de librairie, de répertoire de configuration, de nom, ... :rolleyes:
Blague à part, je ne sais pas trop ce qui est le plus efficace entre DB ou fichier par rapport à la configuration géré dans mon plugin. En plus cela doit surement dépendre de la plateforme ou est installé Piwigo. Toutefois que ce soit DB ou fichier, une solution basé sur un cache (en mémoire) serait intéressante (par exemple avec APC).
J'avais pensé à utilisé la table config mais je n'aimais pas trop l'idée d'utiliser une table de Piwigo (je n'avais pas envie qu'un bug dans mon plugin provoque des effets de bord).
Pour l'instant j'aime bien l'idée que le plugin soit le plus neutre possible.
Quand j'aurais une meilleur idée de comment fonctionne Piwigo (ca commence a venir ;) j'utiliserais surement la DB pour de nouvelle fonctionnalité que je souhaite ajouter mais qui sont plus gourmandes sur la persistance des données.
Merci pour ton aide,
Vincent.
A te lire je pense qu'il y a quiproquo.
Piwigo dispose d'un mécanisme qui va regarder sur piwigo.org/ext si une nouvelle version de chaque plugin installé est disponible. Si c'est le cas, on propose à l'utilisateur de mettre à jour en cliquant sur un lien (et c'est possible de lancer plusieurs mises à jour d'un seul coup en 2.2).
Ensuite, il y a le plugin qui va mettre à jour le modèle de données en fonction de ses besoins. En général, les développeurs comptent sur un passage par la fonction plugin_activate() pour effectuer cette mise à jour. Moi je conseille de ne pas compter dessus.
Exemple :
1) l'utilisateur a le plugin Community en version 2.1.c, il a une table "community" dans la base de données, qui a été créée lors de l'installation du plugin
2) l'utilisateur voit sur la page [Administration > Pugins > Gérer > Mise à jour] qu'une version 2.2.e est disponible et il décide de mettre à jour. La version 2.2 a besoin qu'une nouvelle table soit présente, la table "community_permissions".
La stratégie que je conseille, c'est que l'ajout de la table community_permissions, ne requiert pas forcément un passage par la fonction plugin_activate()
binaryworld a écrit:
J'ai basé ma solution sur l'utilisation de deux fichier ini. Un fournit par défaut avec le plugin et l'autre utilisé pour sauvegarder la configuration de l'utilisateur.
Corriges moi si je me trompe, mais le fichier de l'utilisateur est sauvegardé en tant que PIWISHADOW_PATH .'config.inc.php', ce n'est pas le bon endroit. Soit c'est dans $conf['local_data_dir'] (_data par défaut) soit dans PHPWG_ROOT_PATH.PWG_LOCAL_DIR (en version 2.2 seulement). Sinon ton plugin ne fonctionnera pas en mode multisite et tu obliges à avoir le fichier config.inc.php autorisé en écriture.
binaryworld a écrit:
L'avantage de passer par le format ini plutôt que la sérialisation c'est qu'il est directement exploitable par l'utilisateur ce qui peut être utile si l'hébergeur ne permet pas l'écriture sur disque depuis php.
Certes... je ne recommande pas du tout de faire cela, mais c'est ton plugin, tu codes comme tu le sens :-) La table config est conçue pour cela, elle permet de limiter le nombre de fichiers à charger, elle dispose de fonction pour mettre à jour facilement un paramètre, etc. Il n'est absolument pas nécessaire de sérialiser, tu peux faire plusieurs paramètres dans la base, mais je recommande de les préfixer par le nom ou l'acronyme de ton plugin, afin d'éviter les conflits potentiels avec d'autres plugins.