spip-zone-commit@rezo.net a écrit le 19/10/2017 à 17:36 :
Author: marcimat@rezo.net
Date: 2017-10-19 17:36:19 +0200 (Thu, 19 Oct 2017)
New Revision: 107053
Modified:
_outils_/spip_loader/trunk/spip_loader.php
Log:
Version 3.0 du SPIP Loader qui… enlève les fichiers obsolètes.
Ce changement de comportement a un impact majeur sur le SPIP Loader et est donc à tester.
Après le déballage du zip, puis le déplacement des fichiers du zip dans l’arborescence finale de SPIP,
donc proche de 100% de la barre de progression de l’installation, le loader va comparer
les répertoires de SPIP avec ceux contenus dans le Zip d’origine.
Les fichiers ou répertoires en plus dans SPIP (c’est à dire issus d’une précédente installation)
sont déplacés dans un répertoire "fichiers_obsoletes_{date}" sous la même arborescence
(oui, on ne les supprime pas quand même drastiquement aucazou).
On ne teste que *certains* répertoires (ecrire, prive, plugins-dist, squelettes-dist, et l’ancien 'extensions').
Les autres ne sont pas comparés, ni la racine.
Dès lors, cela *peut* impacter certains sites qui auraient :
- ajouté des fichiers dans prive/ ou ecrire/
- ajouté des plugins dans plugins-dist/
Le premier cas étant à éviter, ça ne doit pas arriver.
Le second cas est plus problématique car cette situation pourrait effectivement arriver. À voir donc.
Dans tous les cas les plugins ne sont pas perdus, juste déplacés dans ce répertoire d’obsolescence.
Que dirais-tu de pouvoir mettre un fichier à tester dans les dossiers qui ne doivent pas être supprimés par spip_loader ?
Par exemple : _SPIPLOADER_IGNORE_
Dans le cas d'un dossier dans extensions, il faudrait même le déplacer dans plugins-dist...
spip-zone-commit@rezo.net a écrit le 19/10/2017 à 17:36 :
Author: marcimat@rezo.net
Date: 2017-10-19 17:36:19 +0200 (Thu, 19 Oct 2017)
New Revision: 107053
Le second cas est plus problématique car cette situation pourrait effectivement arriver. À voir donc.
Dans tous les cas les plugins ne sont pas perdus, juste déplacés dans ce répertoire d’obsolescence.
Que dirais-tu de pouvoir mettre un fichier à tester dans les dossiers qui ne doivent pas être supprimés par spip_loader ?
Par exemple : _SPIPLOADER_IGNORE_
Dans le cas d'un dossier dans extensions, il faudrait même le déplacer dans plugins-dist...
Je sais pas… je suis franchement pas très chaud comme ça en première lecture. Je vais tenter de détailler : à mon avis, le Spip Loader est un outil pour le commun des mortels qui n’est pas forcément à l’aise avec SPIP / SSH / SVN.
C’est quand même bien plus sûr de faire un 'svn switch' ou un 'svn update' pour changer de branche ou mettre à jour que d’utiliser le loader, dès lors qu’on a un accès SSH au serveur / à l’hébergement, il me semble ; d’autant plus qu’avant ces modifications récentes le Loader laissait donc les anciens fichiers et on a vu plein de fois sur spip-user que c’était confus pour les gens et source de nombreux problèmes...
Et du coup j’aurais tendance à considérer que dès lors que tu commences à vouloir mettre des plugins dans le répertoire 'plugins-dist/', c’est que déjà tu as une certaine habitude de SPIP. Et y coller en plus des '_SPIPLOADER_IGNORE_' ça me semble un rien tordu. Dans ton cas, tu as accès aux serveurs en SSH et tu maitrises SVN… Quel est l’intérêt du coup d’utiliser le SPIP Loader ?
Cela dit, je suis pas fermé non plus, mais vraiment là comme ça je vois pas l’intérêt.
Dès lors, cela *peut* impacter certains sites qui auraient :
- ajouté des plugins dans plugins-dist/
[...] plus problématique car cette situation pourrait
effectivement arriver. À voir donc.
Dans tous les cas les plugins ne sont pas perdus, juste déplacés dans ce
répertoire d’obsolescence.
Que dirais-tu de pouvoir mettre un fichier à tester dans les dossiers qui ne
doivent pas être supprimés par spip_loader ?
Par exemple : _SPIPLOADER_IGNORE_
Trop de constantes tue la constance.
En fait je pense que la cible visée par le loader n'en a pas besoin...
Dans le cas des plugins dans -dist, on est face à une personne qui
maitrise assez pour savoir récupérer ses petits, en sachant que de
toute façon ils sont à mettre en quarantaine tant qu'on ne sait pas
garantir que ce sera compatible avec la version vers laquelle on
migre.
Matthieu Marcillaud a écrit le 19/10/2017 à 22:38 :
Le 19/10/2017 à 21:00, RealET a écrit :
spip-zone-commit@rezo.net a écrit le 19/10/2017 à 17:36 :
Author: marcimat@rezo.net
Date: 2017-10-19 17:36:19 +0200 (Thu, 19 Oct 2017)
New Revision: 107053
Le second cas est plus problématique car cette situation pourrait effectivement arriver. À voir donc.
Dans tous les cas les plugins ne sont pas perdus, juste déplacés dans ce répertoire d’obsolescence.
Que dirais-tu de pouvoir mettre un fichier à tester dans les dossiers qui ne doivent pas être supprimés par spip_loader ?
Par exemple : _SPIPLOADER_IGNORE_
Dans le cas d'un dossier dans extensions, il faudrait même le déplacer dans plugins-dist...
Je sais pas… je suis franchement pas très chaud comme ça en première lecture. Je vais tenter de détailler : à mon avis, le Spip Loader est un outil pour le commun des mortels qui n’est pas forcément à l’aise avec SPIP / SSH / SVN.
C’est quand même bien plus sûr de faire un 'svn switch' ou un 'svn update' pour changer de branche ou mettre à jour que d’utiliser le loader, dès lors qu’on a un accès SSH au serveur / à l’hébergement, il me semble ; d’autant plus qu’avant ces modifications récentes le Loader laissait donc les anciens fichiers et on a vu plein de fois sur spip-user que c’était confus pour les gens et source de nombreux problèmes...
Et du coup j’aurais tendance à considérer que dès lors que tu commences à vouloir mettre des plugins dans le répertoire 'plugins-dist/', c’est que déjà tu as une certaine habitude de SPIP. Et y coller en plus des '_SPIPLOADER_IGNORE_' ça me semble un rien tordu. Dans ton cas, tu as accès aux serveurs en SSH et tu maitrises SVN… Quel est l’intérêt du coup d’utiliser le SPIP Loader ?
Alors, c'est vrai que j'utilise SSH + svn up / svn sw à fond dès que je peux.
Mais je suis amené à travailler sur des sites où je n'ai qu'un accès FTP.
Dans ce cas, spip_loader est vraiment pratique !
Et avec cette idée d'un fichier pour ignorer un dossier, ça permettrait au moins de passer de 3.1.6 à 3.1.7
L'idée, c'est de gagner du temps partout où c'est possible.
Et de ne faire par FTP que ce qui ne peut être fait ni par SVP, ni par spip_loader.
Cela dit, je suis pas fermé non plus, mais vraiment là comme ça je vois pas l’intérêt.
J'espère que l'intérêt est un peut plus évident avec mon explication.
Dès lors, cela *peut* impacter certains sites qui auraient :
- ajouté des plugins dans plugins-dist/
[...] plus problématique car cette situation pourrait
effectivement arriver. À voir donc.
Dans tous les cas les plugins ne sont pas perdus, juste déplacés dans ce
répertoire d’obsolescence.
Que dirais-tu de pouvoir mettre un fichier à tester dans les dossiers qui ne
doivent pas être supprimés par spip_loader ?
Par exemple : _SPIPLOADER_IGNORE_
Trop de constantes tue la constance.
Ça n'est pas une constante mais un fichier à placer dans le dossier à ignorer
En fait je pense que la cible visée par le loader n'en a pas besoin...
Dans le cas des plugins dans -dist, on est face à une personne qui
maitrise assez pour savoir récupérer ses petits, en sachant que de
toute façon ils sont à mettre en quarantaine tant qu'on ne sait pas
garantir que ce sera compatible avec la version vers laquelle on
migre.
Pas quand c'est seulement passer de 3.1.6 à 3.1.7
Seulement en cas de passage de 3.1 à 3.2
Matthieu Marcillaud a écrit le 19/10/2017 à 22:38 :
Cela dit, je suis pas fermé non plus, mais vraiment là comme ça je vois pas l’intérêt.
J'espère que l'intérêt est un peut plus évident avec mon explication.
Mouais. C'est implémenté par Connexion · GitLab avec un fichier .spip_loader_keep à mettre dans les plugins-dist/X/.spip_loader_keep que tu veux conserver
