Nous avons migré notre site de 1.9.2c vers une svn 10751.
Les types de documents ne sont plus reconnus. Dans la SVN il y a un champ extention dans la table spip_documents qui n'existait pas en 1.9.2 et qui n'est pas rempli lors de la mise à jour.
Si on renseigne ce champ à la main, c'est OK mais je ne me vois pas le faire pour les 3000 documents du site.
Nous avons migré notre site de 1.9.2c vers une svn 10751.
Les types de documents ne sont plus reconnus. Dans la SVN il y a un
champ extention dans la table spip_documents qui n'existait pas en 1.9.2
et qui n'est pas rempli lors de la mise à jour.
Si on renseigne ce champ à la main, c'est OK mais je ne me vois pas le
faire pour les 3000 documents du site.
Je viens de faire des tests avec la révision 10765, c'est bon si on fait la mise à jour d'une 1.9.2c fonctionnelle vers une 1.9.3(écrasement des fichiers par ftp). Par contre si on restaure une base de 1.9.2C dans une install neuve de 1.9.3 le champ extention est toujours vide (mais c'est peut être normal).
en tout cas, merci.
Laurent
Je viens de faire des tests avec la révision 10765, c'est bon si on fait
la mise à jour d'une 1.9.2c fonctionnelle vers une 1.9.3(écrasement des
fichiers par ftp).
Bon.
Par contre si on restaure une base de 1.9.2C dans une
install neuve de 1.9.3 le champ extention est toujours vide (mais c'est
peut être normal).
Ca, ca n'est pas spécifique à l'erreur de la MAJ 938: par définition restaurer une vieille base veut dire qu'on remplit les nouvelles tables par leur ancien contenu, et donc lorsqu'un champ nouveau a été introduit l'ancien contenu ne peut le remplir puisqu'il n'existait pas. Si l'on veut faire ça, il faut partir d'un site disposant de l'ancienne version de SPIP, le mettre à jour ce qui met à jour la base dans la foulée, sauvegarder cette mise à jour, ce qui donne le bon contenu pour restauration dans le site visé.
Ce qui reste contrariant c'est le cas de ceux qui ont exécuté la MAJ 938 originelle (fautive), et n'ont pas de sauvegarde antérieure pour repartir d'une état correct et exécuter la MAJ 938 nouvelle. Il y a sans doute peu de monde, mais c'est pas très glorieux.
Salut,
J’utilise habituellement une méthode intermédiaire :
je crée une arborescence SPIP nouvelle mouture à partir de l’archive zipée complète de files.spip.org (pour éviter de trimballer les vieux fichiers), mais à l’install je le connecte à la base ancienne version ce qui en général déclenche la mise à jour de base. Et hop mon site est prêt.
Oui, c'est plus simple lorsque les serveurs sont les mêmes.
Mais ça ne donne pas les moyens de revenir en arrière si la nouvelle version pose un pb.
Ce qui ne va pas dans la situation actuelle, c'est qu'une fois la nouvelle version de SPIP installé, on est obligé de lancer la MAJ de la base avant de pouvoir faire quoi que ce soit d'autre, en particulier une sauvegarde de la base avant sa mise à jour. Je pense que le lien "si vous etes admin, cliquer pour mettre à jour" devrait etre dédoublé pour offrir une version "sauvegarde préalable", ça éviterait quelques sueurs froides.
Le 13/11/07, *Committo,Ergo:sum* <esj@rezo.net <mailto:esj@rezo.net>> a écrit :
Ca, ca n'est pas spécifique à l'erreur de la MAJ 938: par définition
restaurer une vieille base veut dire qu'on remplit les nouvelles
tables par leur ancien contenu, et donc lorsqu'un champ nouveau a été
introduit l'ancien contenu ne peut le remplir puisqu'il n'existait
pas. Si l'on veut faire ça, il faut partir d'un site disposant de
l'ancienne version de SPIP, le mettre à jour ce qui met à jour la
base dans la foulée, sauvegarder cette mise à jour, ce qui donne le
bon contenu pour restauration dans le site visé.
Salut,
J'utilise habituellement une méthode intermédiaire :
je crée une arborescence SPIP nouvelle mouture à partir de l'archive zipée complète de files.spip.org <http://files.spip.org> (pour éviter de trimballer les vieux fichiers), mais à l'install je le connecte à la base ancienne version ce qui en général déclenche la mise à jour de base. Et hop mon site est prêt.
Est-ce que cette méthode est correcte ?
Effectivement mais dans notre cas le site d'orrigine est notre site de prod donc pas question de mettre à jour la base. Le but étant d'avoir un autre site en svn pour des tests.
Effectivement mais dans notre cas le site d’orrigine est notre site de
prod donc pas question de mettre à jour la base. Le but étant d’avoir un
autre site en svn pour des tests.
Ben ça passe aussi on copie la base et à l’install on dirige le nouveau spip dessus, sauf si la maj à un ptit bug (comme semblait l’indiqué le ticket pour une série de versions).
Il est vrai que je migre en général des versions stabilisée.
