Pages: 1
Salut à tous !
Je souhaite corréler le nom de son dossier d'installation qui est actuellement NBC_UserAdvManager avec le nom du plugin qui est UserAdvManager.
Pour le dépôt SVN, le plugin est stocké dans un dossier NBC_UserAdvManager et je peux le renommer facilement. Le problème se situe au niveau de la future mise à jour du plugin sur les galeries. Il est déjà installé sous ../plugins/NBC_UserAdvManager et la mise à jour ne se fera pas. Au pire, on ajoutera un "nouveau" plugin UserAdvManager qu'on ne pourra pas installer car les tables sont déjà présentes.
Il faut que je trouve un moyen de renommer le dossier d'installation sans perdre la config (stockée dans la table _config) et les données propres au plugin (dans des tables additionnelles). J'ai tenté d'utiliser la fonction php rename() sans succès : Le renommage ne peut pas se faire sur un dossier actif.
J'ai aussi tenté l'approche d'installer le plugin dans un dossier UserAdvManager puis de supprimer l'autre. Pas mieux... Soit je perds la config du plugin, soit je plante l'installation.
J'ai en tête une autre idée qui consisterait de proposer une sauvegarde des données liées au plugin avant la mise à jour et le renommage du dossier d'installation mais il faudrait aussi pouvoir restaurer les données après coup. Et là, je sèche...
Si quelqu'un a une idée ou une méthode, je prends ;-)
Hors ligne
Dans le fichier d'installation du plugin, tu fais créer les tables que si elles n'existent pas.
Dans la fonction de mise à jour tu fais copier les fichiers dans le nouveau répertoire
Mettre à jour la table plugin
et supprimer l'ancien répertoire
Hors ligne
ddtddt a écrit:
Dans le fichier d'installation du plugin, tu fais créer les tables que si elles n'existent pas.
Dans la fonction de mise à jour tu fais copier les fichiers dans le nouveau répertoire
Mettre à jour la table plugin
et supprimer l'ancien répertoire
C'en est consternant de simplicité... Moi et ma sale manie de toujours chercher le passage le plus compliqué alors que la solution est tellement simple ;-)
Merci ddtddt ! ;-)
Dernière modification par Eric (2011-03-24 21:17:13)
Hors ligne
J'ai codé la méthode donnée par ddtddt et cela fonctionne parfaitement. Je pense même simplifier encore un peu plus cette méthode en m'abstenant de la copie des fichiers vers le nouveau répertoire. En effet, la nouvelle version de UAM ne sera compatible qu'avec la version 2.2 (et +) de Piwigo et la mise à jour sera sous condition de migration de Piwigo.
Il reste cependant une zone d'ombre : Comment va réagir la gestion des plugins de la galerie face à PEM qui proposera un plugin existant mais pas avec la même structure de fichiers ?
Mon raisonnement:
- Si on a une galerie 2.1.6 avec le plugin UAM 2.16.0 (ou antérieure), lors de la migration de la galerie vers 2.2.0, tous les plugins non standards sont désactivés par sécurité.
- La nouvelle version compatible de UAM devrait apparaitre dans la liste des plugins disponibles. Elle ne devrait pas apparaitre dans l'onglet "Rechercher les mises à jour" ni être proposée par Piwigo AutoUpgrade (à confirmer car je ne sais pas comment réagira l'ensemble lorsque la nouvelle archive sera sur PEM).
- Il suffirait d'installer et d'activer la nouvelle version comme s'il s'agissait d'un nouveau plugin sauf que le process d'activation effectuera la mise à jour des tables et la suppression de l'ancien répertoire.
Je pense que le meilleur moyen de savoir est que je publie une nouvelle version en RC du plugin. Avec la 2.2.0-RC4 et le plugin Piwigo AutoUpgrade, je devrais être fixé. Mais pour cela, je vais devoir renommer le dépôt SVN avant et je ne maitrise pas les implications que cela pourrait avoir...
Hors ligne
Eric a écrit:
- La nouvelle version compatible de UAM devrait apparaitre dans la liste des plugins disponibles. Elle ne devrait pas apparaitre dans l'onglet "Rechercher les mises à jour" ni être proposée par Piwigo AutoUpgrade (à confirmer car je ne sais pas comment réagira l'ensemble lorsque la nouvelle archive sera sur PEM).
il apparaitra dans l'onglet mise à jour ce n'est pas géré avec le nom de répertoire mais avec le 'numero' de plugin
la ligne
Plugin URI: http://piwigo.org/ext/extension_view.php?eid=NNN
Hors ligne
Eric a écrit:
Je pense que le meilleur moyen de savoir est que je publie une nouvelle version en RC du plugin. Avec la 2.2.0-RC4 et le plugin Piwigo AutoUpgrade, je devrais être fixé. Mais pour cela, je vais devoir renommer le dépôt SVN avant et je ne maitrise pas les implications que cela pourrait avoir...
il faut le faire avec la fonction de renommage de SVN pour ne pas perdre l'historique des commit et la possibilité de retour en arrière
Hors ligne
ddtddt a écrit:
Eric a écrit:
- La nouvelle version compatible de UAM devrait apparaitre dans la liste des plugins disponibles. Elle ne devrait pas apparaitre dans l'onglet "Rechercher les mises à jour" ni être proposée par Piwigo AutoUpgrade (à confirmer car je ne sais pas comment réagira l'ensemble lorsque la nouvelle archive sera sur PEM).
il apparaitra dans l'onglet mise à jour ce n'est pas géré avec le nom de répertoire mais avec le 'numero' de plugin
la ligne
Plugin URI: http://piwigo.org/ext/extension_view.php?eid=NNN
Oui, je m'en suis aperçu après avoir publié une nouvelle version en RC du plugin pour tester justement ce comportement. Donc, obligation de créer un nouveau répertoire et d'effectuer une copie des fichiers comme tu l'as suggéré. J'ai codé une fonction qui devrait faire la copie de fichiers mais il reste des mises au point à faire car il s'agit de copier des fichiers mais aussi une arborescence de sous-répertoires. Et là, c'est un peu plus compliqué...
Hors ligne
Faire simple, toujours chercher à faire simple :-))
Finalement, pas besoin de créer un nouveau répertoire et de copier le contenu de l'ancien vers le nouveau: La fonction rename() fonctionne et se charge de tout.
Je viens d'effectuer un test en ligne chez Free sur une galerie 2.2.0RC4 avec le plugin UAM en version non compatible mais installé (donc désactivé) et le renommage du dossier NBC_UserAdvManager en UserAdvManager au moment de l'upgrade a parfaitement fonctionné.
J'avais un gros doute par rapport à certaines limitations des hébergeurs mais, a priori, si çà fonctionne chez Free cela doit fonctionner ailleurs ;-)
Merci ddtddt pour ton aide. Je vais pouvoir renommer le dépôt SVN du plugin (en passant par le rename de SVN, bien sûr ^^).
Hors ligne
Super si cela fonctionne :-)
Pour l'aide de rien c'est toi qui a bossé :-D
Hors ligne
Oui mais mon cerveau a la fâcheuse tendance à vouloir se faire des nœuds tout seul. Ton regard extérieur et objectif sur mon problème m'a permis de défaire ces nœuds.
Et çà le vaut bien pour toutes les heures de boulot que j'ai économisé ;-))
Hors ligne
Pages: 1