En faisant une migration d'un site SPIP 1.9.2 vers la 2.1.20, j'ai suivi la procédure suivante :
- créer un dump depuis SPIP 1.9.2 ;
- installation d'un SPIP 2.1.20 propre et vierge avec donc un seul auteur (id_auteur=1) ;
- restauration de la base de données depuis SPIP 2.1.20 ;
La procédure se passe bien…
Mais là où est le comportement étrange, c'est que je reste identifier en tant qu'auteur n°1 alors que ce n'est pas mon compte…
Ne devrait-il pas avoir une sécurité supplémentaire à ce niveau là ? Actuellement, cela se fait avec l'id_auteur. Ok, mais on devrait mettre une vérification sur le nom de l'auteur ou l'email. Si après restauration du dump on est sur des emails différents, on détruit la session pour pouvoir se reconnecter avec ses vrais identifiants.
Ou si on retrouve après restauration on retrouve un auteur ayant le même email et le même nom que le compte restauration, alors on connecte l'auteur sur ce profil… (Ça, ça va être difficile… car il faudrait refaire le cache avec le nouvel id_auteur)
Je n'ai pas encore testé ce processus sur une installation SPIP 3… Mais je suppute que cela est identique.
*sauvegardez votre base de données avant la mise-à-jour, mais ne la restaurez pas ensuite !* En effet, nous avons constaté que de nombreux utilisateurs sauvegardaient leur base de données, effectuaient la mise-jour, puis /réinstallaient leurs documents à partir de cette sauvegarde/ ; c’est une erreur, et leurs sites présentaient alors des dysfonctionnements. La sauvegarde est une simple précaution en cas de gros problème lors de la mise à jour, mais si l’opération se déroule bien (ce qui est presque toujours le cas !), *vous ne devez pas réinstaller cette sauvegarde.*
Il faut en effet installer le nouveau spip en le branchant sur la base de l'ancien spip et c'est spip qui fait la màj de la base
Oui et non.
Ici c’est une méthode pour reconstruire une base de données mysql au bon format.
Contexte: j’ai une bdd mysql 4 que je dois transférer sur une bdd mysql 5. Sauf que sur la base initiale, il n’y a pas les charset. Impossible d’en déduire le charset réel car parfois on a des accents dans la base, parfois encodé en utf-8, ou en latin1. Toutes tentatives sur un charset générique a été voué à l’échec. (Symptômes: accents kabbalistiques en partie privée de Spip)
Donc, j’ai créé une bdd mysql5 en utf8_general_ci puis installation d’un Spip 2, restauration d’un dump pour retrouver mes accents en base et espace privé. Et aussi utilisation d’InnoBD tant qu’à faire.
Ah oui, infos supplémentaires, je n’ai pas accès à la bdd initiale qui est toujours en Prod d’ailleurs. Je n’ai accès qu’à un dump mysql4 (format fichier sql)
Si tu as des mélanges de charsets c’est parfois un peu plus compliqué. Il va falloir mettre tes données dans une base (que tu auras créée en iso-8859-1). Ensuite, en PHP, lister tous les contenus, vérifier lesquels ne sont pas en utf8 (avec la fonction is_utf8()), et les convertir en utf8. Article par article, voire, champ par champ, si tes données sont vraiment en vrac. Enfin, dire que ta base est utf8, la dumper, et appliquer la méthode que j’ai décrite dans l’article.