Suite au même problème (ci-dessous), j'ai testé sur un même site: sauvegarde de la base, effacer la base, réinstallation, restauration de la base. Donc, tout ça sur un seul site, en local, même version de PHP5, de SPIP et tout.
Et je confirme: SPIP 2.0.10 [14698] ne restaure pas la table spip_meta, pourtant présente dans le xml du dump. Le dump ne me semble donc pas incomplet.
Par ailleurs, j'ai constaté que si les tables d'un plugin (agenda en l'occurrence) sont dans le dump mais que le plugin n'est pas activé dans le site où on restaure la base, les tables ne sont pas restaurées. Je ne sais pas si c'est voulu? Ca me paraît un peu bizarre. On peut décider de réactiver le plugin plus tard et s'étonner de la disparition des données.
Par ailleurs, j'ai constaté que si les tables d'un plugin (agenda en
l'occurrence) sont dans le dump mais que le plugin n'est pas activé dans
le site où on restaure la base, les tables ne sont pas restaurées. Je ne
sais pas si c'est voulu? Ca me paraît un peu bizarre. On peut décider de
réactiver le plugin plus tard et s'étonner de la disparition des données.
Ça, c'est normal : il faut procéder en 3 temps :
1) Restauration
2) activation des plugins
3) nouvelle restauration
Remarque : avec un dump mysql (avec phpmyadmin ou via ssh en ligne de commande), on n'a pas ce problème : la restauration restaure tout (sous réserve que le nom des dossiers des plugins soient les mêmes)
Par ailleurs, j'ai constaté que si les tables d'un plugin (agenda en
l'occurrence) sont dans le dump mais que le plugin n'est pas activé dans
le site où on restaure la base, les tables ne sont pas restaurées. Je ne
sais pas si c'est voulu? Ca me paraît un peu bizarre. On peut décider de
réactiver le plugin plus tard et s'étonner de la disparition des données.
Ça, c'est normal : il faut procéder en 3 temps :
1) Restauration
2) activation des plugins
3) nouvelle restauration
Cette procédure est peut-être "normale", mais ça ne m'empêche pas d'interroger sa pertinence...
D'autant qu'elle n'est pas documentée.
(ouille, un petit lifting serait bienvenu)
Remarque : avec un dump mysql (avec phpmyadmin ou via ssh en ligne de commande), on n'a pas ce problème : la restauration restaure tout (sous réserve que le nom des dossiers des plugins soient les mêmes)
Selon moi, le but de la restauration via l'interface de spip est de permettre à quiconque de sauvegarder/restaurer la base, sans connaître phpMyAdmin (encore moins le shell
> 1) Restauration
> 2) activation des plugins
> 3) nouvelle restauration
Bonjour,
je viens de tester comme ça et ça n'a rien changé.
Après avoir restauré, j'ai activé tous les plugins à l'identique, puis j'ai à nouveau restauré, et rien de plus n'est venu, ni les configuration des plugins, ni même le nom du site.
Oui, je crois qu'on a manifestement un soucis depuis quelques versions mineures sur la restauration de spip_meta.
J'ai pas osé me pencher sur le problème, mais je râle aussi que les métas ne soient pas récupérées. C'est rarement moins d'une demi-journée dès qu'on touche à la restauration pour comprendre le code et le modifier sans rien casser et tester... Alors, j'attends d'être bien motivé dans un moment de lucidité
Ce n'est pas le seul problème rencontré : je n'ai pas réussi l'autre jour à importer un DUMP 1.8.3 alors que justement le restaurateur de la 2.0 devrait normalement le permettre... Tout cela est délicat.
Je soupçonne (un rien facilement vu que j'en ai pas l'utilité ^^) les fonctionnalités de «fusion» et de «sauvegardes partielles» de compliquer inutilement ce code :).
Alors dans ce cas, je crois qu'on peut dire que c'est un bug à résoudre en vue de la 2.1.11 ou d'un affinage de 2.0.10 (14699 ou 14700) ?
On va voir ce que dit la liste spip-dev...
Parce que là typiquement dans ce cas je vais devoir passer 60 fois (60 sites) une heure de plus de travail à tout reparamétrer tous les plugins au détail près, à la main.
Il doit y avoir une bidouille avec phpmyadmin. As-tu essayé les options "Mode de compatibilité SQL" lors de l'importation?
Aurélie
Tina
Aurélie a écrit :
Salut,
Suite au même problème (ci-dessous), j'ai testé sur un même site: sauvegarde de la base, effacer la base, réinstallation, restauration de la base. Donc, tout ça sur un seul site, en local, même version de PHP5, de SPIP et tout.
Et je confirme: SPIP 2.0.10 [14698] ne restaure pas la table spip_meta, pourtant présente dans le xml du dump. Le dump ne me semble donc pas incomplet.
Par ailleurs, j'ai constaté que si les tables d'un plugin (agenda en l'occurrence) sont dans le dump mais que le plugin n'est pas activé dans le site où on restaure la base, les tables ne sont pas restaurées. Je ne sais pas si c'est voulu? Ca me paraît un peu bizarre. On peut décider de réactiver le plugin plus tard et s'étonner de la disparition des données.
Aurélie
Le 11/01/2010 23:12, Tina ENGELBERG a écrit :
Bonjour à tous,
en 2.0.10 avec un PHP 4, je fais un dump et par exemple, la table spip_meta annoncé à (133), au final (recap du dump) m'annonce spip_meta (125).
Résultat évidemment, je perds un maximum de paramétrages que je dois me retaper alors que je vais devoir faire ça pour 60 sites...
Est-ce à cause de php 4 ? Je ne peux pas upgrader en PHP 5, car c'est justement la raison pour laquelle je dumpe, en vue d'une migration sur une autre machine ayant PHP 5.
Comment me sortir de cette embrouille ???
Existe-il une manière de se faire un dump .xml à partir de PhpMyAdmin par exemple ?
