Fusion de SPIP

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 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.

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 :

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

Notes

[1En cas d’utilisation d’un préfixe non standard, vous référer à la note en PS ci-dessous.

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

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

PS : Quand on déclare une nouvelle base qui possède des tables préfixées (avec un préfixe différent de spip_, l’interface ne propose pas d’indiquer le préfixe : il faut éditer après coup le fichier créé dans /config, manuellement par FTP dans le fichier secondaire de connexion source et l’ajouter dans le paramètre suivant le type de la base de données.

Discussion

35 discussions

  • 4

    j’ai suivi pas à pas la démarche mais ma base finale est toujours lite et non mysql.
    merci de m’indiquer ou est le pb

    • Tu as suivi la procédure pour passer de sqlite à Mysql ? ou l’inverse ?

      Et que contient le fichier /config/connect.php ?

      Attention : il y a un mot de passe dans ce fichier, ne le colle pas ici publiquement tel quel

    • j’ai spip 3.1 et si je passe en 3.2 j’ai une erreur
      donc l’idée c’est faire passer ma base sqlite vers mysql
      j’ai suivi ce protocole
      De SQLite a MySQL & Inversement grâce au plugin Fusion
      -  
      je n’ai pas de fichier connect.php
      -  
      A la fin ma base est toujours en sqlite et chaque article est répété 3 fois ????

    • Si tu suis la procédure en 5 points, après le point 3 (connexion à la base mysql) tu dois avoir un fichier /config/connect.php qui se crée.

      Sinon c’est qu’il y a un problème et la suite ne peux pas marcher.

      A la fin ma base est toujours en sqlite et chaque article est répété 3 fois ????

      Tu avais bien fait une sauvegarde de ta base sqlite avant ?
      Si oui, tu remets ce fichier en place pour repartir.

    • si j’ai un fichier connect.php

      <?php
      if (!defined("_ECRIRE_INC_VERSION")) return;
      defined('_MYSQL_SET_SQL_MODE') || define('_MYSQL_SET_SQL_MODE',true);
      $GLOBALS['spip_connect_version'] = 0.8;
      spip_connect_db('mybase.mysql.db','','userndo','mdp','userpar','mysql', 'spip','','utf8');
      

    Répondre à ce message

  • 6

    Bonjour,
    je bute sur une erreur 504, peut-on relancer la fusion (reprise) ou ce n’est pas prévu ?
    Clt

    • Un timeout ça peut arriver oui, si la base est volumineuse ou le serveur pas trop véloce...

      A titre de prévention il y a deux ini_set : https://git.spip.net/spip-contrib-extensions/fusion_spip/src/commit/25fda79936df3b831af5cd557e4fa2d6d5cd8fdd/formulaires/fusion_spip.php#L128
      mais ça ne marche pas partout.

      Et non, il n’y a pas encore de traitement par lot qui permettrait de reprendre le traitement.
      Il y a une table spip_fusion_spip qui est mise à jour au fur et à mesure du traitement des bases, mais je ne sais pas si ça pourrait suffire à « redémarrer » un traitement sans risquer de créer des doublons. Il faudrait s’y repencher mais ce n’est pas dans mes priorités actuelles.

      Dans les cas désespérés, il m’est arrivé de faire la fusion sur un autre serveur que celui où le site est hébergé (ou en local), si vraiment il n’y arrive pas, puis de retransférer un dump des sites fusionnés.

    • Et non, il n’y a pas encore de traitement par lot qui permettrait de reprendre le traitement.

      trop tard, J’ai testé !
      un clic est si vite arrivé... :-)

      A titre de prévention il y a deux ini_set

      je suis pas dev :
      ça se règle comment ?

      Si spip retrouve ses petits en rapatriant les doc après, je peux le faire en deux temps car avec 2,5Go c’est le gros du volume, (la base étant riquiqui)
      Dans le pire des cas, je travaillerai sur une copie du site de départ après avoir donné un « coup de balai* » pour l’alléger au lieu de le donner après fusion

      * bon plugin complémentaire à fusion

    • Bonjour,
      Bon, en 2021, c’est passé, en 2023, ça casse
      J’ai tout transféré chez mon hébergeur, là pas d’erreur 504, juste le foutoir
      tous les objets sont bien créés (auteurs, articles, rubriques, documents...
      Pas de lien auteurs/article
      toutes les rubriques avec la même id parent, y compris la rubrique parent elle même ???
      tous les id secteurs à 0
      toutes les profondeurs à 5
      Pas de log « fusion »

    • Petites précisions pour d’éventuels visiteurs :
      Il s’agissait de SPIP 3.2.19
      -  Je suppose (peut être à tort) que les modifs de 2022 ont cassé quelque chose pour la version 3.2, mais comme elle n’est plus maintenue, cela n’a pas d’importance.
      -  En l’absence d’explications, je n’ai pas pu tester les init_set

      Il semble également, « d’après internet » que les réglages de timeout peuvent être modifiés sur le serveur apache ou pris en compte par le programme pour traiter par « petits lots » afin de les éviter.
      Mais bon, on voit tout et n’importe quoi sur internet et je suis pas dev :
      je ne peux donc pas valider la véracité de ces informations, ni les tester ;-)
      Clt

    • Salut,

      effectivement les traitements peuvent être longs si la base est volumineuse (je parle bien de la taille de la base de données, pas du « poids » du site lui même avec ses documents et tout).

      D’où les deux directives « ini_set », qui sont là pour tenter de corriger le problème de la durée du traitement, mais en fonction de l’hébergement et de la configuration PHP elles ne sont pas toujours effectives.

      Si tu as la main sur le php.ini ou équivalent (la configuration de PHP) sur ton serveur, tu peux tenter d’y modifier la config de limite de mémoire et de limite de temps (cf documentations de ton hébergement).
      Mais c’est tellement dépendant de l’hébergement qu’il me serait impossible de documenter tous les cas possibles.

      Et sinon sur le fond de ta question :

      Je suppose (peut être à tort) que les modifs de 2022 ont cassé quelque chose pour la version 3.2

      le plugin est censé fonctionner aussi bien sur SPIP 3.2 que 4 voir 4.2

    • Bonjour nicod_
      Comme je ne sait pas comment paramétrer ces « Init_set », je n’ai pas pu tester

      Comme spécifié,
      En 2021 aucun problème de timeout avec une base similaire (et un serveur local asthmatique)
      En 2023 chez mon hébergeur, aucun timeout, aucune erreur apparente, mais le résultat indiqué.
      Après, je ne fait qu’établir un constat sur mon cas perso et un spip 3.2 basique

      je parle bien de la taille de la base de données

      Coté base de données, il est fort heureux qu’on n’a plus à utiliser le terminal pour sauvegarder/ restaurer etc ;-)
      Perso, je me contente de comparer des enregistrements et d’essayer d’en tirer une logique à partir du résultat visuel dans spip
      La base faisait 3, 8Mo , j’ignore si c’est « gros »
      Je suis descendu à seulement 20 articles mais sur mon serveur local, le timeout existait toujours...
      toutefois il y avait les bonnes liaisons
      Du coup, j’y suis allé par paquets de 20 avec pour conséquences de nombreuses duplications de données (auteurs, rubriques principales).
      Après la 2e passe un ancien collègue a déterminé les requêtes pour recoller le tout à chaque passe
      Il me suffisait ensuite de détruire les enregistrements en surnombre.

      tu peux tenter d’y modifier la config de limite de mémoire et de limite de temps

      J’ai indiqué ce que j’avais « trouvé », uniquement comme piste de travail pour des utilisateurs aguerris qui auraient les mêmes problèmes que moi.
      Comme je te l’ai déjà dis je ne suis pas dev, c’est l’avantage de choisir un CMS et des pluging spécialisés :
      Faire quelque chose de basique sans avoir à connaitre quoi que ce soit en informatique

      Cordialement

    Répondre à ce message

  • Bonjour,

    pour info sur un environnement spip 4.2.4 la migration sqlite => mysql c’est bien passé et ma permis de résoudre

    https://discuter.spip.net/t/passage-4-2-3-a-4-2-4-probleme-espace-prive/171113/3

    ps/ j’avais du changer les bornes du paquet.xml
    compatibilite=« [3.0.0 ;4.1.*] » ===> compatibilite=« [3.0.0 ;4.2.*] »

    Répondre à ce message

  • 2

    Après fusion est-il possible de savoir quels objets (auteurs, rubriques, articles) proviennent de la source et lesquels sont issus de l’hôte ?

    • Toutes les opérations de fusion sont inscrites dans la table spip_fusion_spip, avec une ligne par donnée importée : le nom du site source, le type d’objet (article, auteur, etc), l’identifiant (numéro) d’origine et le nouvel identifiant après import.

      Il y a aussi une entrée dans le menu « Maintenance » qui permet de retrouver un objet par son id d’origine ou final, qui utilise justement cette table, mais ça ne donne pas une liste complète (qui pourrait être très longue et pas forcément utile).

    • Merci pour cette réponse détaillée !

    Répondre à ce message

  • 1

    Que se passe-t-il lorsque il existe deux utilisateurs (éditeur, contributeur) avec un même login sur chacune des installations à fusionner ?
    Est-ce qu’à l’arrivée on a un seul utilisateur qui reste auteurs des tous les articles provenant des deux sites ?
    Est-ce que l’on a deux utilisateurs différents ?
    Est-ce que les auteurs ne sont pas recréés ?

    • Les auteurs du site source sont importés tels quels.
      S’il y a un auteur sur le site source avec le même login que celui du site hôte, il apparaitra donc deux fois, avec le même login mais avec un identifiant (numéro) différent.
      Les liens de cet auteur importé (articles, etc) seront aussi importés dans les tables spip_*_liens, avec ce nouvel identifiant.
      Le plugin ne gère pas la consolidation (fusion) des auteurs ayant un même login.

    Répondre à ce message

  • Bonjour,
    J’ai un problème dès le 1/3, la déclaration de la base : « Il y a 1 erreur dans votre saisie, veuillez vérifier les informations. ».
    J’ai réessayé plusieurs fois, avec les champs que j’avais sauvegardés, avec les champs dans connect.php, à chaque fois j’ai cette erreur, qui n’est pas détaillée.
    Les deux sites sont sous la même version de SPIP.
    Une idée ?
    Merci beaucoup.

    Répondre à ce message

  • 8

    Salut,

    mysql_query() est supprimée en PHP 7.0 : https://www.php.net/manual/fr/function.mysql-query.php

    après quelques recherches, il semble conseillé d’utiliser mysqli_set_charset :

    C’est la meilleure façon de modifier le jeu de caractères. Il n’est pas recommandé d’utiliser la fonction mysqli_query() pour le définir (comme avec la requête SET NAMES utf8).

    Voir la 2e note https://www.php.net/manual/fr/mysqli.set-charset.php#refsect1-mysqli.set-charset-notes

    Quelle est la syntaxe a utiliser du coup ?

    Merci

    • J’imagine qu’il faut utiliser la syntaxe conseillée, non ? ^^
      Enfin, en fonction de la version de PHP.
      Et du coup, mettre à jour la doc du plugin si tu me confirmes que ça marche bien.

    • Ça serait avec joie mais le truc, c’est que je trouve pas la bonne syntaxe du coup :)

      La doc PHP indique :

      mysqli_set_charset ( mysqli $link , string $charset )

      quand la doc du plugin indique :

      mysql_query("SET NAMES 'utf8'");

      Et je ne vois pas comment faire la conversion malgré mes recherches (j’ai tenté plusieurs trucs mais j’ai toujours des erreurs :( )

    • Le $link en question est à priori dans le tableau $GLOBALS[’connexions’], qui stocke en globale tous les liens mysqli ouverts.

      L’index 0 est le lien principal (celui déclaré dans /config/connect.php), il faut juste réussir à trouver le bon index dans le fichier connect de la base source...

    • hum... c’est la partie après le juste qui me pose problème :

      trouver le bon index dans le fichier connect de la base source

      Ca doit dévoiler un peu mon faible niveau en PHP :)

    • Je ne crois pas que ce soit la bonne piste en fait, il n’y a rien dans $GLOBALS[’connexions’] à cette étape là. Faudrait que je creuse un peu...

    • Bon, j’ai repassé l’hébergement en PHP 5.6 pour pouvoir utiliser mysql_query() mais j’ai toujours un problème de caractères, notamment avec des émojis dans le texte, par ex 📣 (no comment, je ne suis pas rédacteur du site ^^).
      Les accents, eux, semblent bien passer...

    • Ça doit venir d’un problème d’encodage de la base / des tables.

      https://stackoverflow.com/questions/39463134/how-to-store-emoji-character-in-mysql-database

      1) Database : Change Database default collation as utf8mb4.

      2) Table : Change table collation as CHARACTER SET utf8mb4 COLLATE utf8mb4_bin.

      Query : ALTER TABLE Tablename CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin

      (pour toutes les tables donc, enfin au moins spip_articles et quelques autres)

    • j’ai essayé dans phpMyAdmin

      ALTER TABLE spip_articles CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin

      mais j’ai une erreur

      #1067 - Valeur par défaut invalide pour 'date'

      J’ai donc changé manuellement dans mon fichier sql cible (j’ai une sauvegarde d’un SPIP vide avec juste la config de base pour ne pas avoir à tout reprendre à chaque fois), avant import dans phpMyAdmin

      ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE utf8mb4_bin;

      du coup, les émojis sont remplacés en bases par des ????.

      La base, elle, est bien en : https://pic.infini.fr/YGvbsafJ/buEtM73S.png

      Bref, on n’est pas sorti des ronces !

    Répondre à ce message

  • 8
    olivier

    Bonjour,
    Existe-t-il un plugin ou un moyen, après la fusion, pour fusionner les auteurs et pour « creer » des liens de traductions ?

    J’ai fusionné deux sites, un en francais et un an anglais, qui étaient en sqlite sur deux domaines différents, vers un seul site sur mysql.
    Comment puis-je lier les articles traduits un à un ? (une vingtaine : je peux le faire à la main)

    Je dois aussi fusionner les auteurs en double.

    • olivier

      pour les auteurs, le plugin RAO devrait faire l’affaire

    • RAO ? Kézako ?

      Pour la fusion des auteurs, j’y ai déjà pensé et c’est en projet, j’essaierai de développer quelque chose si je trouve un peu de temps pour le faire.

      Par contre, pour lier les articles des deux sites, je ne vois pas trop comment faire : comment savoir qu’un article est une traduction d’un autre ?
      Le multilinguisme peut être géré de tellement de façons différentes que ça me parait difficile de trouver une solution générique.

    • olivier

      plugin Réassocier auteurs objets (RAO) : ça a bien marché

      Multilinguisme : ok. je vais essayer de me baser sur la table qui gère les liens de traduction entre articles, et la modifier à la main.
      par exemple : depuis un article X, créer une traduction de cet article (l’entrée id_article_Y dans la table est créée) ; puis modifier la base pour remplacer id_article_Y par id_article_Z ; et enfin mettre article Y à la poubelle.

    • Ah super, je ne connaissais pas ce plugin.
      On en apprend tous les jours avec SPIP :)

      Pour le multilinguisme, qu’on se comprenne bien : dans les deux sites de départ, tu n’avais pas de liens de traductions ? ou bien ils ont été perdus après la fusion ?

    • olivier

      tout à fait, il n’y avait pas de liens de traduction (2 spips distincts). Il faut les recréer.

    • olivier

      les créer, plutôt

    • olivier

      pour conclure, la procédure de création des liens de traduction a posteriori fut assez facile à faire à la main.
      Sur un bout de papier, noter les id des articles de référence, et les articles traduits à associer.
      Dans phpMyAdmin (la première fois que je l’utilisai), via mon hébergeur ovh, il suffit de regarder la table spip_articles. il y a une colonne id_trad, qui vaut zéro par défaut.

      Il suffit de remplacer « 0 » par le numero de l’article de référence de la traduction.
      ex : si l’article en anglais n°4 doit correspondre à l’article en français n°76, alors
      il faut mettre « 4 » dans la colonne id_trad sur la ligne de l’article 4 et sur celle de l’article 76

    • Parfait, content que tu t’en sois sorti, et merci pour le lien vers le plugin RAO :)

    Répondre à ce message

  • 8

    Bonjour, je travaille « en local » (Linux Ubuntu) sur un serveur Apache, et j’utilise la mutualisation de Spip. Les deux sites que je cherche à fusionner sont donc sur le même serveur, et utilisent le même serveur MySql.
    J’ai bien déclaré ma base de donnée source comme base externe de mon site hôte.
    Or, lorsque je lance la fusion, je reçois le message 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 23375
    - source est en version 

    Le message d’erreur n’en dit pas plus.
    Pour moi, la version de base de données est la même, puisque les deux bases sont sur le même serveur. Qu’est-ce que j’ai raté ?
    Merci,
    Eric LM

    • Les bases peuvent être sur le même serveur, mais ne pas correspondrent à la même version de SPIP (c’est ce que dit le message, même si bizarre qu’il aille plus loin).

      Sans connaitre le plugin je dirais : s’assurer d’avoir la même version sur les deux sites avant de tenter la fusion.

    • Bonjour Maïeul, les deux sites sont sous la même version de Spip, puisque j’utilise la mutualisation. Ils sont tous les deux sous Spip 3.2.7 [24472]

    • aucune idée alors :(

    • Bonjour,

      c’est une erreur qui apparait quand la clé version_installee ne peut pas être lue (ou est vide) dans la table spip_meta du site source.

      J’ai mis à jour le plugin pour que cette erreur ne soit plus bloquante, elle génère maintenant uniquement un avertissement qu’il suffit de confirmer.

      La nouvelle version 1.3.4 devrait être disponible rapidement dans les mises à jour des plugins (d’ici quelques heures au maximum), sinon elle est déjà disponible ici en ZIP : https://git.spip.net/spip-contrib-extensions/fusion_spip/releases

    • Un grand merci ! Je vais tester cela demain mercredi, et je reviens vers vous. Bonne journée !

    • Bonjour nicod_ merci pour la mise à jour. En fait, ça n’a pas fonctionné (cf copie d’écran). Mais j’ai ajouté la valeur version_installee dans la table spip_meta, avec comme valeur celle indiquée pour mon site hôte (23375) j’ai relancé l’importation, et celle-ci s’est bien déroulée. Je pense avoir tout récupéré.
      Merci encore,
      Eric LM

    • Merci pour le retour.
      D’après ce que je vois sur la capture écran, en fait il fallait juste cocher « Confirmer la fusion » pour poursuivre sans tenir compte de cette erreur.
      Mais bon, au moins le message d’erreur est plus explicite maintenant, et ça t’a permis de t’en sortir, c’est parfait.

    • Ah... désolé ! Mais oui, le message est plus explicite. A bientôt !

    Répondre à ce message

  • 2

    bonjour,
    j’ai des sites sous SPIP 3.2.7 [24473] , et pas de « Maintenance » -> « Maintenance technique », puis choisir « Déclarer une autre base ». mais « Maintenance » -> « Maintenance technique »,
    Réparer la base de données !!
    Comment fait-on SVp ?

    • Bonjour,
      tu es bien webmestre du site ?
      (à vérifier dans « Mes informations personnelles »)

    • bonjour,
      absolument : cela dit :
      "AUTEUR NUMÉRO 1
      Je suis administrateur
      Je suis webmestre
      Je gère toutes les rubriques"

      MAIS sur 3 sites en config et versions identiques, sur 2 je n’ai pas cette commande visuellement (« Déclarer une autre base ». ) et seul 1 site l’a (mais celui sur lequel je n’ai pas besoin de faire la manœuvre). Stable non ? Ce n’est donc pas le critère "webmestre" seul qui conditionne l’accès à cette commande ! Lequel alors ?

    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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

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

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom