Piwigo.org

binaryworld · 2011-03-26 19:01:10

Bonjour,

J'aimerais avoir plus d'information sur ce qu'il faut faire pour bien gérer la mise à jour d'un plugin.

Notamment, je me demande s'il faut faire quelque chose de particulier dans un plugin pour gérer le cas ou un utilisateur mets à jour sa version de Piwigo.

J'aimerais aussi savoir s'il est possible de gérer la mise à jour du plugin lorsque l'utilisateur utilise la console d'administration de Piwigo. Par exemple, si je souhaite permettre de migrer les données de configuration de l'utilisateur lors de la mise à jour, est qu'il y a une fonction ou une interface à implémenter dans le plugin ?
Lors de la mise a jour, est ce que tous les anciens fichiers sont forcément supprimés et remplacés par la nouvelle structure de fichier ?

Je me pose aussi les même questions lorsque l'utilisateur demande une nouvelle installation plutôt que de passer par la mise à jour.

J'ai cherché mais je n'ai rien trouvé sur le wiki. Est qu'il existe un guide sur le sujet (francais ou anglais) ?

Edite
Arf! j'aurai du attendre vos réponses.
J'ai fait une nouvelle version du plugin. J'ai déplacé certain de mes répertoires et renommé un fichier. Après une mise à jour les nouveaux fichiers (fichier déplacé) sont bien installé mais les anciens sont toujours là :(.
Donc nouvelle question: comment je peux supprimer les répertoires et fichiers lors d'une mise à jour ?

Merci,
Vincent.

Dernière modification par binaryworld (2011-03-26 19:27:05)

Eric · 2011-03-26 19:25:38

binaryworld a écrit:
Bonjour,

J'aimerais avoir plus d'information sur ce qu'il faut faire pour bien gérer la mise à jour d'un plugin.

Notamment, je me demande s'il faut faire quelque chose de particulier dans un plugin pour gérer le cas ou un utilisateur mets à jour sa version de Piwigo.

Oui, le plugin doit gérer lui-même toutes les actions nécessaires à sa mise à jour. Par exemple, si une mise à jour nécessite une modification des données propres au plugin en base de données, il faudra le gérer.

Grosso modo, la mise à jour de plugin par l'interface de gestion de Piwigo se passe ainsi:
1- Désactivation du plugin en version v-1
2- Décompression des fichiers de la version v dans le dossier d'installation du plugin
3- Activation du plugin

C'est à la phase 3, qu'il conviendra de gérer les éventuelles actions de mise à jour sur les fichiers ou les données en base.

binaryworld a écrit:
J'aimerais aussi savoir s'il est possible de gérer la mise à jour du plugin lorsque l'utilisateur utilise la console d'administration de Piwigo. Par exemple, si je souhaite permettre de migrer les données de configuration de l'utilisateur lors de la mise à jour, est qu'il y a une fonction ou une interface à implémenter dans le plugin ?

Si une mise à jour d'un plugin nécessite une intervention manuelle de l'admin qui réalise la mise à jour, il faudra implémenter une interface pour cela. Perso, je n'ai jamais fait mais çà doit être faisable.

binaryworld a écrit:
Lors de la mise a jour, est ce que tous les anciens fichiers sont forcément supprimés et remplacés par la nouvelle structure de fichier ?

Non, une mise à jour de fichier d'un plugin (dans le cas d'une mise à jour automatique via l'interface de gestion des plugins) se comporte comme si on décompressait une archive dans un dossier. Les fichiers présents dans le dossier de destination et pas dans l'archive sont conservés et ceux présents dans le dossier et dans l'archive sont écrasés par ceux de l'archive.

Il existe une méthode pour nettoyer des fichiers rendus obsolètes d'une version d'un plugin à une autre.

binaryworld a écrit:
Je me pose aussi les même questions lorsque l'utilisateur demande une nouvelle installation plutôt que de passer par la mise à jour.

Une nouvelle installation nécessitera la désinstallation de la version précédente et, par conséquent, la perte de données propres au plugin éventuellement stockées en base de données. Sauf si on gère dans le processus d'installation la présence ou non de données. C'est faisable aussi mais c'est plus lourd.

binaryworld · 2011-03-26 19:38:44

Merci Eric pour tes réponses.
J'ai édité mon 1er poste pendant que tu devais écrire le tiens.

Eric a écrit:
C'est à la phase 3, qu'il conviendra de gérer les éventuelles actions de mise à jour sur les fichiers ou les données en base.

Comment ? Il y a un moyen de gérer les phases de mise à jour du plugin ?

Eric a écrit:
Il existe une méthode pour nettoyer des fichiers rendus obsolètes d'une version d'un plugin à une autre.

Laquelle ?
De plus, comme je m'y suis pris comme un pied, il faut que je le fasse dans une nouvelle version.
Donc du coup nouvelle question: comment garantir une mise à jour correct si la mise à jour est par exemple entre une version 0.1.7 et 0.1.9 ou plus? Il faut que le plugin sache mettre à jour toutes ses anciennes versions ?

Eric a écrit:
Une nouvelle installation nécessitera la désinstallation de la version précédente et, par conséquent, la perte de données propres au plugin éventuellement stockées en base de données. Sauf si on gère dans le processus d'installation la présence ou non de données. C'est faisable aussi mais c'est plus lourd.

Comment le plugin est 'au courant" qu'il est en train de s'installer ?

Est ce qu'il existe un plugin qui pourrait me servir d'exemple ?

Merci,
Vincent.

Dernière modification par binaryworld (2011-03-26 19:40:31)

mistic100 · 2011-03-26 19:57:32

tu peux regarde n'importe quel plugin (presque) ^^
dans le fichier maintain.inc.php il y a les trois phases : installation/activation/désinstallation chacune gérée par une fonction

pour les fichier à supprimer c'est avec le fichier obsolete.list non ? (d'ailleurs il faudrait que j'en ajoute un sur les plugins que j'ai récupéré...)

Dernière modification par mistic100 (2011-03-26 19:58:54)

binaryworld · 2011-03-26 20:27:10

Merci mistic100.

mistic100 a écrit:
dans le fichier maintain.inc.php il y a les trois phases : installation/activation/désinstallation chacune gérée par une fonction

Bon avec tes mots clefs, j'ai trouvé ca : sur le wiki anglais.
Ça va m'aider pour creuser un peu plus le truc.

mistic100 a écrit:
pour les fichier à supprimer c'est avec le fichier obsolete.list non ? (d'ailleurs il faudrait que j'en ajoute un sur les plugins que j'ai récupéré...)

[strike]Il faut que j'ajoute un fichier nommé 'obsolete.list' dans le répertoire de mon plugin avec la liste des fichiers que je souhaite voir supprimés pendant l'installation ?
Cela fonctionne aussi avec des noms de répertoire ?[/strike]

Edit
Ok j'ai trouve dans le code de Piwigo => C'est bien obsolete.list et cela fonctionne aussi avec les répertoires.

Merci,
Vincent.

Dernière modification par binaryworld (2011-03-26 20:55:13)

flop25 · 2011-03-26 22:08:52

obsolete.list est générée automatiquement

plg · 2011-03-26 23:13:01

Idéalement, un plugin devrait pratiquer l'auto-upgrade, je veux dire sans obligatoirement passer par le plugin_activate du fichier maintain.inc.php.

Pourquoi ? parce que tout le monde n'utilise pas (ne peut pas utiliser) le système de mise à jour automatique proposé sur l'écran [Administration > Plugins > Gérer > Mise à jour] (c'est pour cela qu'il y a un lien "télécharger"), donc tout le monde ne va pas forcément repasser par plugin_activate() au moment de la mise à jour des fichiers.

Le principe de l'auto-upgrade commence à être implémenté dans certains plugins, comme [extension by P@t] Additional Pages : dans main.inc.php (donc appelé à chaque page, même côté galerie), P@t à écrit:

Code:

// Need upgrade?
if (!isset($conf['AP']['language_perm']))
  include(AP_PATH.'admin/upgrade.inc.php');

et le fichier admin/upgrade.inc.php détecte indirectement la version en cours niveau modèle de données et le met à jour en conséquence.

Pour le moment, tout comme pour le core, Piwigo ne stocke pas sa version dans la base de données (ne vous fiez pas à piwigo_plugins.version, ce n'est pas mis à jour, c'est la version du plugin lors de sa première installation), donc on est obligé de "deviner" en étudiant la liste des colonnes par exemple. Mais rien n'empêche d'écrire la version de son plugin dans la table piwigo_config, ce qui simplifiera énormément la détection pour savoir quelles changements appliquer au modèle de données.

binaryworld · 2011-03-27 12:00:46

flop25 a écrit:
obsolete.list est générée automatiquement

