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.

Footnotes

[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

29 discussions

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

    Reply to this message

  • Petit retour d’expérience (avec SPIP 3.0.17)

    Ce plugin marche au top !!

    Notre principale difficulté a été de le retrouver une fois installé... En effet, il n’apparaissait pas dans le menu “Maintenance” !!
    Pour y accéder, il suffit donc de visiter la page ecrire/?exec=fusion_spip

    Et après un clic sur le bouton, plein de warnings php, tous identiques au nom de l’image près, qui nous ont fait craindre que les copies du dossier IMG2 ne se soient pas faites dans IMG !!

    Warning: copy(../IMG/vignettes/mon_image.jpg): failed to open stream: No such file or directory in /home/le_site_hote/www/plugins/auto/fusion_spip/v1.0.3/inc/fusion_spip.php on line 490”

    Mais en fait, tout va bien, tout est bien copié... 600 articles fusionnés en 15 secondes chrono, ça c’est ce que j’appelle de l’efficacité !!

    Reply to this message

  • 9
    Thomas

    Bonjour,
    Je suis en train d’effectuer la fusion définitive entre deux bdd, avec IMG, dont j’avais fait un premier essai tout à fait concluant en janvier avec votre aide (cf. [spip3] fusionner 2 bdd sur le rezo).

    Donc j’ai à nouveau mis à niveau une base depuis spip 2.1.23 vers 3.0.13, mis sa sauvegarde (.sqlite) dans le config/bases du site hôte (en 3.0.13), déclaré cette nouvelle base (acceptée avec toutes ses tables). + copié cette fois un dossier IMG (/IMG2)
    Or cette fois, la fusion ne se lance pas, j’ai toujours le message “Cette information est obligatoire” sur le champ du site source de l’interface du plugin, alors que la source est bien renseignée (ma_base.sqlite) et qu’elle est bien reconnue en tant ’Base supplémentaire déjà interrogeable’ par spip....
    Comprend pas...

    Help ?
    Merci
    T

    • Thomas

      Bon et bien après divers essais infructueux, avec une base rendue le plus similaire possible à celle devant l’accueillir (configs de spip, plugins..), le meilleur résultat fut une fusion qui “fonctionna” en ajoutant bien les rubriques mais hélas sans contenus..

      Ensuite :
      -  réinstallation d’un spip 3.0.13 en local en lui attribuant cette fois un nom de base identique à celui de la base devant la recevoir,
      -  nettoyage au maximum de cette base (simplification de l’arborescence, suppression d’articles en attente depuis longtemps etc..),
      -  sauvegarde de la base en lui donnant le nom exacte de la base hôte (base_nom_identique.sqlite)
      -  > import dans le config/bases/ du site distant hôte
      -  > déclaration de la base : ok
      -  > ajout du mysql_query("SET NAMES 'utf8'"); dans le fichier base_nom_identique.php
      -  > renseignement des champs du plugin fusion (base, chemin dossier images, rubrique dans laquelle verser le tout.
      => Fusion ? Ah, cette fois ça marche, il y a toutes les rubriques, ss-rubriques et articles. Sauf que... :
      -  tous les articles précédemment supprimés (“à la poubelle”) lors du ménage en local se retrouvent maintenant parmi les traductions des articles !!!
      En effet sur ce site les articles possèdent une traduction en anglais, donc on a 2 articles (fr + en) mais là, les articles se retrouvent avec d’autres traductions (5, 6, 7...) constituées par des articles précédemment mis à la poubelle...
      -  Les documents (source) n’ont pas été intégrés au IMG (hôte) et donc les liens sont rompus. Bon, ça on peut le faire à la main...

      Je ne crois pas (connais pas) qu’il y ait un moyen de forcer spip à vider sa base des articles mis à la poubelle, avant d’effectuer une sauvegarde (puis une fusion)...
      Quelqu’un aurait-il une piste à ce sujet ? ou pour faire en sorte que la fusion ignore les articles supprimés ?

      Merci
      T

    • Pour le premier problème, le message d’erreur « Cette information est obligatoire » indique qu’aucune base de données source n’a été sélectionnée.
      Le champ select (liste des bases sources) était bien renseigné, avec le nom de la base source dedans ? et elle était bien sélectionnée ?

      Pour le deuxième problème, le plugin Corbeille permet de supprimer définitivement de la base de données les articles (ainsi que forums et autres) à la poubelle.
      Par contre, pourquoi avoir nommé la base source avec le même nom que la base hôte ? ça risque plus de poser des problèmes que d’en résoudre.

      Après ça, s’il y a des erreurs de fusion (articles vides, mélangés ou autres) c’est assez difficile à debugger à distance, dans ce cas je peux faire des tests en local de mon côté mais il me faudrait une copie de chaque base de données (sans les données personnelles, emails et autres).
      Tu peux me contacter en privé par le foormulaire de contact.

      Pour la base source, inutile de la nettoyer (config, plugins, articles anciens etc). S’il y a des plugins différents ça génére un message d’avertissement, mais c’est juste un rappel, ça ne causera aucune erreur.

      Pour l’import des documents (IMG), c’est bien le chemin absolu vers IMG2 qui était indiqué ?
      Chemin absolu = chemin complet sur le disque dur, pas l’adresse web avec http://

      Sous Linux, ça peut ressembler à qqchose comme ça : /home/compte/www/site/IMG par exemple
      Sous OS X : /Users/compte/Sites/site/IMG
      Et sous Windows, j’imagine qqchose comme C:\Program Files\Easy PHP\www\IMG
      (tout ça à adapter très largement)

    • Thomas

      Merci Nicod pour ta réponse.
      -  Alors pour le premier point, oui bien entendu le champ select du plugin était bien renseigné avec les nom de la base à fusionner (sélectionnée). Il m’a mis le message “Cette info est obligatoire” quasiment à toutes mes tentatives, nombreuses, de fusion. (La base avait été déclarée sans problème).

      -  Merci pour le plugin Corbeille, je vais essayer sur ma base à fusionner.

      -  Pour le fait de nommer la base source du même nom de la base hôte, et bien c’est ce que j’ai essayé au bout d’un moment, en désespoir de cause...
      Mes premières tentatives de fusion concernaient une base source nommée différemment que celle de l’hôte (ça devait être d’ailleurs le nom par défaut “spip”) et un fichier nom_du_site.sqlite... mais sans succès. Ensuite j’ai remonté un spip local pour lui donner le même nom de base que celui de la base hôte.. nouvel essai de fusion avec toujours un fichier nom_du_site.sqlite... sans succès. Enfin j’ai essayé en renommant le fichier sqlite du même nom que celui de la base hôte nom_base_hôte.sqlite et là ça a marché. (Je ne me souviens pas d’autres actions avant cette tentative, si ce n’est les choses habituelles : suppression du Nom_de_Base.php + _sqlite3_install.sqlite dans ’bases’, vidage du cache, redéclaration de la base renommée...).
      Donc c’est avec un fichier sqlite du même nom et contenant la base du même nom que la base hôte que ça a marché... (mais en intégrant les articles-poubelle en traductions d’articles).

      -  J’ai nettoyé la base source pour gagner du temps en réfléchissant à ce que je pouvais faire (et éventuellement en attendant une réponse d’ici). De toute façon c’était à faire donc autant le faire avant qu’après la fusion.

      -  Pour le dossier IMG2, dont le nom trahit mon inspiration de l’expérience d’Yves ci-dessous, j’ai mis le même chemin que lui (d’après ce que j’ai compris) certes relatif : ../IMG2 (en fait c’est ../images, nouveau nom donné à l’occasion d’une de mes tentatives). Ce dossier est à la racine du site, avec les autres dossier dont IMG..
      Le site hôte est sur un serveur apache distant dont le chemin est /home/thomas/spip. Donc je vais essayer avec : /home/thomas/spip/images
      D’autre part j’ai tendance à éviter les majuscules dans les noms de fichiers et dossiers et d’ailleurs je crois bien qu’une tentative de fusion à marché après avoir modifié le nom de fichier sqlite : depuis Nom_de_Base.sqlite vers nom_de_base.sqlite (mais cette fusion à générée des rubriques sans contenus : les secteurs de la base source se sont bien mis dans la rubrique hôte sélectionnée mais sans leur contenus).

      Voilà, désolé de raconter un peu ma vie mais je me dis que ces détails peuvent t’être éventuellement utiles même s’il manque le contexte précis.

      Bien, j’essaye avec une nouvelle base source débarrassée des contenus supprimés, un chemin absolu pour le dossier “images” , et on verra.

      Un grand merci, merci pour ta proposition d’aide en privé (ce n’est pas exclu si décidément ça ne veux pas....)
      T

    • Thomas

      Je vais mettre un petit moment avant de refaire une tentative car je me suis aperçu que la plupart des traductions des articles de la base source n’étaient pas basculés en “english” mais restés en “français”.... oh my god... les rédacteurs (et admin) font parfois n’importe quoi... (et s’il n’y avait que ces gestions des trads...).
      Donc je revois toute la base..

    • Pas de problème avec le fait de raconter toute la procédure et les essais, c’est du concret et ça fait un peu de littérature pour ceux qui s’intéressent au plugin :)

      Pour les chemins vers les documents, je confirme, il faut bien indiquer un chemin absolu (/home/thomas/spip/images) et pas relatif (../images).

      C’est un peu contraignant, mais dans ma conception de l’utilisation du plugin, on doit pouvoir fusionner un autre SPIP hébergé sur le même serveur mais à un emplacement différent., pour ne pas avoir à copier des gigas de documents inutilement.
      Et l’utilisation est plutôt pensée pour des utilisateurs avertis, qui à priori doivent connaitre le chemin absolu d’un répertoire sur leur serveur (ou sur leur poste).

    • Je n’avais pas testé le multilinguisme en particulier, mais comme les enregistrements sont copiés ligne à ligne et avec tous leurs champs, je suis confiant : les langues et id_trad suivront lors de l’import des articles sources.
      Par contre, il faudra bien sûr reconfigurer les langues de la même façon sur le site hôte.

    • Thomas

      Je suis aussi confiant, le bordel sur la base source est assez indescriptible donc qu’on obtienne un truc bizarre au final est normal... Cette fois, ça devrait aller mieux.
      Mais c’est long de nettoyer une base (ou les gens mettent des div et ce, pour tout.. de br à la chaîne.. des documents sans passer par spip donc directement dans un sous dossier créé dans IMG et avec des liens <a>....) et aussi donc sans attribuer de langue à leur traductions...
      J’avais déjà nettoyé mais pas dans tous les recoins.
      Presque fini on va voir..

    • Thomas

      Bon alors, je crois que c’est bon maintenant. Mais il m’aura fallu encore 4 tentatives de fusion...

      Au final ça a marché après avoir :
      -  restaurée la base du spip hôte (état avant 1er essai de fusion) + config/nettoyé (cache vidé...)
      -  bien nettoyé les deux bases, source et hôte en m’assurant surtout que sur la base hôte il ne subsiste aucun article commun avec la base source (reste d’une ancienne fusion par exemple... hum..)
      -  emploi du plugin Corbeille pour “vider les corbeilles” des deux spip (puis sauvegardes des bases)
      -  copie du fichier de la base source dans le config/bases. Ce fichier sqlite porte le nom de la bases hôte (tout comme la bdd source. Donc la base et son fichier ont le même nom que la base hôte).
      -  la base est bien déclarée, ok
      -  le fichier de la bdd source est bien renseignée dans le champ ’source’ du plugin, le chemin du dossier images est bien renseignée en /home/thomas/spip/images et la rubrique de destination est renseignée (et vide de contenus)
      => Résultat semble ok. Les articles n’ont plus de traductions fantômes et les documents semblent avoir été intégrés, en tout cas ils apparaissent sur les quelques articles vérifiés.

      Question : le dossier “image” demeure en place avec son contenu. Donc le plugin a copié les docs du dossier images dans le IMG, ce qui signifierait que l’on peut supprimer le dossier images ? (question bête mais à cette heure et avec les neurones qui me reste..).

      A propos des noms de base et de fichier sqlite :
      J’ai encore fait différents essais avant ce dernier, notamment en mettant un fichier de base sqlite dont le nom était “inventé”, genre bbd_sitetruc_clean_20140505.sqlite mais j’obtenais le même message “Cette information est obligatoire” pour le champ “source” du plugin. Ce que j’obtenais également avec un nom de bdd différent que celui de la base hôte..
      Bon certes, j’ai fait pas mal de manips et sans tout noter mais j’ai vraiment le sentiment que dans mon cas la fusion fonctionne lorsque la bdd source ainsi que son fichier sqlite portent le même nom que celui de la base hôte...
      Voilà qu’en penses-tu ?
      Ecore merci pour ton aide,
      T

    • Bonjour,
      Simplement, je ne sais pas si j’ai eu de la chance ou ? Mais la seule chose qui a bien fonctionné dans ma deuxième fusion, c’est justement l’import des documents, et j’ai utilisé comme chemin ../IMG2.
      Là j’ai un gros doute... Le serveur que j’utilise aurait-il une configuration atypique ? Quand j’ai testé le plugin, j’avais tenté de donner tous les path possibles... Nada ! Du coup j’avais donné le fameux ../IMG2, là ça avait marché.
      Hier pareil, et aujourd’hui idem les document, c’est la seule chose qui se passe bien.

      Chose que je n’ai pas dite dans mon post précédent, c’est que moi aussi j’ai eu l’erreur “vous devez remplir ce champ” alors que j’avais pourtant déclaré la deuxième base et que... Je voyais le nom ce cette base dans le menu déroulant !
      Bonne journée,
      Yves

    Reply to this message

  • Bonjour,
    Malgré l’utilisation de mysql_query(“SET NAMES ’utf8’”) ,j’ai le même problème que si je ne l’avais pas rajouté...
    J’ai fait trois fois la manip de la fusion, ça ne marche pas.
    (à chaque fois en remettant le base du site hote avec le .sql d’origine)

    Je ne pige vraiment pas d’où ça vient, d’autant plus que j’ai déjà fusionné ces deux sites juste pour tester “Fusion” avant de l’utiliser.

    Bonne journée,
    Y

    Reply to this message

  • 1

    Retour d’expérience

    Les deux sites doivent être sous la même version de SPIP, des différences mineures peuvent exister, une fusion entre un site sous 2.x et 3.x est illusoire ; de plus la version “Fusion pour SPIP2” n’est plus maintenue.

    Mode opératoire

    -  On sauvegarde les /IMG et /config des deux sites
    -  On vide le /tmp/cache
    -  On sauvegarde les bases MySQL ou SQLite (dans le cas SQLite, les fichiers sont locaux, dans celui de MySQL, distants)
    -  On installe sur le site hôte (celui qui reçoit les fichiers) le plugin “Fusion” de SPIP (disponible sur http://files.spip.org/Fusion-de-SPIP, “Fusion” dans le menu déroulant “maintenance”)
    -  On y crée une rubrique dont le nom n’existe pas dans le site accueilli, si on ne fait pas cela le résultat sera un mixe des deux sites.
    -  On démarre la fusion…

    Attention : La base du site accueilli doit être déclarée comme « base externe sur le site hôte » après cette déclaration, un fichier nom-de-ma-base.php est créé .

    On édite nom-de-ma-base.php<code> et <code>connect.php et on ajoute :

    mysql_query("SET NAMES 'utf8'");
    après la ligne :
    spip_connect_db('localhost','','basog','ejemrapelplu','basogbis','mysql', 'spip','');

    (bas est le login phpMyadmin pour bosser sur la base, ejmerapelplu le password fourni par les collègues, basbis le nom de la base hôte).

    On renomme en IMG2 le /IMG du site hébergé et on le copie à coté du /IMG du site hôte, a priori, IMG-truc ne fonctionne pas mais IMG2 oui.

    À tester : Ne modifier que non-de-ma-base.php et /IMG-truc sans le -

    On retourne à spip-fusion, la nouvelle base est dispo dans le premier menu déroulant, pour le chemin des documents, le path est ../IMG2.

    Pour “secteur” on donne le nom de la rubrique prévue pour l’accueil.

    Et on lance la fusion…

    • a la place de :
      spip_connect_db(’localhost’,’’,’basog’,’ejemrapelplu’,’basogbis’,’mysql’, ’spip’,’’);

      lire :
      spip_connect_db(’localhost’,’’,’bas’,’ejemrapelplu’,’basbis’,’mysql’, ’spip’,’’);

      Et le password ne vous est pas fourni par “les collègues” mais par votre hébergeur :-)

      Pardon,
      Y

    Reply to this message

  • 3

    Bonjour,
    J’ai modifié le connect.php avec mysql_query(“SET NAMES ’utf8’”); comme dit ci -dessus, malgré cela j’ai les noms de rubrique ainsi que les contenus d’article tronqué à la première lettre accentuée.

    Faut-il aussi modifier le fichier ma-base.php créé lors de la fusion et qui contient les même indications que le connect.php ?

    Merci et bonne journée,
    Y

    • Tout à fait, l’article n’est peut être pas suffisamment explicite mais c’est bien dans le fichier de connexion de la base source (ma-base.php) qu’il faut ajouter cette modif.

    • Je dirais que oui... C’est pas 100% sûr que ça soit ça qui allait pas mais après l’avoir fait ça a marché... C’est curieux.

    • Raah! !! J’ai compris il faut modifier le ma base.php, pas le connect.php... C’est fou comme je comprend vite ;-)

    Reply to this message

  • 1

    Bonjour,
    Au moment ou je veux déclarer la deuxième base (localhost - login - pwd) j’ai simplement “La connexion à la base de données a échoué.” et rien de plus. Je ne vois pas ce que je pourrais donner à la place... Que puis-je faire ?
    Bonne journée,
    Y

    • Oubliez la question ! Le problème était entre la chaise et l’écran !

    Reply to this message

  • 1

    J’ai installer Spip en local sur mon serveur XAMPP, sous Linux, et mon mot de passe Spip ne fonctionne plus. Est-ce que Spip le change automatiquement au bout de quelques jours?

    Y a t-il un moyen de le récupérer ou si je dois réinstaller Spip à chaque fois que ça arrive?

    • salut,

      a priori non spip ne change pas automatiquement les mots de passe. Quels types de message as-tu ?

      Du reste, je ne vois pas ce que cette question vient faire sous cet article ...

    Reply to this message

  • Je note un premier bug à corriger : en cas d’import des documents du IMG source, le script tente de copier dans l’hôte les documents distants, ce qui provoque des erreurs.
    Merci à Jack31 de m’avoir permis de localiser ce bug, promis je m’en occupe dès que possible.

    Reply to this message

Add a comment

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 / PostgreSQL
  • 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 apparait.

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.

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom