Bonjour,
Je remets le couvert...
je gère 18 sites mutualisés et à chaque fois que je dois mettre à jour ne serait-ce qu'un plugin, comme le couteau suisse par exemple, utilisé par tous les sites, c'est la croix et la bannière, si j'ose m'exprimer ainsi. Je suis alors obligé de repasser sur *tous* les sites (qui ont de toutes façons planté, me connecter et réactiver le ou les plugins mis à jour qui ont été désactivés.C'est sans doute un bien (?) de séparer les versions des plugins dans /plugin/auto quand le site est seul, mais pour des sites mutualisés, c'est horrible, c'est plus d'une demi heure à chaque fois si on tient compte des lenteurs de l'hébergeur et du réseau, très tôt le matin...
Y a-t-il quelque chose de prévu ? On m'a bien donné dans le passé quelques conseils mais un peu tarabiscotés. Je pense qu'un logiciel du niveau de SPIP devrait proposer une solution simple pour l'utilisateur Lambda (ou presque) qui a vocation à utiliser ce CMS, sinon il ira voir ailleurs...
Des idées ? Du nouveau ?
--
Philippe G.
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
l'utilisateur "lambda" n'est pas concerné par le problème que tu décris et qui touche le plugin de "mutualisation facile" qui nécessite tout de même un niveau de prise en main minimum de SPIP qui concerne les utilisateurs gérant un parc de site (c'est une toute petite frange des utilisateurs).
C'est le concept même de mutualisation que cela interroge, car si tous les dossiers et plugins sont mutualisés, il semble totalement anormal de pouvoir mettre à jour un plugin par l'intermédiaire de l'un des sites, puisque cela ne prend en aucun cas en compte les besoins/contraintes des autres sites qui peuvent casser à tout moment.
J'ai bien compris que le point soulevé est que SVP change le nom du dossier quand on télécharge une mise à jour d'un plugin, et c'est un point qui devrait/pourrait être amélioré.
Cela ne changerai malheureusement pas le problème de fond : si tu fais la mise à jour d'un plugin via un des sites tu casses possiblement tous les autres si jamais le plugin nécessite de recompiler les plugins (ajout/suppression d'un fichier options, fonctions, d'un pipeline) ou de mettre à jour la base.
La mise à jour d'un plugin d'une mutualisation de sites ne devrait donc se faire que par une intervention de haut niveau qui consisterait :
- à mettre à jour le plugin sur le système disque (par svn/download ou ce qu'on veut)
- a déclencher la recompilation des plugins et l'upgrade de base sur chaque site de la mutu
--
Cédric
Philippe G. a écrit :
Bonjour,
Je remets le couvert...
je gère 18 sites mutualisés et à chaque fois que je dois mettre à jour
ne serait-ce qu'un plugin, comme le couteau suisse par exemple, utilisé
par tous les sites, c'est la croix et la bannière, si j'ose m'exprimer
ainsi. Je suis alors obligé de repasser sur *tous* les sites (qui ont de
toutes façons planté, me connecter et réactiver le ou les plugins mis à
jour qui ont été désactivés.C'est sans doute un bien (?) de séparer les
versions des plugins dans /plugin/auto quand le site est seul, mais pour
des sites mutualisés, c'est horrible, c'est plus d'une demi heure à
chaque fois si on tient compte des lenteurs de l'hébergeur et du réseau,
très tôt le matin...
Y a-t-il quelque chose de prévu ? On m'a bien donné dans le passé
quelques conseils mais un peu tarabiscotés. Je pense qu'un logiciel du
niveau de SPIP devrait proposer une solution simple pour l'utilisateur
Lambda (ou presque) qui a vocation à utiliser ce CMS, sinon il ira voir
ailleurs...
Des idées ? Du nouveau ?
La mise à jour d'un plugin d'une mutualisation de sites ne devrait donc se faire que par une intervention de haut niveau qui consisterait :
- à mettre à jour le plugin sur le système disque (par svn/download ou ce qu'on veut)
- a déclencher la recompilation des plugins et l'upgrade de base sur chaque site de la mutu
Si on écrase (par svn/download, ftp ou autre) le plugin précédent sans autre précaution, ça risque de perturber son fonctionnement, non ? Ne faut-il pas le désactiver avant sur tous les sites ?
Ça doit d'ailleurs être le cas même sans mutualisation, si la mise à jour ne peut pas se faire par l'interface de gestion des plugins. Je pense aux hébergeurs qui bloquent les accès externes.
La mise à jour d'un plugin d'une mutualisation de sites ne devrait
donc se faire que par une intervention de haut niveau qui consisterait :
- à mettre à jour le plugin sur le système disque (par svn/download ou
ce qu'on veut)
- a déclencher la recompilation des plugins et l'upgrade de base sur
chaque site de la mutu
Si on écrase (par svn/download, ftp ou autre) le plugin précédent sans
autre précaution, ça risque de perturber son fonctionnement, non ? Ne
faut-il pas le désactiver avant sur tous les sites ?
Ça doit d'ailleurs être le cas même sans mutualisation, si la mise à
jour ne peut pas se faire par l'interface de gestion des plugins. Je
pense aux hébergeurs qui bloquent les accès externes.
S'il existait une option dans SVP qui permette de ne pas supprimer le répertoire actuel du plugin mis à jour (le répertoire qui indique le numéro de version) lors de l'installation de la nouvelle version, ça résoudrait peut être une partie du problème.
Quand deux versions d'un plugin existent localement, la mise à jour manuelle est proposée : la version du plugin est indiquée "obsolète" dans les plugins actifs, et la nouvelle est proposée dans les inactifs.
Ça ne répond pas au problème initial de mettre à jour les plugins sans se connecter à chaque site mutualisé, mais au moins, ils continueraient à utiliser la version non mise à jour sans planter.
La mise à jour d'un plugin d'une mutualisation de sites ne devrait donc
se faire que par une intervention de haut niveau qui consisterait :
- à mettre à jour le plugin sur le système disque (par svn/download ou
ce qu'on veut)
- a déclencher la recompilation des plugins et l'upgrade de base sur
chaque site de la mutu
D'après moi, c'est typiquement une opération qui devrait faire partie des commandes de "spip-cli". Mettre à jour les fichiers d'un plugin, et appeler directement les fonctions d'update du plugin s'il en a.
D'abord une version uni-site, puis la mutualisation pourrait ajouter la même fonctionnalité mais multi-site (qui appelle donc la fonction d'update sur chacun des sites).
S'il existait une option dans SVP qui permette de ne pas supprimer le
répertoire actuel du plugin mis à jour (le répertoire qui indique le
numéro de version) lors de l'installation de la nouvelle version, ça
résoudrait peut être une partie du problème.
je plussoie en ce sens. C'est la raison pour laquelle j'ai renoncé à une mutualisation, sachant que la maj vers svn peut amener vers des versions non stable.
S'il existait une option dans SVP qui permette de ne pas supprimer le
répertoire actuel du plugin mis à jour (le répertoire qui indique le
numéro de version) lors de l'installation de la nouvelle version, ça
résoudrait peut être une partie du problème.
je plussoie en ce sens. C'est la raison pour laquelle j'ai renoncé à une
mutualisation, sachant que la maj vers svn peut amener vers des versions
non stable.
Il y a une modif de SVP qui permet ça, je dois pouvoir la retrouver je
l'avais utilisée sur plusieurs mutualisations.
Il y a aussi la possibilité de faire ça par svn ... complexe ...
Mais j'ai néanmoins abandonné mes mutualisations à cause de ce problème
de plugins et d'autres, trop prise de tête:
- si les dossiers sont conservés, il faut repasser sur chaque site pour
valider le plugin mis à jour
- s'ils ne sont pas conservés et le plugin dévalidé ça devient très
compliqué car quand on arrive sur la gestion des plugins, le plugin
dévalidé est au milieu d'un paquet d'inactifs, difficile de se souvenir
lesquels sont utilisé par ce site (car en général on mets à jour un
paquet de plugins simultanément) ... le plugin Mutu permet apparament de
conserver las liste des plugins actifs pour un site mais je faisais mes
mutu à la main ...
- j'avais aussi essayé de bosser sur les variables qui permettent de
déclarer un dossier plugin pour chaque site avec héritage de plugins
communs, jamais réussi à faire marcher ça correctement
- l'avantage de sites séparés est de permettre des mises à jour plus
étalées que l'on complète une par une, en mutu il faut repasser fissa
sur les 20 sites de la mutu pour tout vérifier
- sans parler des pbms de sites qu'il faut sortir de la mutu pour
d'autres raisons (par ex client qui part ou qui soudainement se sent une
ame de programmeur et veux regarder sous le capot ou qui demande un
accès FTP à son site ...)
Bref les mutus qui devaient me faire gagner du temps m'en ont tellement
fait perdre que j'ai fini par arrêter (et j'avais au moins 30 sites dans
des mutus).
Je pense réutiliser ça pour des cas spéciaux (par ex un client avec 2 ou
3 sites à lui).
Mais j'ai néanmoins abandonné mes mutualisations à cause de ce problème
de plugins et d'autres, trop prise de tête:
- si les dossiers sont conservés, il faut repasser sur chaque site pour
valider le plugin mis à jour
Ben... quand tu as plusieurs sites indépendants il faut aussi valider les plugins sur chaque site, en plus de faire les mises à jour (Spip compris) sur chaque...
- l'avantage de sites séparés est de permettre des mises à jour plus
étalées que l'on complète une par une, en mutu il faut repasser fissa
sur les 20 sites de la mutu pour tout vérifier
Le commit-août de cet été et les récents piratages m'ont incité à rafraîchir tous mes sites sous Spip, qui étaient dans des versions diverses et variées. Certes j'ai repris chaque site séparément, mais s'il avait fallu d'abord mettre à jour les plugins ça n'aurait pas vraiment posé de problème. Comme j'ai beaucoup de plugins communs, la recherche des dernières versions était facilitée.
Le plus laborieux, c'était de faire les sauvegardes de chaque site avant mise à jour.
Pour moi le plus laborieux est, pour un upgrade de spip,
de devoir créer un sous répertoire de tmp
dans chacun des sites de la mutu
pour m'authentifier pour la mise à jour de la BDD.
Et si on essayait plutôt de modifier le plugin « Mutualisation » pour lancer un script d’update de la BDD de chaque site quand il détecte qu’un plugin a été mis à jour ?
Oui, si SVP permettait d’avoir plusieurs versions d’un même plugin, ça aiderait… Mais on parle aussi ici du plugin « Mutualisation facile »… Autant le modifier lui aussi.
Pour moi le plus laborieux est, pour un upgrade de spip,
de devoir créer un sous répertoire de tmp
dans chacun des sites de la mutu
pour m'authentifier pour la mise à jour de la BDD.
S'il existait une option dans SVP qui permette de ne pas supprimer le
répertoire actuel du plugin mis à jour (le répertoire qui indique le
numéro de version) lors de l'installation de la nouvelle version, ça
résoudrait peut être une partie du problème.
Quand deux versions d'un plugin existent localement, la mise à jour
manuelle est proposée : la version du plugin est indiquée "obsolète"
dans les plugins actifs, et la nouvelle est proposée dans les inactifs.
Je gère ma mutu sans problème, si je mets à jour un plugin dans un site par SVP, ça ne plante rien dans les autres.
J'ai même mis à jour le plugin Mutualisation pour lister toutes les versions de plugins non utilisés.
Quand j'ai proposé de mettre sur la zone, on m'a demandé de placer auparavant des "jalons" que je ne savais pas faire...
On peut évoluer encore beaucoup : supprimer automatiquement les plugins non utilisés, ...
Ça ne répond pas au problème initial de mettre à jour les plugins sans
se connecter à chaque site mutualisé, mais au moins, ils continueraient
à utiliser la version non mise à jour sans planter.
Pour mettre à jour tous les sites automatiquement, c'est autre chose. Cet automatisme me paraît plus risqué.