Hello
on a eu des retours de personnes qui ont mis à jour par SPIP 3.1 par spip_loader en écrasement de fichiers simples
cela lève quelques erreurs:
qq retours aussi en IRC avec bertrandbbb que fait-on ? - on met à jour la doc en précisant comment faire une installation propre ? et on le précise dans l’annonce de SPIP 3.1 ? - on crée un plugin de nettoyage ? on pourrait se baser sur la liste de fichiers établis ici a++
Un plugin, ça voudrait dire diffuser à nouveau l'info, et elle ne sera pas forcément reçue.
Pourquoi pas directement dans spip_loader si on a la liste précise des fichiers à supprimer ?
Mais ça voudrait dire annoncer qu'il y a un nouveau spip_loader...
je suis pas persuadé que supprimer d'anciens fichiers (et répertoires)
de l'installation antérieure soit une bonne idée.
ne serait-ce que pour ceux qui veulent utiliser spip_loader pour
passer de 2.1 à 3.0 par exemple.
le mieux, à mon avis, serait de déplacer en backup les
répertoires mis à jour ecrire/, plugins-dist/, etc par exemple
en les renommant back_ecrire/ back_plugins-dist/ back_etc
mais ça veut dire doubler la taille physique de l'installation
(ajouter 70 à 80 Mo sur l'hébergement donc...)
Oui pourquoi pas de faire une backup des répertoires que l'on archive.
L'idéal est surtout de pouvoir utiliser le spip_loader sans se connecter en FTP pour simplifier au maximum la vie des usagers
actuellement la méthode de mise à jour est un *poil* complexe pour un débutant (10 étapes...)
http://contrib.spip.net/Mettre-a-jour-vers-SPIP-3-1-pour-les-nuls
Hello 
En faite, la question qui se pose ici, est déjà dans un ticket
https://core.spip.net/issues/3644
perso, je dirais que en y réfléchissant que spip_loader fasse une copie des
fichiers dans un dossier "backup/sauvegarde" serait sans doute un plus.
Après la question de savoir si spip_loader doit supprimer les fichiers, je
ne sais pas si c'est une si bonne idée que ça.
Il y a sans doute des gens (débutant) qui ont fait directement des modifs
dans squelettes-dist au lieu de faire un dossier "squelettes".
Dans les deux cas, en utilisant spip_loader, cela réduire de façon
drastique, car au pire, cela donnera
Lancement de spip_loader
Une fois la mise à jour fini, faites la suppression du dossier "backup"
Après, sur la zone, il était question il y a peu que spip_loader propose le
choix de la version (2.1/3.0/3.1), donc ne faudrait 'il pas faire d'une
pierre de coup ?
Pour l'annonce du nouveau spip_loader, c'est un faux problème puisqu'un
message apparait dès qu'une version plus récente expliquant à l'utilisateur
qu'une nouvelle version est dispo, donc entre ça, et une annonce sur le
blog...
-----Message d'origine-----
Envoyé : vendredi 15 janvier 2016 18:46
d'écrasement de fichiers
Oui pourquoi pas de faire une backup des répertoires que l'on archive.
L'idéal est surtout de pouvoir utiliser le spip_loader sans se connecter en
FTP pour simplifier au maximum la vie des usagers
actuellement la méthode de mise à jour est un *poil* complexe pour un
débutant (10 étapes...)
http://contrib.spip.net/Mettre-a-jour-vers-SPIP-3-1-pour-les-nuls
Hello
Salut,
la ligne de commande suivante donne la liste des fichiers supprimés entre 2 versions stable (3.0.21 vs 3.1.0):
svn diff --summarize --old=svn://trac.rezo.net/spip/tags/spip-3.0.21 --new=svn://trac.rezo.net/spip/tags/spip-3.1.0 | egrep “^D” | sed -e “s/.spip-3.0.21/(.)$/\1/”
résultats :
rien.gif
CHANGELOG.txt
prive/javascript/pause.js
prive/javascript/jquery.colors.js
prive/formulaires/selecteur/jquery-ui-1.8.custom.js
prive/formulaires/selecteur/inc-nav-rubriques_fonctions.php
prive/formulaires/selecteur/rubriques_fonctions.php
prive/formulaires/selecteur/ajax_fonctions.php
prive/formulaires/selecteur/selecteur_fonctions.php
prive/formulaires/selecteur/picker-ajax_fonctions.php
prive/formulaires/selecteur/navigateur_fonctions.php
prive/formulaires/selecteur/articles_fonctions.php
prive/squelettes/inclure/plan-articles.html
ecrire/req/pg.php
ecrire/action/reorganiser.php
ecrire/action/iconifier.php
C’est reproductible d’une version à l’autre, il y a peut-être moyen de fournir un référentiel en ligne puis, à terme, une méthode systématique, non ?
Amicalement,
Tu oublies les plugins
Il existe un plugin d'Ybbet pour afficher/mémoriser la liste des plugins actifs
(ce qui compléterait avantageusement l'aide-memoire d'Erational)
http://contrib.spip.net/Les-plugins-necessaires-au-site /bravo !! /
PS je n'avais pas réussi à encoder correctement l'enregistrement
pour en créer automatiquement un fichier paquet.xml.zip
qui serait l'outil idoine de sauvegarde-restauration des plugins utiles,
d'un seul chargement (en utilisant SVP natif..)
Bloavez Mad
Tu oublies les plugins
Il existe un plugin d'Ybbet pour afficher/mémoriser la liste des plugins
actifs
(ce qui compléterait avantageusement l'aide-memoire d'Erational)
Lister les plugins nécessaires au site - SPIP-Contrib /bravo !! /
En fait je pensais plus au calcul du diff entre deux versions :
il faut prendre en compte les plugins-dist (si on part de 3.0 et plus).
En dessous, James a raison vu qu'on écrase pas le dossier "extensions".
Non :), je n’oublie pas les plugins, mais oui Gilles, tu as raison, cette commande ne suffit pas, elle ne tient pas compte des références externes SVN. Je vais creuser …
à propos de l’utilisation ou de la création d’un plugin pour ce genre de problème, excusez-moi, mais, intuitivement, je ne trouve pas ça bon comme idée. C’est plus à l’outil d’installation, et surtout de mise à jour de savoir ce qu’il a à faire, ou à suggérer.
+1, il faut que ça reste simple.
Hello J
Normalement, si je n’avais pas fait d’erreur, tu trouveras la même chose que moi.
http://www.spip.net/ecrire/?exec=article&id_article=5842
Par contre en passant, je suis pas sûr, mais il me semble qu’il n’y a pas eu d’équivalent pour spip 2.0 vers 2.1 ; 2.1 vers 3.0
Je peux faire la même chose, mais s’il y a moyen de le faire automatiquement, cela serait mieux J
Franck
Donc, comme il n’est pas possible d’explorer les svn:externals via la commande svn diff, j’ai fait un script que vous pourrez trouver à l’url suivante :
http://zone.spip.org/trac/spip-zone/browser/outils/print_deleted_files.sh
c’est du bash. Je ne l’ai pas documenté.
en PJ, le résultat entre 3.0.21 et 3.1.0. Sur mon ordi, le script à mis 2m30 pour produire le résultat complet.
Fonctionnement :
OLD est l’ancienne version, NEW est la nouvelle. On traite ici les tags, donc, les versions stables de SPIP. Ne vous amusez pas à le tester avec des branches de maintenance ou le trunk (je veux dire, la version de DEV)
On fait la liste des plugins gérés par svn:externals des deux versions
On compare ces listes en faisant la correspondance par le répertoire de chaque external
Pour chaque plugins listé dans OLD
Si le répertoire n’est pas listé dans NEW, on affiche de répertoire voué à être supprimé
Si le répertoire est aussi listé dans NEW, on compare les fichiers via svn diff et on affiche les fichiers existants dans OLD et supprimés dans NEW
On compare enfin les fichiers des 2 versions via svn diff et on affiche les fichiers existants dans OLD et supprimés dans NEW
Amicalement,
PS: pour info, Toggg avait fait un script php (du joli nom de cancellatore http://zone.spip.org/trac/spip-zone/browser/outils/cancellatore/cancellatore.php) qui efface des fichiers depuis un serveur web… En matière de sécurité, on fait mieux, mais on en avait besoin parce que le spip_loader de l’époque faisait des misères aux serveurs qui activaient le safe_mode… On avait envie de le fusionner avec spip_loader et puis, bon, voilà, c’est jamais arrivé…
deleted-3.0.21-3.1.0.txt (15.2 KB)
Petit complément:
ce script permet de vérifier qu’il n’y a pas de suppression de fichiers entre, par exemple, une 3.0.20 et une 3.0.21
j’ai fait les tests suivants :
2.0.26 vers 2.1.28
2.1.28 version 3.0.21
et j’ai poussé les résultats ici http://zone.spip.org/trac/spip-zone/browser/acotes/fichiers_supprimes
Hello,
Je ne comprend pas bien l’intérêt de faire des diff pour obtenir la liste des fichiers, le spip_loader va de toutes façon télécharger et décompresser un zip sur l’hébergement. Il ne cible pas les fichiers modifiés, il ne fait pas de diff entre les versions.
Alors certes, c’est très pratique pour savoir ce qu’il faut supprimer précisément sur l’hébergement quand on fait une mise à jour. Mais le problème ne ce pose pas si on déplace les fichiers du core.
Charger le spip_loader
Cela me semble la manière la plus simple de faire non ?
Alors certes, c'est très pratique pour savoir ce qu'il faut supprimer
précisément sur l'hébergement quand on fait une mise à jour. Mais le
problème ne ce pose pas si on déplace les fichiers du core.Charger le spip_loader
- Déplacer les dossiers du core dans un dossier backup
- Lancer la mise à jour de SPIP
-> ça fonctionne, proposer à l'utilisateur de supprimer le dossier backup
-> ça échoue, lancer une erreur et restaurer les fichiers du backup
L'intérêt que je vois c'est de pouvoir se passer d'un backup - mais on perd
peut-être en sécu avec cette méthode
Hello,
Je ne comprend pas bien l'intérêt de faire des diff pour obtenir la liste
des fichiers, le spip_loader va de toutes façon télécharger et décompresser
un zip sur l'hébergement. Il ne cible pas les fichiers modifiés, il ne fait
pas de diff entre les versions.
J'ai lu la remarque de DenisB et sa proposition. C'est effectivement plus
simple. Mais, comme il le souligne, ça double l'espace occupé.
Que fait spip_loader lors d'une mise à jour ? Il télécharge effectivement
un zip et le décompresse. Concrètement, il va ajouter des nouveaux fichiers
et modifier, oui, il modifie aussi, des fichiers corrigés ou améliorés.
Mais, comme tu le dis, il ne fait pas de diff, il ne supprime pas les
fichiers rendus obsolètes par cette mise à jour.
Or, ce sont certains de ces fichiers obsolètes mais pas effacés qui
provoquent des erreurs (msie-compat, req/pg.php, ...). à ma connaissance,
personne ne fait de tests assez poussés, pour anticiper ces anomalies. Ce
n'est pas un reproche 
Je rappelle que spip_loader, c'est un outil fait pour ceux qui ne peuvent
pas utiliser svn sur le serveur hébergeant leurs sites et aussi pour
simplifier les installations et mises à jour sans passer par ftp. Les
outils de synchronisation sont rares, peu connus, et finalement assez
complexes à appréhender quand l'utilisation de ftp est déjà vécue comme
difficile.
Alors certes, c'est très pratique pour savoir ce qu'il faut supprimer
précisément sur l'hébergement quand on fait une mise à jour. Mais le
problème ne ce pose pas si on déplace les fichiers du core.
L'objectif du script que je propose, et qui mérite certainement d'être
validé pour nous assurer qu'il est fiable, au même titre que l'on considère
spip_loader comme étant fiable, est surtout d'éviter un travail pénible,
empirique et peu fiable malgré toute la bonne volonté des gens qui le font,
à savoir, lister les fichiers supprimés entre 2 versions... Si jamais on
constate que le script est fiable, reproductible, robuste en somme,
peut-être que cela deviendra profitable de l'automatiser un peu... Mais
nous n'en somme pas là.
Charger le spip_loader
- Déplacer les dossiers du core dans un dossier backup
- Lancer la mise à jour de SPIP
-> ça fonctionne, proposer à l'utilisateur de supprimer le dossier backup
-> ça échoue, lancer une erreur et restaurer les fichiers du backupCela me semble la manière la plus simple de faire non ?
En supposant que cela fonctionne de manière robuste, qu'advient-il des
backups de fichiers obsolètes ? Que se passe-t-il à la mise à jour suivante
?
Je ne défends pas une idée plus qu'une autre. J'assemble des éléments pour
que nous puissions faire le meilleur choix. Désolé si je donne l'impression
du contraire.