(Je passe en SPIP dev au cas où c'est un bug)
Oyez oyez braves gens!
J'ai une annonce à faire! La fusion sous SPIP 3 est toujours présente!
Louez soit les développeurs dans leur oubli! = > [ ]
Non, sérieusement, j'explique le contexte.
J'ai un site initialement en SPIP 2.1. Des rubriques, des mots-clés, des
articles, des images, des auteurs. Pas de plugins. (site #0)
Je crée une nouvelle copie de la bdd par phpmyadmin.
Je crée un nouveau site propre en SPIP 3.0.11 et lui indique cette BDD
dupliquée. (site #1)
SPIP met à jour la BDD...
Tout se passe bien.
Je fais un dump sqlite par ?exec=sauvegarder
Tout va bien.
Je crée un nouveau site sous SPIP 3.0.10 (oui je sais, ce n'est pas la même
version mais mon architecture de site est basée sur cette version pour le
moment) avec une BDD toute propre. (site #2)
J'y installe un plugin qui génère ma nouvelle arborescence avec création de
rubriques et de mots-clés. Association de mots-clés à des rubriques
précises.
Je fais une restauration de la BDD à partir d'un dump sqlite (qui se trouve
dans tmp/dump), j'ai validé "écraser la bdd".
L'import se fait et Ô surprise! Je retrouve mes anciens articles,
rubriques, mots-clés de mon site #1 mais aussi mon arborescence du site #2
et de ses mots-clés.
Les numéros de rubriques de mon site #2 ont changé pour se greffer "après"
ceux de mon site #1.
Comme quoi, une bonne discussion sur IRC ça aide beaucoup! Merci denisb!
Contexte avant contexte. J'ai repris un plugin maison qui insère des
rubnriques en base et des mots-clés.
Ce plugin, à son activation, vérifie si une rubrique id_rubrique=1 existe.
Si elle n'existe pas, elle crée mes rubriques pour ma nouvelle architecture.
Dans mon dump sqlite du site #1, il n'y a pas de rubrique id_rubrique=1.
Donc je "remplis" mes conditions pour que l'installation de mon plugin
maison se fasse.
C'est ce qui m'a induit en erreur.
Le dump s'est correctement fait avec mes anciennes données puis activation
des plugins qui étaient actifs avant le dump. Et insertion des mes
rubriques et des mots-clés.
Maintenant, je vais aller me cacher dans un trou pendant quelques temps.
Ce n'est pas un bug de SPIP.
Comme quoi, une bonne discussion sur IRC ça aide beaucoup! Merci denisb!
Contexte avant contexte. J'ai repris un plugin maison qui insère des
rubnriques en base et des mots-clés.
Ce plugin, à son activation, vérifie si une rubrique id_rubrique=1
existe. Si elle n'existe pas, elle crée mes rubriques pour ma nouvelle
architecture.
Dans mon dump sqlite du site #1, il n'y a pas de rubrique id_rubrique=1.
Donc je "remplis" mes conditions pour que l'installation de mon plugin
maison se fasse.
C'est ce qui m'a induit en erreur.
Le dump s'est correctement fait avec mes anciennes données puis
activation des plugins qui étaient actifs avant le dump. Et insertion
des mes rubriques et des mots-clés.
Maintenant, je vais aller me cacher dans un trou pendant quelques temps.
Désolé pour le bruit.
J'essaie de comprendre : finalement il n'y avait pas lieu de fusionner des
bases de données c'est ça ?
Oui et non.
Pour le oui, lieu de la fusion :
En fait, je voulais faire la fusion pour que les rubriques créées par mon
plugin maison restent avec les premiers id_rubrique (de 1 à 6 en
l'occurence).
Pour le non :
Le plugin maison est suffisamment "générique" pour se greffer à un contenu
existant.
Donc, la fusion n'était pas nécessaire là.
Cela dit, cette discussion n'a pas été inutile parce qu'on sait qu'il y a,
dans les cartons un plugin pour remplacer cette fonction absente de SPIP3.
Le plugin fusionne les champs extra s'ils ont été créés de la même façon dans les deux bases. En fait il copie tous les champs similiares d'une base à l'autre.
Sinon il faut utiliser en premier un autre plugin, comme la synchronisation des champs extra, pour synchroniser d'abord les champs d'une base à l'autre, puis faire la fusion pour importer les données.
Le plugin d'import export de la config des champs extra serait plus simple mais malheureusement il n'est pas encore porté pour la v3 de champs extra.
