1. J'ai fait un dump SPIP - les champs extras ajoutés à la table « articles » étaient bien mis dans le fichier xml. Par contre ils ne sont plus dans la table après une réimportation de ce fichier.
2. Donc j'ai restauré la table par phpMyAdmin, pour avoir tout.
3. En refaisant un dump/restauration SPIP après avoir changé des données, je vois que cette fois-ci les changements dans les champs ajoutés sont bien transférés à la base destinataire.
Est-ce possible que les données sont importées seulement si le champs existe déjà dans la table destinataire ?
Autrement dit : on peut utiliser le dump/restauration de SPIP, à condition d’être sûr que la définition des champs dans les tables de la base destinataire est la même ? (Facile à oublier...)
1. J'ai fait un dump SPIP - les champs extras ajoutés à la table « articles » étaient bien mis dans le fichier xml. Par contre ils ne sont plus dans la table après une réimportation de ce fichier.
C'est le «problème» de tous les plugins qui modifient la base : pour que SPIP restaure leurs contenus dans un autre SPIP, il faut que les champs soient connus, ie. que le plugin soit installé sur le site où l'on fait la restauration. Ce qui se complique avec les CE, c'est que les champs sont créés à la volée, par conséquent, sur le site à restaurer, il faut activer le plugin, et ajouter les champs que l'on souhaite voir se restaurer. Pour l'instant il n'y a pas d'autre solution que ça.
Cependant, toute proposition est bienvenue. Quelques possibilités :
- système d'import/export de configuration de CE ?
- recréer les champs sur une restauration en fonction de la meta 'iextras' (mais je vois pas comment)
- ...
Cependant, toute proposition est bienvenue. Quelques possibilités :
- système d'import/export de configuration de CE ?
- recréer les champs sur une restauration en fonction de la meta 'iextras'
(mais je vois pas comment)
Avec les dumps du type mysqldump, ce problème n'existe pas. C'est dnc
la sauvegarde/restauration de SPIP qui est déficiente