Fusion de SPIP

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 :

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.