je reviens sur la mise à jour de spip 1.92x vers spip 2.0
La mise à jour est véritablement problématique
je viens de mettre a jour un site sur l'Apinc
j'ai copié par ftp tous les fichiers de spip en écrasant les précédents
j'ai supprimé le inc_connect
relancer la config
jusque la pas de PB tout a fonctionné
passage dans l'espace privé
1er pb la feuille Css n'est pas chargée ou plutot firefox garde en mémoire la précédent, il est nécessaire de vider le cache du navigateur pour retrouver un affichage correct, cela va en déstabiliser plus d'un
mise à jour de la base de données
je clique sur la mise à jour de la base de données
- le système à l'air de patiner , plus d'affichage de la liste des tables en cours de mise à jour (est-ce volontaire), à la fin un message d'erreur qui dit que le système n'est pas encore configuré et je n'ai plus accès à l'espace privé
curieusement l'espace public fonctionne
- j'efface par ftp le connect.php et je recommence, m^me sanction
- j'efface par ftp TOUS les fichiers de spip et ne conserve que <IMG>, <config> et <squelettes>
- je recopie par FTP tous les fichiers de spip (j'ai viré les fichiers de langue que je n'utilise pas!!)
- je me reconnecte au site, je relance la mise à jour de la base de données, et la ça FONCTIONNE
je reviens sur la mise à jour de spip 1.92x vers spip 2.0
La mise à jour est véritablement problématique
je viens de mettre a jour un site sur l'Apinc
j'ai copié par ftp tous les fichiers de spip en écrasant les précédents
Pour ton souci, quand tu dis "écraser", c'est que tu as copié les fichiers par dessus les anciens. Or, il y a eu pas mal de déplacements de fichiers et un écrasement n'est pas suffisant (car n'efface pas les anciens). Il faut par conséquent supprimer complètement ou renommer ecrire, privé et dist (et oo/ qui n'est plus de ce monde). Les problèmes souvent viennent de fichiers encore présents dans dist/ mais déplacés dans privé/ (dist etant prioritaire, SPIP utilise alors les vieux fichiers et non les nouveaux).
Il y a un autre (vrai) bug, un peu plus génant en ce moment ; c'est l'importation des vieux dump (au format spip) qui finissent par des boucles de redirections (bloquées par firefox), empechant les mises à jour de s'effectuer correctement.
je reviens sur la mise à jour de spip 1.92x vers spip 2.0
La mise à jour est véritablement problématique
je viens de mettre a jour un site sur l'Apinc
j'ai copié par ftp tous les fichiers de spip en écrasant les précédents
Pour ton souci, quand tu dis "écraser", c'est que tu as copié les fichiers par dessus les anciens. Or, il y a eu pas mal de déplacements de fichiers et un écrasement n'est pas suffisant (car n'efface pas les anciens). Il faut par conséquent supprimer complètement ou renommer ecrire, privé et dist (et oo/ qui n'est plus de ce monde). Les problèmes souvent viennent de fichiers encore présents dans dist/ mais déplacés dans privé/ (dist etant prioritaire, SPIP utilise alors les vieux fichiers et non les nouveaux).
c'est bien cela, mais c'est la procédure usuelle classique de mise à jour, celle qui est encore dans la doc : Effectuer une mise à jour - SPIP
Je viens de rencontrer le pb, c'était la meta "admin" qui n'était pas effacée en fin d'importation. Je m'en suis sorti en enlevant cette meta par une commande SQL et suppression de meta_cache.txt. Il faut trouver dans quels cas la séquence de suppression n'est pas exécutée. J'ai l'impression que ça se produit lorsqu'on "restaure" un dump qui ne provient pas du même site, plus précisément où les id_auteur de la base initiale et de la base restaurée diffèrent: comme cette meta dépend de ce numéro (pour éviter que 2 admins lancent en meme temps une telle opération) ça doit coincer, mais il faudrait approfondir.
La restauration de base ancienne est une fonctionnalité qui a toujours été indiquée comme dangereuse et déconseillée car elle consistait à charger dans une base les données d'une base dont la structure et les champs pouvaient être différents. Du coup le résultat était imprévisible, avec dans le meilleur des cas une restauration de toutes les tables mais certaines avec des champs manquants, et dans le pire certaines tables omises.
Spip 2.0 contient maintenant un mécanisme de restauration fiable des anciennes bases (contrairement aux apparences :p) :
- un jeu de tables temporaires avec la structure de l'ancienne base est créé
- les données sont restaurées dans ce jeu de tables
- les tables du jeu de tables temporaires sont upgradées
- les données de ce jeu sont recopiées dans les tables.
C'est lors de cette dernière opération que les choses sont un peu tendues :
- on ne peut recopier la table des metas qu'en dernier lieu car c'est elle qui contient les infos sur le jeu de tables temporaires
- on ne devrait recopier la table des auteurs qu'en dernier aussi car si l'auteur connecté n'existe pas dans le dump on est deconnecté
Il est possible que des problèmes se posent donc, et je vais essayer de debug cela rapidement.
Quand au message d'avertissement, il demeure pour le moment, le temps que la fonctionnalité soit éprouvée.
Enfin, cela montre que malgré ce message pourtant dissuasif, qui avait été préféré à une interdiction pure et simple, le simple fait de laisser faire cette opération dangeureuse et non supportée passe maintenant pour une fonctionnalité établie, ce qui, pourtant, n'a jamais été le cas.
Cédric
En l'occurrence j'ai eu le pb dans un autre contexte: j'avais installé SPIP 2.0 avec rien dedans sauf moi comme auteur numéro 1, j'ai voulu importer un dump de spip-svn, donc avec la meme config de BD mais où j'ai un numéro d'id_auteur différent. Au bout d'un moment j'ai perdu la main ("site non configuré revenez plus tard"). J'ai viré la meta "admin" mais j'ai du aussi recréer mon compte car la table des auteurs n'était pas visiblement pas passée.