[spip-dev] Amélioration spip_loader

Dev
1

Suite à une discussion sur IRC, b_b faisait remarquer que spip_loader ne supprimait pas les anciens fichiers et qu'on pouvait se retrouver avec un vieux fichier qui met la zone.

Pour ma part, je suis totalement adepte de spip_loader, que je trouve très efficace et très sécurisé (pas de risque d'erreur de transfert FTP).
C'est en plus un outil très simple à utiliser, surtout pour des utilisateurs débutants (même si il me semble qu'il n'est pas assez connu).

spip_loader + mise à jour auto des tables, je ne connais pas d'autres CMS ou applis web qui aient une procédure de mise à jour aussi simple et fiable, c'est vraiment un très gros point fort.
J'ai fait des mises à jour dans tous les sens, de 1.9 à 3 directement, c'est magique.

Le problème soulevé par b_b peut être facilement réglé en renommant ses répertoires dist (ecrire, plugins-dist, squelettes-dist, prive, d'autres ?), avec un suffixe _n°version, par exemple, pour pouvoir ensuite les supprimer manuellement.

Cette opération de renommage pourrait être intégrée à spip_loader, peut être sur option ?

Si ce problème d'anciens fichiers était résolu de façon magique, SPIP aurait un outil que beaucoup lui envieraient.

Mais il y a peut être des arguments contre.
Qu'en pensez vous ?

2

Bonjour,

J'ai la meme perception et pratique : les deux seuls soucis rencontrés peuvent venir, de la m-à-j de plugins, et parfois de l'authetification (avec la page blanche dans ecrire ) ; je rajouterais bien -pour pallier certains problèmes dans ce cas- de vider les cache lorsque spip_loader rencontre une mise-à-jour de version, voire aussi de faire d'abord un rename/mv complet de la structure des programmes pour pouvoir conserver l'ancienne version ?

Un autre "problème" de Spip-loader (implicitement soulevé dans la documentation l'accompagnant),
c'est que selon son paramétrage natif, il peut éventuellement provoquer un "saut de version" non volontaire,
et comme le retour en SPIP 2.x est impossible a partir d'une V3 (avec les nombreux pbs mineurs qui l'accompagnaient au début), cela pouvait faire désordre..... j'avais d'ailleurs proposé une première amélioration https://spippourlesnuls.fr/?spip_loader,184qui semble n'avoir jamais intéressé; personnellement j'utilise cette version patchée depuis près d'un an sur tous mes sites (SPIP 2 et SPIP 3 ).

Enfin, peut-ete qu'un complement de documentation un peu plus technique serait utile, pour les utilisateurs intermédiaires,
sur ce qu'execute réellement spip_loader (selon le cookie de connexion par exemple), et ses consequences, car il a aussi été fait état de difficultés lors de montées de versions (perte des auteurs, ou des liens ; tables XXX temporaires non effacées), mais cela ne releve plus strictement de spip_loader.

+1

3

2013/8/13 YannX SPIP <yannx.spip@hotmail.fr>

spip_loader + mise à jour auto des tables, je ne connais pas d’autres CMS ou applis web qui aient une procédure de mise à jour aussi simple et fiable, c’est vraiment un très gros point fort.

Je trouve la mise à jour automatique de Wordpress beaucoup plus intuitive.
S’il y a des mises à jour à faire, c’est mieux mis en avant que dans SPIP - et ça prévient/gère les plugin et wordpress lui-même (ce qui me semble assez fort vu qu’on n’y voit « que du feu ») ← C’est cet aspect transparent et stable qui peut être amélioré dans SPIP

J’ai la meme perception et pratique : les deux seuls soucis rencontrés peuvent venir, de la m-à-j de plugins, et parfois de l’authetification (avec la page blanche dans ecrire ) ; je rajouterais bien -pour pallier certains problèmes dans ce cas- de vider les cache lorsque spip_loader rencontre une mise-à-jour de version, voire aussi de faire d’abord un rename/mv complet de la structure des programmes pour pouvoir conserver l’ancienne version ?

+1

Le problème est que spip-loader ne fait pas la différence entre une intallation et une mise à jour.
Dans le dernier cas, il faudrait désactiver les plugins, mettre à jour SPIP, vider le cache, et ne réactiver le plugin que s’il est compatible avec la nouvelle version.

Un autre « problème » de Spip-loader (implicitement soulevé dans la documentation l’accompagnant),
c’est que selon son paramétrage natif, il peut éventuellement provoquer un « saut de version » non volontaire,

Là encore ce n’est pas normal, mais c’est à mon avis surtout lié au mécanisme général d’installation de SPIP.
Lorsqu’on installe sur une base+prefixe qui correspond à une vieille version de SPIP, on devrait avoir un message d’avertissement ET avoir à ce moment le choix de la branche à choisir

et comme le retour en SPIP 2.x est impossible a partir d’une V3 (avec les nombreux pbs mineurs qui l’accompagnaient au début),

spip_loader pourrait en cas de mise à jour proposer de faire un backup

cela pouvait faire désordre… j’avais d’ailleurs proposé une première amélioration https://spippourlesnuls.fr/?spip_loader,184qui semble n’avoir jamais intéressé; personnellement j’utilise cette version patchée depuis près d’un an sur tous mes sites (SPIP 2 et SPIP 3 ).

Perso je n’avais pas vu l’article :wink:

Mais tu peux proposer ton patch en commitant ici :
http://zone.spip.org/trac/spip-zone/browser/dev/spip_loader
Cela dit, il faudrait peut-être remettre en branches/tags/trunk de répertoire avant que chacun y mette son grain de sel :wink:

En tout cas merci pour tes retours constructifs,

4

Si, puisqu’il y aun controle des droits de l’utilisateur connecté avant le lancement (j’ai eu la surprise de me voir refuser une M@J alors que j’utilisais un code rédacteur) Je crois percevoir que le principe est "gogogo, … et tant pis pour les revert de flamme ! " Mais je n’ai pas voulu/oser toucher à un “pilier” de SPIP, et le patch avait été proposé a un admin… je travaille actuellement sur un lien LDAP (ne marche plus tres bien en SPIP3) qui pourrait peut-etre intégrer les plugins associés dans un plugins-dist/ldap…

5

2013/8/13 YannX SPIP <yannx.spip@hotmail.fr>

J’ai la meme perception et pratique : les deux seuls soucis rencontrés peuvent venir, de la m-à-j de plugins, et parfois de l’authetification (avec la page blanche dans ecrire ) ; je rajouterais bien -pour pallier certains problèmes dans ce cas- de vider les cache lorsque spip_loader rencontre une mise-à-jour de version, voire aussi de faire d’abord un rename/mv complet de la structure des programmes pour pouvoir conserver l’ancienne version ?

+1

Le problème est que spip-loader ne fait pas la différence entre une intallation et une mise à jour.

Si, puisqu’il y aun controle des droits de l’utilisateur connecté avant le lancement
(j’ai eu la surprise de me voir refuser une M@J alors que j’utilisais un code rédacteur)

Heureusement :wink:
Ce n’est pas ce que je voulais dire. Selon moi, le problème est lié au mécanisme de base de SPIP qui fonctionne un peu trop en mode « on écrase tout sans prévenir ». Alerter qu’un site SPIP est déjà installé pourrait éviter quelques erreurs.

Dans le dernier cas, il faudrait désactiver les plugins, mettre à jour SPIP, vider le cache, et ne réactiver le plugin que s’il est compatible avec la nouvelle version.

cela pouvait faire désordre… j’avais d’ailleurs proposé une première amélioration https://spippourlesnuls.fr/?spip_loader,184qui semble n’avoir jamais intéressé; personnellement j’utilise cette version patchée depuis près d’un an sur tous mes sites (SPIP 2 et SPIP 3 ).

Perso je n’avais pas vu l’article :wink:

Mais tu peux proposer ton patch en commitant ici :
http://zone.spip.org/trac/spip-zone/browser/dev/spip_loader
Cela dit, il faudrait peut-être remettre en branches/tags/trunk de répertoire avant que chacun y mette son grain de sel :wink:

Je crois percevoir que le principe est "gogogo, … et tant pis pour les revert de flamme ! "
Mais je n’ai pas voulu/oser toucher à un « pilier » de SPIP, et le patch avait été proposé a un admin…

Tu as bien fait car il faudrait effectivement savoir comment est calculé le spip_loader disponible actuellement.
Et il faudrait absolument différencier une branche stable d’un trunk/ dans lequel on peut « s’éclater » même si on perd en stabilité…

Vu que j’ai fais quelques retours de mon côté, je vais créer le mise en branches+trunk moi-même dès demain, si personne n’y voit d’objection (et en profiter pour commiter 2 ou 3 babioles)

6

Voilà,

spip_loader est passé en version branches + trunk.
Il y a du nettoyage à faire dans le trunk car je doute que ce schéma explicatif soit encore à jour : http://zone.spip.org/trac/spip-zone/browser/dev/spip_loader/trunk/kit_loader/doc/flot.png