J'imagine que le fichier est généré automatiquement si le plugin et dans le dépôt SVN ?
J'avais fait la demande mais comme il y a eu un petit problème avec la license d'une librairie que j'embarqué dans mon plugin (enlevé depuis), je ne sais pas trop dans quel état est le status de ma demande.
Je n'ai plus l'icône (nuage) pour faire la demande mais sur la page de configuration SVN du plugin [extension by binaryworld] Shadogo le message suivant est affiché: "Impossible de récupérer les données SVN!"

Edité:
Je ne comprends plus. J'ai ajouté le fichier obsolete.list dans mon archive zip avec le nom des fichiers que je souhaite voir supprimés après la mise à jour du plugin. J'ai fait un test en local et cela fonctionne. Par contre cela ne fonctionne pas sur mon serveur quand l'archive est téléchargée depuis votre site.

plg a écrit:
Le principe de l'auto-upgrade commence à être implémenté dans certains plugins, comme [extension by P@t] Additional Pages

Je vais regarder.
Toutefois, je ne suis pas certain de comprendre alors la différence entre une mise à jour et une installation.
Je souhaiterais garder la possibilité de re-faire (forcer) une installation même si cela implique de perdre les données du plugin. Pour moi, une mise à jour et une réinstallation devrait être un choix assumé de l'utilisateur. Il faut juste l'avertir correctement.

plg a écrit:
Mais rien n'empêche d'écrire la version de son plugin dans la table piwigo_config

Je n'aime pas trop l'idée de devoir saisir la version du plugin à plusieurs endroits.
N'est il pas possible d'utiliser la version dans le fichier main.inc.php. Ce n'est pas cette version qui est utilisée par le gestionnaire de plugin de Piwigo? Pourquoi ne pas ouvrire l'interface d'une gestionnaire de plugin pour permettre de retrouver la version d'un plugin ?

Merci,
Vincent.

Dernière modification par binaryworld (2011-03-27 20:04:43)

plg · 2011-03-28 16:08:09

binaryworld a écrit:
J'avais fait la demande mais comme il y a eu un petit problème avec la license d'une librairie que j'embarqué dans mon plugin (enlevé depuis), je ne sais pas trop dans quel état est le status de ma demande.

Voilà c'est bon, tu as dû recevoir un email avec tes identifiants.

binaryworld a écrit:
Je souhaiterais garder la possibilité de re-faire (forcer) une installation même si cela implique de perdre les données du plugin. Pour moi, une mise à jour et une réinstallation devrait être un choix assumé de l'utilisateur. Il faut juste l'avertir correctement.

Tu te contredis ou alors je ne comprends pas ce que tu veux dire. Moi je trouve ça normal de vouloir sous certaines conditions forcer la réinstallation (donc perte potentielle des paramètres de configuration), cela peut se justifier et sur un un plugin comme Piwishadow, les pertes ne sont pas grandes (par contre sur un Additional Pages, oula la la, il faudrait vraiment un truc grave pour forcer la réinstallation, sachant que l'utilisateur a peut-être passé des heures à créer ses pages).

binaryworld a écrit:
plg a écrit:
Mais rien n'empêche d'écrire la version de son plugin dans la table piwigo_config
Je n'aime pas trop l'idée de devoir saisir la version du plugin à plusieurs endroits.
N'est il pas possible d'utiliser la version dans le fichier main.inc.php. Ce n'est pas cette version qui est utilisée par le gestionnaire de plugin de Piwigo? Pourquoi ne pas ouvrire l'interface d'une gestionnaire de plugin pour permettre de retrouver la version d'un plugin ?

Je te laisse faire quelques essais et mener ta réflexion. Tu verras que ce que tu dis n'a pas de sens :-) (c'est pas super simple donc c'est normal de s'emmêler les pinceaux entre la version des fichiers et la version du modèle de données)

binaryworld · 2011-03-28 20:59:28

plg a écrit:
Voilà c'est bon, tu as dû recevoir un email avec tes identifiants.

Merci :D

