SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 250 visiteurs en ce moment

Accueil > Administration et BDD > Import-Export > Fusion de SPIP > Fusion de SPIP

Fusion de SPIP

21 janvier 2014 – par nicod_ – 42 commentaires

18 votes

Importer et fusionner tout le contenu d’un autre site : textes, images, auteurs, liens, et sans se mélanger les pinceaux.

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 si des fichiers du même nom dans le /IMG de l’hôte existent déjà, auquel cas ils 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.

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 [1].
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.

PNG - 42.8 ko
Interface du plugin fusion

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 :

PNG - 19.7 ko
Exemple d’alerte (tables introuvables)

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 [2]

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 :

  1. dans le répertoire /config, supprimer le fichier connect.php,
  2. vider complètement le contenu de /tmp (pour rebooter Spip)
  3. appeler l’url /ecrire pour relancer l’installation, choisir cette fois une base mysql,
  4. 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 » ),
  5. lancer la fusion en choisissant comme source la base sqlite,
  6. « 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.

Voir en ligne : http://plugins.spip.net/fusion_spip

Notes

[1À titre d’exemple, j’ai importé sans erreur une base de démarrage au format SPIP 3.0.5 (http://contrib.spip.net/Base-de-donnees-de-test-pour-SPIP3) sur un SPIP 3.0.13

[2à part un ou deux cas particuliers sur les urls et les forums notamment

Dernière modification de cette page le 21 décembre 2015

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 22 juin à 11:19, par Valéry En réponse à : Fusion de SPIP

    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

    • Le 22 juin à 11:34, par nicod_ En réponse à : Fusion de SPIP

      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.

      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.

      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

  • Le 28 décembre 2015 à 23:37, par horetol En réponse à : Fusion de SPIP

    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 :

    Impossible de vérifier la version de la base de données importée (table spip_meta)..

    A la lecture de la table meta de chaque site je vois une différence : base_version        62712 sur 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

    Répondre à ce message

  • Le 15 septembre 2015 à 20:18, par Lafontanelle En réponse à : Fusion de SPIP

    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

    • Le 15 septembre 2015 à 20:41, par nicod_ En réponse à : Fusion de SPIP

      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

  • Le 2 septembre 2015 à 10:36, par Guillaume Blanc En réponse à : Fusion de SPIP

    Bonjour,

    J’ai tenté d’utiliser ce plugin pour passer mon site de sqlite en mysql. Les rapports d’utilisateurs disent que ça marche bien, mais je n’ai pas réussi.

    Je suis sur le même serveur, du coup le nouveau site mysql et l’ancien sqlite sont au même endroit. Le nom de la base est le même ??

    Je déclare ma base sqlite comme base externe, puis je lance la fusion, mais j’obtiens l’erreur : « Impossible de vérifier la version de la base de données importée (table spip_meta) »

    Est-ce que le plugin va bien chercher la base dans config/bases/XXX.sqlite ?

    Merci d’avance pour toute aide rapide !

    site : gblanc.fr
    hébergeur : OVH
    spip 3.0.17

    Guillaume Blanc

    • Le 2 septembre 2015 à 11:48, par Guillaume Blanc En réponse à : Fusion de SPIP

      J’ai fini par arriver à quelque chose (attention, la fin de la manip n’est pas indiqué, mon browser donnait une erreur de chargement de la page, mais visiblement des choses se sont passées...)
      Sauf qu’il y a pas mal de ménage à faire dans les rubriques, les articles, les n° sont différents, il y a des doublons...

    • Le 2 septembre 2015 à 12:08, par Guillaume Blanc En réponse à : Fusion de SPIP

      Bon, j’ai fini par arriver à quelque chose. Sauf que les n° des articles ont été chamboulés, donc tous les liens aussi. Impossible de tout reconstruire à la main. Tant pis. Dommage. Je reviens à mon sqlite, je trouverai une autre solution.

    • Le 2 septembre 2015 à 12:13, par nicod_ En réponse à : Fusion de SPIP

      Bonjour,
      effectivement les numéros des articles et des rubriques sont modifiés lorsqu’on fait une fusion.
      Mais tous les liens entres les objets sont mis à jour en conséquence (id_rubrique dans la table spip_articles, etc), donc à part si on utilise des ID en dur dans ses squelettes, ça reste transparent.

    • Le 2 septembre 2015 à 14:39, par nicod_ En réponse à : Fusion de SPIP

      J’ai ajouté cette précision dans le dernier paragraphe.

    • Le 2 septembre 2015 à 16:14, par Guillaume Blanc En réponse à : Fusion de SPIP

      Je ne suis pas sûr de comprendre. J’ai un lien vers un autre article du genre toto qui ne pointait plus du tout sur le bon article. Par ailleurs, je perds les liens externes si les N° sont chamboulés...

    Répondre à ce message

  • Le 19 mars 2015 à 03:45, par brain_damage En réponse à : Fusion de SPIP

    Je viens de tenter une fusion et tous les champs de la table importer avec des caractère accentué saute.

    -  > Ceci est un champ avec des caracères accentués avec plein de texte aprés
    devient
    -  > Ceci est un champ avec des carac

    SI vous avez une idée ou des suggestions je suis preneur :)

    • Le 19 mars 2015 à 04:33, par brain_damage En réponse à : Fusion de SPIP

      “Dans certains cas, il m’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’") ;”

      Héhé ça marche trés bien en fait, :) ça m’apprendra à lire en diagonale

    Répondre à ce message

  • Le 13 mars 2015 à 19:21, par Théo En réponse à : Fusion de SPIP

    Bonjour,

    J’ai hérité d’un site Spip3 (hébergé chez Free) avec une base de données SQLite 3. Apparemment le format MySQL serait mieux…

    Donc avec Fusion ça devrait pouvoir le faire malgré que c’est sur le même site et non pas d’un site à l’autre.

    Je résume (pas très rassuré de ce genre de manip’) :
    • Site source -> le fichier « mon_domaine.sqlite » sur mon bureau
    • Chemin physique des documents : -> tmp/dump/
    • Secteur : ->  ?

    Là, le débutant que je suis hésite sur quoi sélectionner comme dossier ?

    Répondre à ce message

  • Le 15 janvier 2015 à 11:57, par deor En réponse à : Fusion de SPIP

    Juste un petit retour d’expérience.

    Je viens d’utiliser ce plugin pour repasser un site en MySQL à partir de backup SQlite que le site n’arrivait pas à restaurer (plantage à la moitié de l’importation, des tables manquantes, bizarrement).

    Après avoir testé pas mal de solutions différentes, c’est vraiment ce plugin qui m’a sorti de la panade.

    Merci beaucoup.

    Super boulot.

    • Le 15 janvier 2015 à 12:05, par nicod_ En réponse à : Fusion de SPIP

      Merci, et content que ça ait pu te dépanner.
      Ce n’était pas le but initial du plugin mais c’est vrai que cette manip marche très bien.

    Répondre à ce message

  • Le 7 janvier 2015 à 11:19, par Pierrot En réponse à : Fusion de SPIP

    Un petit commentaire après une nuit (bon disons plutôt une longue longue soirée) de galère pour préciser un point qui me semble-t-il était mon problème : il faut que les bases que l’on fusionne soit sur le même « storage engine », donc soit toutes les 2 myISAM (mon cas) soit aussi probablement toutes les 2 innoDB (pas testé).

    J’essayais d’importer une myISAM dans une innoDB, 6 essais infructueux avec corruption de la base hôte ... spip à réinstaller, ...

    Ma base hôte n’avait pas (plus après nettoyage) d’articles (mais un gros paquet de contacts/organisations et de mots-clés) .

    D’un point de vue « logique », je ne suis pas sûr de comprendre pourquoi (on fait des requêtes SQL donc ...), la preuve étant que certains se servent du plugin pour passer de SQLite à mySQL, je ne referai pas une 7 ème tentative pour tester un contre-exemple, mais bon, mon commentaire pourrait être une piste à explorer pour ceux qui ont des pbms.

    Moi ça importait partiellement et ensuite ça tournait sans fin ... le résultat était un import partiel jusqu’au milieu d’une certaine rubrique, donc c’était peut-être un truc dans un article qui coinçait et le fait d’avoir basculé la base hôte en myISAM a corrigé la chose ... ou un pbm d’index ... ?

    Répondre à ce message

  • Le 28 décembre 2014 à 18:09, par spipfactory En réponse à : Fusion de SPIP

    Hello tous ça pour dire que la partie : Astuce : passer son site de sqlite à mysql est une merveille

    trois sites on subi le transfert seul Hic Le passage de sqlite à mysql a perdu la numérotation existante des articles, si bien que les diaporama de galleria ne fonctionnaient plus, ainsi que GIS.

    alors du coup j’ai bu enfin ma bière ;)

    Répondre à ce message

  • Le 4 novembre 2014 à 12:40, par tcharlss En réponse à : Fusion de SPIP

    Bonjour,
    J’ai tenté de fusionner 2 sites en SPIP 3.0.17.
    Après le choix du site source, j’ai le message d’erreur suivant :

    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 19268
    -  source est en version

    La version de la base de données du site source n’est donc pas détectée.
    Après inspection, la meta version_installee n’est présente ni dans le site source, ni dans le site hôte.
    Bref, en désactivant cette vérification dans le formulaire, j’ai pu forcer la fusion, qui s’est correctement déroulée.

    -  Peut-être faudrait-il se reposer sur une autre méthode pour détecter la version de la bbd de la source ?
    -  En cas de différence de version, il faudrait avoir une option pour ignorer l’erreur, comme c’est suggéré dans la doc.

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Adaptive Images

    15 novembre 2013 – 66 commentaires

    Un plugin pour permettre aux sites responsive d’adapter automatiquement les images de la page à l’écran de consultation. Adaptive Images, que l’on pourrait traduire par Images adaptatives, désigne la pratique qui vise à adapter les taille, (...)

  • Métas

    8 août 2009 – 50 commentaires

    Ce petit plugin permet l’ajout, depuis l’espace privé, de metatags aux articles et rubriques de SPIP, ainsi que la mise en exergue de mots importants.

  • Brownie

    6 juillet 2012 – 43 commentaires

    Brownie est une adaptation pour Zpip du thème du même nom initialement développé par Egrappler.com. Présentation Brownie est un thème Responsive à deux colonnes. La démonstration ci-dessous utilise la version 2.0.0 de Brownie, la dist de SPIP3 (...)

  • Métas +

    3 décembre – 13 commentaires

    Améliorez l’indexation de vos articles dans les moteurs et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card. Installation Activer le plugin dans le menu dédié. Dans le panel de configuration, (...)

  • Acces Restreint 3.0

    11 décembre 2008 – 785 commentaires

    Le plugin accès restreint permet de définir et de gérer des zones de l’espace public en accès restreint. Cette version du plugin a été redévelopée et optimisée tout spécialement pour SPIP 2.0. Il en découle une amélioration des performances sur les gros (...)

Ça spipe par là