Je voudrais bien que tous mes plugins soient à jour !
Or il se trouve que mon "designer" a mis les plugins dont il avait
besoin dans plugins-dist (et même pour certain dans un sous-dossier du
sus-dit).
Du coup, ils sont verrouillés (normal), mais ne se mettent pas à jour,
ni automatiquement (ce qu'ils devraient faire ?) ni manuellement (je
n'ai pas la main, bien que webmestre.
La copie brutale du code des plugins n'est pas une bonne solution, les
mise à jour des tables semblant du coup ne pas se faire...
Une solution, autre que les délacer à la main dans plugins/auto ?
Francois Sauterey (Perso) a écrit le 29/05/2018 à 16:43 :
Je voudrais bien que tous mes plugins soient à jour !
Or il se trouve que mon "designer" a mis les plugins dont il avait
besoin dans plugins-dist (et même pour certain dans un sous-dossier du
sus-dit).
Du coup, ils sont verrouillés (normal), mais ne se mettent pas à jour,
ni automatiquement (ce qu'ils devraient faire ?) ni manuellement (je
n'ai pas la main, bien que webmestre.
La copie brutale du code des plugins n'est pas une bonne solution, les
mise à jour des tables semblant du coup ne pas se faire...
Une solution, autre que les délacer à la main dans plugins/auto ?
Quand ils sont installés dans plugins-dist/ ils devraient l'être via SSH avec SVN.
Ce qui permet leur mise à jour assez simplement en ligne de commande.
Si tu n'as pas ces accès, le designer aurait dû mettre en place une maintenance technique en plus. L'a-t'il fait ?
Ceci dit, le déplacement des plugins dans plugins/ (sans descendre dans auto/) va permettre leur mise à jour via SVP.
Et une fois la mise à jour faite, les plugins à la racine de plugins/ pourront être effacés.
Des solutions t'ont été données mais le plus "propre" à mon sens serait de rétablir la structure normale de SPIP, en réservant plugins-dist aux plugins de la dist, comme son nom l'indique. Déplacer ces plugins à la main dans plugins/auto n'est pas très compliqué (un dossier par plugin) et ensuite tu n'as plus à t'en faire.
CM
Le 29/05/2018 à 16:43, Francois Sauterey (Perso) a écrit :
Une solution, autre que les délacer à la main dans plugins/auto ?
Le 29/05/2018 à 16:43, Francois Sauterey (Perso) a écrit :
Du coup, ils sont verrouillés (normal), mais ne se mettent pas à jour,
ni automatiquement (ce qu'ils devraient faire ?) ni manuellement (je
n'ai pas la main, bien que webmestre.
Merci a tous ceux qui m'ont répondu... sans résoudre complètement mon
problème.
D'où deux nouvelles questions liées :
1) Les plugins-dist ne se mettent-ils pas à jour automatiquement ? Si
oui, pourquoi les miens ne le font-ils pas ?
Sinon, quel est le processus pour les mettre à jour ???
2) la mise à jour via SVN, provoque-t-elle la mise à jour des tables, si
nécessaire ?
Le 30/05/2018 à 09:36, Francois Sauterey (Perso) a écrit :
Le 29/05/2018 à 16:43, Francois Sauterey (Perso) a écrit :
Du coup, ils sont verrouillés (normal), mais ne se mettent pas à jour,
ni automatiquement (ce qu'ils devraient faire ?) ni manuellement (je
n'ai pas la main, bien que webmestre.
Merci a tous ceux qui m'ont répondu... sans résoudre complètement mon
problème.
D'où deux nouvelles questions liées :
1) Les plugins-dist ne se mettent-ils pas à jour automatiquement ?
Non.
- SVP ne sait (volontairement) gérer que les plugins de plugins/auto
- spip_loader.php ne met à jour que les fichiers distribués avec SPIP (donc ses plugins-dist, mais pas ceux ajoutés dedans).
Si
oui, pourquoi les miens ne le font-ils pas ?
Sinon, quel est le processus pour les mettre à jour ???
Ce n’est pas forcément une mauvaise manière d’ajouter d’autres plugins dans plugins-dist. Mais c’est effectivement plus facile de gérer leurs mises à jour en SVN (ou GIT selon les plugins) du coup. Car ils ne pourront être mis à jour depuis l’interface web. Par FTP cela fonctionne aussi, il faut juste penser à enlever les anciens fichiers !
2) la mise à jour via SVN, provoque-t-elle la mise à jour des tables, si
nécessaire ?
Ce qui provoque la mise à jour des tables est la modification du fichier paquet.xml (lorsque l’entrée 'schema' augmente), et le passage sur la page de gestion des plugins. Quelque soit la méthode cela se fera si ces conditions sont réunies.
Si des mises à jour de certains plugins ne se sont pas faites correctement alors qu’elles auraient du (ce que tu sembles dire), tu peux tenter de modifier la version du schema de ce plugin dans la table spip_meta (les {prefix}_version_base ), qui indiquent à quelle version la BDD est de ce plugin. Si tu supprimes l’entrée, le plugin se réinstallera (c’est peut être pas la meilleure idée) ; si tu modifies la version (par exemple mettre 1.1.0 à la place de 1.5.0), les mises à jour intermédiaires se relanceront pour ce plugin.
Le 30/05/2018 à 09:36, Francois Sauterey (Perso) a écrit :
1) Les plugins-dist ne se mettent-ils pas à jour automatiquement ? Si
oui, pourquoi les miens ne le font-ils pas ?
Sinon, quel est le processus pour les mettre à jour ???
Je complète les indications reçues :
Les plugin-dist sont associés à la "dist", c'est à dire l'ensemble de ressources SPIP
distribuées et validées ENSEMBLE.
SPIP ne prévoit pas de mettre à jour les plugins-dist
si tu ne changes pas la version du noyau
justement pour être certain que tout ce qui est livré (dist-ribué par SPIP de base)
marche toujours bien ensemble.
Par contre, SPIP met à jour les plugins-dist
si tu met à jour le noyau (SPIP 3.1 ou autre)
notamment avec le spip_loader.
Le 30/05/2018 à 09:54, Matthieu Marcillaud a écrit :
Ce qui provoque la mise à jour des tables est la modification du fichier paquet.xml (lorsque l’entrée 'schema' augmente), et le passage sur la page de gestion des plugins. Quelque soit la méthode cela se fera si ces conditions sont réunies.
Pourquoi la mise à jour de la base, pour ce qui concerne les seuls plugins de la dist, nécessite-t'elle un passage sur la page de gestion des plugins ?
Le 30/05/2018 à 09:54, Matthieu Marcillaud a écrit :
Ce qui provoque la mise à jour des tables est la modification du fichier paquet.xml (lorsque l’entrée 'schema' augmente), et le passage sur la page de gestion des plugins. Quelque soit la méthode cela se fera si ces conditions sont réunies.
Pourquoi la mise à jour de la base, pour ce qui concerne les seuls plugins de la dist, nécessite-t'elle un passage sur la page de gestion des plugins ?
Parce que le code qui vérifie si les plugins présents sur le disque sont
d'un n° de version différent de celui enregistré en base (spip_meta) n'est exécuté
que lorsqu'on va dans la page de gestion des plugins.
Le 29/05/2018 à 16:43, Francois Sauterey (Perso) a écrit :
Je voudrais bien que tous mes plugins soient à jour !
Or il se trouve que mon "designer" a mis les plugins dont il avait
besoin dans plugins-dist (et même pour certain dans un sous-dossier du
sus-dit).
Du coup, ils sont verrouillés (normal), mais ne se mettent pas à jour,
ni automatiquement (ce qu'ils devraient faire ?) ni manuellement (je
n'ai pas la main, bien que webmestre.
La copie brutale du code des plugins n'est pas une bonne solution, les
mise à jour des tables semblant du coup ne pas se faire...
Une solution, autre que les délacer à la main dans plugins/auto ?
Ce "designer" dont tu parles, c'est la personne qui t'a vendu le site ?
La vraie question, c'est pourquoi mettre des plugins autres que dist dans plugins-dist ?
Pour qu'on ne puisse pas les désinstaller ?
Comme on le voit, ce n'est pas une bonne idée, ce n'est pas conçu pour et il y a des effets de bord.
Le mieux pour ça serait de gérer des <necessite>, par exemple avec un meta plugin qui ne contient qu'un paquet.xml et des necessite, mais bon, si ça n'a pas été conçu comme ça, autant les déplacer dans /plugins/auto et faire attention à ne pas les désinstaller.
Pourquoi la mise à jour de la base, pour ce qui concerne les seuls plugins de la dist, nécessite-t'elle un passage sur la page de gestion des plugins ?
Parce que le code qui vérifie si les plugins présents sur le disque sont
d'un n° de version différent de celui enregistré en base (spip_meta) n'est exécuté
que lorsqu'on va dans la page de gestion des plugins.
De tous les plugins d'ailleurs, pas que de la dist.
Ce qui peut occasionner des erreurs Mysql dans les squelettes si le schéma de la base n'est pas à jour.
Le 30/05/2018 à 09:54, Matthieu Marcillaud a écrit :
Ce qui provoque la mise à jour des tables est la modification du fichier paquet.xml (lorsque l’entrée 'schema' augmente), et le passage sur la page de gestion des plugins. Quelque soit la méthode cela se fera si ces conditions sont réunies.
Pourquoi la mise à jour de la base, pour ce qui concerne les seuls plugins de la dist, nécessite-t'elle un passage sur la page de gestion des plugins ?
Parce que le code qui vérifie si les plugins présents sur le disque sont
d'un n° de version différent de celui enregistré en base (spip_meta) n'est exécuté
que lorsqu'on va dans la page de gestion des plugins.
CQFD
Oui, ça je l'avais bien compris, j'ai été surpris de le constater lors d'une mise à jour récente. Ma question ici était mal formulée. Je me demandais pourquoi avoir fait le process ainsi ? Pourquoi ne pas avoir prévu cela plutôt lors de l'accès à ecrire avec un flag inscrit en bdd pour ne le faire qu'une fois après une maj de noyau ?
Je dis ça car dans mon cas perso, lorsque je mets à jour plus d'une centaine de sites où je suis le seul webmestre et sur chacun ensuite administre des admins restreints, qui n'ont pas accès à la page de gestion des plugins (et je ne souhaite pas qu'ils l'aient non plus), je ne garde que les dossiers img et config de chacun, balance les fichiers de la nouvelle version par script sur chacun, vide les caches par suppression de fichiers en scripts, et m'y connecte en admin sur /ecrire en cas de process de maj de base requis. Je ne comprends la contrainte de devoir passer en plus par /ecrire/?exec=admin_plugin pour finaliser l'update.
Je me disais que pour ce qui est des plugins d'une dist, ce serait bien si on pouvait se dispenser de cette étape supplémentaire, compte tenu qu'il s'agit du contexte de la dist. Ou au moins faire un cron ?
Pourquoi la mise à jour de la base, pour ce qui concerne les seuls plugins de la dist, nécessite-t'elle un passage sur la page de gestion des plugins ?
Parce que le code qui vérifie si les plugins présents sur le disque sont
d'un n° de version différent de celui enregistré en base (spip_meta) n'est exécuté
que lorsqu'on va dans la page de gestion des plugins.
De tous les plugins d'ailleurs, pas que de la dist.
Ce qui peut occasionner des erreurs Mysql dans les squelettes si le schéma de la base n'est pas à jour.
C'était un peu l'objet de ma question. Lors d'une mise à jour de la dist, cela oblige même celui qui n'utilise que les plugins de la dist à faire un tour sur la page de gestion des plugins (cette contrainte est-elle d'ailleurs indiquée/documentée car je n'ai pas souvenir de l'avoir vu avant de l'avoir expérimentée ?). Ne serait-il pas intéressant de distinguer les plugins dist des autres dans le processus de mise à jour de la base, et d'inclure ces verifs de version en base en même temps que les verifs des autres tables, donc avec l'accès sur /ecrire ?
Votre histoire me rappelle les phénomènes courants à l'époque des
premières versions de SPIP. Il n'y avait pas de multiliguismes, alors
chacun bricolait ce qu'il lui fallait. Il n'y avait pas de plugins,
alors chacun modifiait son code php sans vraiment comprendre ce qu'il
faisait.
Tout sautait lors de la prochaine mise à jour de SPIP.
Avec l'arrivée officielle du multilinguisme, avec le nouveau noyau écrit
per Emmanuel et avec l'introduction des plugins on s'est libéré de tous
ces problèmes. D'abord ce fut une économie en temps de vie passé avec du
debugging et ce fut le début du SPIP flexible et stable qu'on connaît
aujourd'hui.
Je suis d'accord pour que chacun décide sur sa propre manière
"d'apprendre SPIP" - ce qui est totalement possible vu l'architecture
claire et simple de la base de SPIP. Par contre une fois qu'on passe au
stade professionnel on est obligé de lire et de comprendre la doc et de
suivre les conseils de la communauté.
En prenant un raccourci par des chemins de traverse pour éviter l'étude
des documents de base on se retrouve forcément avec du code superflu et
des modifications douteuses de SPIP. Ce que je trouve le pus grave c'est
qu'on passe à côté de la découvertes des réflexions des contributeurs
qui on élaboré des solutions de plus en plus performantes.
:-)k++
On 30.05.2018 23:03, Francois Sauterey (Perso) wrote:
Le 30/05/2018 à 19:21, nicod_ a écrit :
Ce "designer" dont tu parles, c'est la personne qui t'a vendu le site ?
Exactement...
Bon j'ai pris les plugins un à un fais les mise à jour via svn, ça à
l'air de fonctionner
Merci pour tout
Merci à tous
@ la prochaine
Francois
_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net