Ce plugin permet d’importer tous les contenus d’un site source, en évitant les conflits d’identifiants qu’une simple copie générerait inévitablement.
Cette fonctionnalité existait pour SPIP2, mais n’a pas été portée sur SPIP3.
Ce plugin est une réécriture complète, avec une analyse automatique de la structure de la base de données.
Qu’est ce qui est importé par ce plugin ?
À peu près tout :
- les objets natifs : articles, rubriques, auteurs, mots clés... ainsi que les objets éditoriaux s’ils existent dans les deux sites,
- les documents, images et logos (en option),
- les associations entre objets (auteurs -> articles, articles -> documents...),
- les liens internes (ex : [->artXX]) et les identifiants dans les modèles (ex : <embXX>) sont mis à jour,
- les champs extra s’ils ont été déclarés sur les deux sites,
- les tables et les données des plugins qui sont installés sur les deux sites (formulaires, agendas, accès restreint...).
Avertissement
Il est très fortement conseillé de réaliser une sauvegarde de votre site avant de réaliser une fusion : le plugin est testé et fonctionnel mais l’opération de fusion est irréversible.
Sauvegardez la base de données et le répertoire IMG du site hôte
En cas d’erreur, on peut ainsi redémarrer depuis la sauvegarde.
L’import des documents et images de la source ne vérifie pas si des fichiers du même nom dans le /IMG de l’hôte existent déjà. Si jamais c’est le cas, ces derniers seraient écrasés.
Pour des bases de données très volumineuses, le processus peut être long et nécessiter beaucoup de ressources. Le processus de fusion peut échouer sur un hébergement mutualisé.
1 - Déclarer une base externe
Sur le site hôte (celui qui reçoit l’import), il faut commencer par déclarer la base de données source (celle qui va être importée) comme une base de données externe.
Dans le bandeau principal, « Maintenance » -> « Maintenance technique », puis choisir « Déclarer une autre base ».
Lors de l’étape « Déclarer une autre base (3/3) Indiquez le nom utilisé pour ce serveur » utilisez un nom commençant par connect_
Si le site source utilise une base de données Mysql, indiquer simplement les paramètres de connexion à la base : serveur, utilisateur, mot de passe, nom de la base [1].
Si le site source utilise une base de données sqlite, copiez le fichier .sqlite de la base (que vous trouverez dans le répertoire /config/bases/ du site source) au même endroit dans le site hôte (dans /config/bases/ donc).
Rechargez la page « Déclarer une autre base », votre base source devrait apparaître.
Les sauvegardes de SPIP sont au format sqlite, on peut donc aussi importer une sauvegarde d’un autre site : pour ça il faut copier la sauvegarde du site source (qu’on trouve dans /tmp/dump) dans le répertoire /config/bases/ du site hôte.
La base de données source doit être dans la même version que la base hôte, dans le cas contraire un avertissement sera lancé lors de la fusion, à vous de confirmer la fusion.
Si les différences de versions sont mineures, le risque d’erreur est faible [2].
Sinon, faites une mise à jour du site source, avec spip_loader c’est rapide et sans douleur.
Problèmes d’encodage
Dans certains cas, il a été signalé un problème d’encodage qui tronquait les titres et les textes dès le premier accent ou caractère étendu.
Dans ce cas, il suffit d’ajouter cette ligne à la fin du fichier de connexion associé à la base source (dans /connect) :
mysql_query("SET NAMES 'utf8'");
2 - Démarrer la fusion
Le plugin s’installe dans le menu « Maintenance » du bandeau principal.
Par défaut, seuls les webmestres y ont accès.
Choisissez la base de données à importer.
Les documents et logos du site source peuvent aussi être importés si on déclare leur chemin physique. Dans ce cas, il faut réaliser l’opération de fusion sur le même serveur (sur votre poste en local, ou sur un serveur en ligne).
Le site source peut être importé dans un secteur en particulier, ou bien à la racine du site.
En option, vous pouvez choisir de ne pas importer les statistiques et les referrers. Ces tables peuvent être très volumineuses et longues à traiter dans certains cas, et vous n’en avez peut être pas besoin.
Au démarrage de la fusion, le plugin peut vous remonter plusieurs avertissements :
- versions de bases de données différentes (cf plus haut)
- certaines tables ou certains champs n’ont pas été trouvés dans la base source
Ce deuxième cas peut se produire si des plugins du site hôte ne sont pas installés dans le site source, ou bien si le site hôte comporte certains champs spécifiques (champs extra) qui ne sont pas présents dans le site source.
C’est un simple message pour vous prévenir que les données de ces plugins seront ignorées, cela ne causera pas d’erreurs particulières, vous pouvez confirmer et continuer.
Exemple :
Ici, le plugin formidable est installé sur le site hôte, mais il ne l’est pas sur le site source. Le plugin prévient que ses tables n’ont pas été trouvées sur le site source.
C’est juste un rappel, cela ne causera pas d’erreurs particulières, vous pouvez confirmer et continuer.
NB : Quand vous lancerez l’opération de fusion, vous ne verrez aucun indicateur visuel de la progression en cours, vous verrez juste l’indicateur visuel du navigateur qui indique un chargement de page.
Ne relancez pas l’opération en cliquant plusieurs fois sur le bouton !
Complément : fonctionnement technique
Le code s’appuie entièrement sur les schémas de l’hôte déclarés dans lister_tables_principales() et lister_tables_auxiliaires() pour un traitement automatisé, quel que soit le schéma de la base (plugins installés). Les clés primaires et les liaisons sont découvertes d’après les schémas pour les mises à jour [3]
Après avoir déclaré une base externe, l’import d’un site se fait en plusieurs temps :
- les tables principales de la source sont importées ligne par ligne sans leur clé primaire. Les objets changent donc d’identifiant, mais une table d’assemblage (spip_fusion) enregistre l’id original, l’id final, le type d’objet, et la base source.
- les liaisons entre objets sont reconstruites en reconnaissant automatiquement les clés primaires dans chaque table.
- les tables auxiliaires sont importées, en modifiant les clés primaires qui pointent sur des objets principaux.
- les documents et logos sont importés (si on précise le chemin absolu du répertoire IMG source). Les logos sont renommés avec les nouveaux identifiants des objets auxquels ils sont rattachés.
NB : Les logos pris en compte sont ceux des articles, des rubriques, des auteurs, des mots clés et des brèves (extensible facilement)
- les identifiants dans liens internes ->artXX ->XX -rubXX etc sont mis à jour pour pointer sur les nouveaux identifiants.
- les identifiants dans les modèles (img, doc, emb) sont mis à jour de la même façon.
Astuce : passer son site de sqlite à mysql
Si vous avez créé votre site avec une base de données en sqlite, et que pour diverses raisons vous voulez le passer en mysql, il n’y a pas vraiment d’outil le permettant facilement.
Mais avec ce plugin, c’est possible et même très simple :
- dans le répertoire /config, supprimer le fichier connect.php,
- vider complètement le contenu de /tmp (pour rebooter Spip)
- appeler l’url /ecrire pour relancer l’installation, choisir cette fois une base mysql,
- une fois le site installé en mysql, aller dans « Maintenance » / « Maintenance technique », et suivre les 3 étapes de « Déclarer une autre base » : choisir Sqlite3, sur l’écran suivant choisir la base sqlite existante, et valider jusqu’à « La nouvelle base a bien été déclarée ... » (cf paragraphe « 1 - Déclarer une base externe » ),
- lancer la fusion en choisissant comme source la base sqlite,
- « boire une bière et savourer la satisfaction d’un plan qui s’est déroulé sans accroc » (© b_b).
A noter que cette astuce marche aussi dans l’autre sens : passer de Mysql à sqlite, mais le besoin a été moins souvent exprimé.
Important : Les objets (articles, rubriques etc) vont changer de numéro en passant d’une base de données à l’autre. Si vos squelettes utilisent des numéros « en dur », il faudra les mettre à jour.
Discussions par date d’activité
35 discussions
Voulant migrer un site de sqlite à mysql, j’ai voulu pour cela me servir de "fusion".
J’ai donc effacé le connect.php, laissé spip initialiser sa bdd sur une toute nouvelle base mysql puis déclaré la base sqlite comme base externe.
Au moment de lancer la fusion j’ai toutefois un message d’erreur :
"Le site hôte et le site source ne sont pas dans la même version de base de données : hôte est en version 23375 / source est en version » (sans indication)
Pourtant c’est le même spip, sans upgrade entre temps ; la connexion à la base externe-interne sqlite semble bien se faire puisque l’exécution est bien arrivée jusque là, et lorsque avec adminer je vérifie la table spip_meta de la bdd sqlite, je vois que l’entrée "version_installee" vaut la même valeur 23375.
Faute de parvenir à franchir cette étape, je supprime le test du source et je relance la fusion.
Là ça importe bien, jusquà ce qu’une erreur de syntaxe sql soit signalée :
Je vois quand même que plein de contenu a déjà été importé : articles : 2724 - auteurs : 472 - documents : 6407 - evenements : 345 - formulaires : 1 - formulaires_reponses : 122 - formulaires_reponses_chams : 1051 - forums : 1813 - groupes_mots : 7 - mailshots : 197 - mailsubscribers : 1381 - mailsubscribinglists : 3 - menus : 2 - menus_entrees : 9 - messages : 281 - mots : 74 - newsletters : 233 - noisettes : 183 - partageurs : 4 - rubriques : 3 - seo : 5 - syndic : 16 - syndic_articles : 114 - zones : 1
Comment cela se fèce t-il ?
Salut,
Pas compris ce point là, tu peux expliquer ?
Sinon, il faudrait que tu puisses me fournir la base sqlite utilisée pour pouvoir reproduire l’erreur, mais elle vient de
id_objet, objetdans la clause WHERE.- Erreur de version de bdd : J’avais vérifié dans le code que le connect était bien renseigné ici. J’ai aussi essayé en simplifiant via un sql_getfetsel (sait on jamais...), sans succés. Pour désamorcer l’erreur de version de bdd j’ai finalement contourné le test en le commentant :
- Je vois avec les collègues pour te transmettre la BDD.
Je crois que j’ai pigé le probleme final avec la table spip_seo : c’est que la primary est composée : « PRIMARY id_objet,objet,meta_name » et le test « id_objet,objet,meta_name=12345 » déconne.
J’ai reformulé la réponse anté-précédente pour plus de clarté.
Une fois la fusion réalisée, les tables principales étaient bien importées : articles et rubriques et j’ai pu tester le site. J’ai alors constaté que les articles s’affichaient bien, mais *sans* la mise en page gérée par le noisetier. Pourtant le feedback indiquait que 183 noisettes avaient été importées. Je ne connais pas le noisetier, mais peut être lui faut il d’autres tables encore ? Ou recalcul. Groumpf, j’ai pas pensé à recalcul...
Mais toutes les tables n’ont visiblement pas été importées : les statistiques par exemple.
Répondre à ce message
Bonjour, je suis la procédure de déclaration de base en ajoutant connect_ à l’étape 3
ça me confirme que la base est déclarée mais rien n’apparaît dans le menu déroulant ensuite.
j’ai fais 3 fois l’essai et les noms s’accumulent mais toujours rien.
Où s’inscrivent les infos et que puis je faire ?
Merci d’avance
Désolé de la réponse tardive.
Est ce que ton problème a été résolu ?
non, je n’ai pas réussi
Tu tentes une fusion de deux bases MySql ?
Sur la page « Déclarer une autre base », tu vois bien la ou les bases externes déclarées ?
Tu peux faire une capture écran ?
J’ai essayé à plusieurs reprises, j’arrive visiblement à créer une base (vu que j’ai du donner plusieurs noms « nom existe déjà ») mais impossible de voir quoi que ce soit ensuite.
Où sont écris les infos du plugin car je me retrouve avec une base de données de plus de 100 mo, c’est carrément bizarre.
Le problème c’est que c’était un peu urgent et maintenant j’ai pas mal avancé sur le nouveau site, à voir comment réagencer propre...
Répondre à ce message
Bonjour ,
Je suis sur spip 3.2.1 en sqlite hébergé chez ovh .
Mon site www.amis-robespierre.org
J’ai suivi scrupuleusement les procédures indiquées pour passer mon site de sqlite en mysql
j’ai donc créé une base au préfixe spip.
- Au moment de renommer le site j’ai choisi un nouveau nom d’utilisateur et un nouveau login et mdp
- d’abord en local et j’ai appelé le chemin absolu pour le dossier IMG dont j’ai laissé les droits ouverts.
Le transfert s’est effectué sans problème : résultat impeccable logos rubriques et articles identiques.
- j’ai procédé de même sur le site à distance.
Au moment d’indiquer le chemin pour IMG : "/www/IMG la procédure m’indique :
le répertoire IMG n’existe pas.
Et le transfert n’est pas bon erreur 1064 à l’ouverture du site et pas d’images dans les articles.
J’ai indiqué le chemin aussi par copié-collé. Qui peut me dire comment indiquer le chemin absolu d’un dossier du site origine distant le même que celui hôte ?
Répondre à ce message
Impossible de vérifier la version de la base de données importée
Bonsoir,
Les deux sites sont à jour de la même version de spip 3.0.21 via le spip_loader.
Pourtant j’ai ce message d’erreur :
A la lecture de la table meta de chaque site je vois une différence :
base_version 62712sur l’une et pas sur l’autre.Ou bien cela pourrait-il être lié au fait que mes tables n’ont pas le préfixe de spip mais de « public » dans un cas et de « membres » dans l’autre cas ?
Que me suggérez-vous ?
Merci
J’ai le même soucis.
Bonjour,
le même souci c’est à dire ?
Deux bases avec des préfixes différents ?
Je ne crois pas avoir testé ce cas, je ne sais pas si quelqu’un a un retour là dessus.
Si le problème est là, tu peux déjà vérifier que le préfixe soit bien configuré dans le connect de la base source (pas hôte).
Ensuite :
prefixe_ parspip_ dans ce dump (avec le caractère backquote ` pour bien cibler les noms de tables),Pour la meta base_version, elle n’est pas utilisé, c’est version_installee qui est utilisée pour une comparaison.
Mais le message d’erreur indique effectivement un échec de connexion/lecture de la table spip_meta de la base source.
Effectivement c’est le préfixe qui posait problème. J’ai mis le même partout et c’est tout bon :) Merci !
Pour info, la version 1.3.3 devrait fonctionner avec les tables préfixées.
Une étape supplémentaire : éditer le fichier créé dans /config après avoir déclaré la table externe pour ajouter le préfixe.
Bonsoir,
Je viens de réussir une fusion entre deux spip-3.2.1-mysql tous les deux préfixés sur deux serveurs mutualisés OVH ; à part l’obligation d’aller modifier manuellement le fichier de connexion auxiliaire source (comme bien signalé dans l’article), cela semble être très bien passé...
La seule chose à faire : transporter par FTP (transfert en mode binaire) l’arborescence ./IMG de l’ancien site vers un ./ING du nouveau, et vérifier en y collant un fichier
realpath.phple chemin réel à donner en paramètre :Une astuce complémentaire : l’administration avancée des mots-clés permet de fusionner, dissocier et/ou ré-associer les mots-clés issus des deux sites fusionnés... Super !!
Enfin, il semblerait que la ré-indexation du contenu textuel des articles se fasse plus lentement après l’importation (un coup de « génie » ?) : une meme recherche sur un mot particlier -qui n’existait dans aucun article du site cible- n’a donné des résultats qu’une dizaine de minutes après la fin de l’importation !
Grand merci pour ce plugin !
YannX
Répondre à ce message
Bonsoir,
Yo nicod_ pour que tu jette un oeil ;)
Donc j’ai fusionné deux sites, après test et retest (ça veux dire que je reproduis)
Il s’avère que si l’on créer le secteur avec en première lettre une majuscule (Fusion par exemple), la fusion se réalise a la racine du site et pas dans le secteur désigné.
par contre si l’on créer le secteur sans majuscule (fusion), la on retrouve bien l’ensemble des donnés dans le secteur.
Répondre à ce message
Bonjour Nico,
Pour information, un petit retour d’expérience après avoir migré mon site de SQLite en MySQL en utilisant ton astuce ;-) (spip 3.2)
- J’ai noté un potentiel problème : si toute la base a été parfaitement importée, par contre les liens articles/auteurs est perdu. Donc tous les articles se retrouvent maintenant sans auteur.
- Bon à savoir : la numérotation des logos d’articles & rubriques n’est pas modifiée par le plugin, ils ne sont donc plus valables avec la nouvelle numérotation
- Bon à savoir 2 : avec Noizetier & Aveline, c’est la même chose : les numéros ne sont pas modifiés, toute la structure du site sera donc à refaire.
En tout cas, c’est un outil génial, merci :-)
Salut,
je n’ai pas restesté une conversion sqlite mysql sur SPIP 3.2, mais les deux problèmes que tu signales ne sont pas normaux.
Normalement toutes les tables de liens (auteurs_liens) sont mises à jour, et les logos sont renumérotés.
En tout cas c’est comme ça que ça fonctionne pour « tout le monde » :)
PS : pour info, tu as à la fin de la fusion une table spip_fusion qui indique les anciens et nouveaux id pour chaque objet, si tu veux recréer ou récupérer des infos dedans.
Pour info passage de sqlite spip 3.1.7 a sqlite spip 3.2 3.2
afin d’avoir les même version de bdd
puis passage a mysql sur spip 3.2
Ras ; bon dieu que c’est efficace ;)
Répondre à ce message
J’ai deux sites en SPIP 3.1.6 que je veux faire fusionner. J’ai bien suivi la procédure donnée sur cette page (le plugin utilisé est le dernier en 1.3.0 stable). J’ai bien récupéré la base externe, j’ai bien indiqué le secteur d’importation mais quand je lance la fusion j’ai le message :
— - DEBUT ---
Site en travaux
Attention : un problème technique (serveur SQL) empêche l’accès à cette partie du site. Merci de votre compréhension.
— - FIN ---
je suis dans le cas où :
- le site de destination est en mutualisation SPIP facile
- le site d’origine est sous forme de backup SQLite (ce que la doc dit être permis)
- je ne cherche pas à récupérer /IMG (que je récupèrerai autrement).
Merci de vos lumières.
Message annulé : il fallait simplement que le nom du fichier commence par
connect_(Et c’est même marqué dans la doc...)
Avec toutes les excuses pour bruit inopportun.
Répondre à ce message
NB : Vous devez affecter le nom par défaut « spip » du préfixe des tables des bases de données à fusionner avant d’utiliser le plugin.
Très bonne contribution !, j’ai réussi à fusionner trois bases de données à la fois sans problème. Milles merci.
Répondre à ce message
Bonjour
« L’import des documents et images de la source ne vérifie si des fichiers du même nom dans le /IMG de l’hôte existent déjà, auquel cas ils seraient écrasés. »
Que se passe-t-il dans le cas de figure des documents pour lesquels il n’existe pas de fichier ?
Ex. import sur le site hôte d’une base où la table document fait référence à des fichiers qui n’existent pas dans /IMG du site hôte ?
Suite à une fusion j’ai observé quelque mois plus tard un pdf appelé par
<\img550>
sur le site hôte (document créé après la fusion) alors que sur le site importé (qui existe toujours) la même balise avec le même identifiant affiche un jpg. Ce problème semble être la conséquence de la fusion.
Existe-t-il un mode opératoire permettant d’éviter ce genre de déconvenue ?
Valéry
Bonjour,
Pour chaque document de la source, le script fait une « bête » copie du fichier de l’IMG source (chemin renseigné dans les paramètres) vers l’IMG hôte.
NB : les objets de la source changent d’identifiants après la fusion, donc le document 550 sur le site hôte après la fusion n’est pas le même que le document 550 du site source.
Pour creuser un peu, la fusion crée une table de liaison qu’on peut consulter pour voir les transformations d’identifiants de chaque objet importé.
Répondre à ce message
Bonjour,
Je teste le plugin avec deux sites en 3.0.20. Lors de la phase de fusion, il m’indique cette erreur tout en haut de la page :
Warning : file_exists() : open_basedir restriction in effect. File(/var/www/vhosts/le-site-source/httpdocs/IMG/) is not within the allowed path(s) : (/var/www/vhosts/le-site-cible :/tmp :/usr/share/php) in /var/www/vhosts/le-site-cible/httpdocs/plugins/auto/fusion_spip/v1.0.4/formulaires/fusion_spip.php on line 100.
Et dans le cadre « Fusion de sites Spip », j’ai ce message :
Erreur lors de la fusion
• Le répertoire /var/www/vhosts/le-site-source/httpdocs/IMG/ n’existe pas.
Cela pourrait-il avoir un lien avec une restriction d’accès au dossier IMG sur le serveur source (bien qu’en l’espèce ce dossier soit accessible) ?
Cordialement,
Lafontanelle
C’est bien un répertoire qui est sur le même serveur ?
A priori, ça doit être un problème d’accès en lecture, sûrement une restriction d’accès.
Une solution pourrait être de copier le IMG source dans le répertoire du cite hôte (avec un nom différent, comme IMG_source), pour faire la fusion avec l’import des images, et de le supprimer ensuite.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