Edité: Arf! snniff! il faut que je change le nom de mon plugin car il y aurait des problèmes juridiques pour son utilisation :(

plg a écrit:
Tu te contredis ou alors je ne comprends pas ce que tu veux dire.

Je pense que je ne suis pas assez claire dans mes explications car ce qui est certain c'est que je ne me contredis pas ;). L'autre raison possible c'est que j'ai mal compris ta proposition avec la mise à jour automatique (je n'ai pas encore eu le temps de creuser la solution de P@t :().

Pour moi, l'idée de faire une mise à jour automatique, est de détecter automatiquement dans le plugin la présence ou non d'une ancienne version du plugin et de faire une mise à jour ou une installe de façon automatique sans faire intervenir l'utilisateur.

Hors mon besoin serait de proposer la mise à jour seulement si c'est possible. Il faut juste que l'option soit disponible ou non dans piwigo. Pour savoir, si la mise à jour est possible, Piwigo peut vérifier si le plugin est déjà installé et lui demander s'il supporte la mise à jour.

Donc en gros, je verrais bien 3 propositions dans l'onglet de mise à jour : "Mise à jour" /
"Re-installation" / "Télécharger le fichier"
"Mise à jour" ne sera ajouté par Piwigo que si le plugin la supporte. Et si l'utilisateur clique sur Re-installation alors que Mise à jour est disponible je verrais bien un message de confirmation pour prévenir que dans ce cas il perdra ses données de configuration et l'ensemble du répertoire est remplacé par le contenu de l'archive.

Au final, c'est l'utilisateur qui choisi ce qu'il veut vraiment.
En tout cas, je te remercie pour le temps que tu passes à me répondre.

Pour l'instant, j'ai opté pour une solution basée sur maintain.inc.php et l'implémentation de la fonction plugin_activate. 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. Lors de l'activation de la nouvelle version du plugin je mets à jour la configuration par défaut avec la configuration utilisateur (créé avec la version précédente du plugin). Le code est complètement générique et peut être réutilisé pour d'autre plugin.

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.

Reste que j'aimerais pouvoir gérer les données de configuration en cache mais cela est un autre sujet ;).

Il me reste encore un point que je n'ai pas résolu; c'est la suppression des fichiers obsolètes. J'ai ajouté le fichier obsolete.list directement dans l'archive du plugin mais il semble que cela ne fonctionne pas :(. Je pense ajouter du code dans la fonction plugin_activate mais j'aurais voulu utiliser des mécanismes existant si possible.

Vincent.

Dernière modification par binaryworld (2011-03-28 21:14:12)

plg · 2011-03-28 21:51:40

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.

binaryworld · 2011-03-28 23:30:37

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.

Dernière modification par binaryworld (2011-03-28 23:42:31)

P@t · 2011-03-28 23:59:41

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...

binaryworld · 2011-03-29 00:18:58

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.

P@t · 2011-03-29 01:19:57

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().

Piwigo.org

Annonce

#1 2011-03-26 19:01:10

Comment bien gérer la mise à jour d'un plugin ?

#2 2011-03-26 19:25:38

Re: Comment bien gérer la mise à jour d'un plugin ?

binaryworld a écrit:

binaryworld a écrit:

binaryworld a écrit:

binaryworld a écrit:

#3 2011-03-26 19:38:44

Re: Comment bien gérer la mise à jour d'un plugin ?

Eric a écrit:

Eric a écrit:

Eric a écrit:

#4 2011-03-26 19:57:32

Re: Comment bien gérer la mise à jour d'un plugin ?

#5 2011-03-26 20:27:10

Re: Comment bien gérer la mise à jour d'un plugin ?

mistic100 a écrit:

mistic100 a écrit:

#6 2011-03-26 22:08:52

Re: Comment bien gérer la mise à jour d'un plugin ?

#7 2011-03-26 23:13:01

Re: Comment bien gérer la mise à jour d'un plugin ?

Code:

#8 2011-03-27 12:00:46

Re: Comment bien gérer la mise à jour d'un plugin ?

flop25 a écrit:

plg a écrit:

plg a écrit:

#9 2011-03-28 16:08:09

Re: Comment bien gérer la mise à jour d'un plugin ?

binaryworld a écrit:

binaryworld a écrit:

binaryworld a écrit:

plg a écrit:

#10 2011-03-28 20:59:28

Re: Comment bien gérer la mise à jour d'un plugin ?

plg a écrit:

plg a écrit:

#11 2011-03-28 21:51:40

Re: Comment bien gérer la mise à jour d'un plugin ?

binaryworld a écrit:

binaryworld a écrit:

#12 2011-03-28 23:30:37

Re: Comment bien gérer la mise à jour d'un plugin ?

plg a écrit:

plg a écrit:

#13 2011-03-28 23:59:41

Re: Comment bien gérer la mise à jour d'un plugin ?

binaryworld a écrit:

binaryworld a écrit:

binaryworld a écrit:

binaryworld a écrit:

#14 2011-03-29 00:18:58

Re: Comment bien gérer la mise à jour d'un plugin ?

P@t a écrit:

#15 2011-03-29 01:19:57

Re: Comment bien gérer la mise à jour d'un plugin ?

binaryworld a écrit:

binaryworld a écrit:

Pied de page des forums