Migrer un forum vBulletin 4 vers Discourse

Oui, ils sont convertis. Je vous enverrai un e-mail demain !

Vous devez atteindre le niveau de confiance 1 pour débloquer les messages privés, et vous n’avez pas encore passé assez de temps à lire les sujets ici pour y parvenir.

Bonjour, je suis sur un conteneur Docker (DigitalOcean) et j’essaie d’importer mon forum MyBB (je sais que ce tutoriel est pour vBulletin, mais la partie Gemfile est similaire). Je suis bloqué à l’étape bundle install :

mybb1229×386 68 KB

Bonjour,

Nous avons tenté d’importer vBulletin 3.8 vers Discourse. Ce script fonctionne correctement avec une base de données de 300 Mo, environ 40 000 utilisateurs et 60 000 messages. Cependant, à la fin du processus d’importation, nous avons rencontré un problème d’encodage des caractères.

• Notre vBulletin 3.8 est encodé en latin1.
  ----> Lors de l’exécution du script d’importation, MySQL 5.6 dans le conteneur Docker de Discourse est configuré en UTF-8.
• Le script d’importation force la conversion des données vers UTF-8.

Par conséquent, à la fin de l’importation, les données affichées sur le forum Discourse présentent des erreurs d’encodage UTF-8. Cela ressemble à l’image ci-dessous :

1. Avant l’importation, vB 3.8

2. Après l’importation dans Discourse
   

   

   image581×583 20.9 KB

Nous avons essayé :

• De convertir l’encodage de vB 3.8 en UTF-8 avant d’exécuter le script d’importation.
• De tester cette base de données vB 3.8 sur un nouveau serveur MySQL : le texte s’affiche normalement sans erreur d’encodage.

Auriez-vous des conseils dans ce cas ?

Nous vous remercions par avance pour tout soutien apporté (et nous sommes vraiment désolés si notre anglais est difficile à comprendre).

Voici un extrait de la façon dont j’ai résolu un problème similaire :

    ### Encodage WIN1252
    win_encoded = ''
    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nÉchec Win1252 pour \n\n#{raw}\n\n"
      win_encoded = ''
    end
    raw = win_encoded

Vous m’avez sauvé la vie.
Pour la méthode simple, j’ai essayé le script de conversion sur le post Migrate a phpBB3 forum to Discourse - #540 by gerhard, qui m’a aidé à résoudre rapidement mon problème de jeu de caractères de la base de données, et cela fonctionne parfaitement maintenant.
Merci beaucoup pour vos conseils.

Quelqu’un a-t-il effectué une migration en utilisant l’importateur vBulletin 5 ? Je pourrais l’utiliser à l’avenir et j’aimerais savoir s’il a déjà été utilisé sans aucun problème.

Je viens d’importer vBulletin5 et d’ajouter quelques fonctionnalités (liens permanents, certains éléments de mise en forme, et peut-être d’autres choses dont je ne me souviens plus). Je compte soumettre une PR, mais cela n’a pas encore été fait.

J’ai une sauvegarde de base de données vb5 qui contient des pièces jointes. Puis-je les importer dans Discourse ou dois-je avoir toutes les pièces jointes sous forme de fichiers ?

Je suis aussi confus à ce sujet. Où dois-je exactement copier les fichiers de pièces jointes dans le dossier Discourse ?

Salut à nouveau,

D’après ce que je comprends, les pièces jointes provenant de la base de données devraient fonctionner, car elles semblent être gérées de la même manière que les avatars, qui sont également stockés dans la base de données.

Mon importation se déroule bien, mais j’ai rencontré une erreur à 91 % des publications importées

importing posts...
  1425149 / 1564573 ( 91.1%)  [1040 items/min]  Traceback (most recent call last):
        14: from script/import_scripts/vbulletin5.rb:726:in `<main>'
        13: from /home/canapin/discourse/script/import_scripts/base.rb:47:in `perform'
        12: from script/import_scripts/vbulletin5.rb:49:in `execute'
        11: from script/import_scripts/vbulletin5.rb:300:in `import_posts'
        10: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `batches'
         9: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `loop'
         8: from /home/canapin/discourse/script/import_scripts/base.rb:863:in `block in batches'
         7: from script/import_scripts/vbulletin5.rb:320:in `block in import_posts'
         6: from /home/canapin/discourse/script/import_scripts/base.rb:508:in `create_posts'
         5: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
         4: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
         3: from /home/canapin/discourse/script/import_scripts/base.rb:509:in `block in create_posts'
         2: from script/import_scripts/vbulletin5.rb:321:in `block (2 levels) in import_posts'
         1: from script/import_scripts/vbulletin5.rb:450:in `preprocess_post_raw'
script/import_scripts/vbulletin5.rb:450:in `gsub': invalid byte sequence in UTF-8 (ArgumentError)

Comment puis-je identifier correctement la publication pour voir à quoi ressemble son contenu dans la base de données vbulletin ?

Quelqu’un a suggéré des façons d’utiliser rescue pour résoudre ces problèmes, vous pourriez donc revenir en arrière et le trouver (je ne me souviens plus si c’était dans ce sujet ou un autre). Vous pourriez ajouter un puts dans le bloc rescue pour afficher l’id et/ou le texte qui a causé le problème.

Vous avez un problème d’encodage.

J’ai utilisé ceci lors d’une importation similaire (je pense que vous devriez le placer dans preprocess_post_raw)

    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nWin1252 a échoué pour \n\n#{raw}\n\n"
      win_encoded = ''
    end

Bonjour,
J’ai modifié l’importateur et ajouté votre script comme suit :

  def preprocess_post_raw(raw)
    return "" if raw.blank?
    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nÉchec de Win1252 pour \n\n#{raw}\n\n"
      win_encoded = ''
    end
    # décoder les entités HTML
    raw = @htmlentities.decode(raw)

    # corriger les espaces blancs
    raw = raw.gsub(/(\\r)?\\n/, "\n")
      .gsub("\\t", "\t")

La séquence d’octets invalide en UTF-8 se produit dans cette partie : raw = raw.gsub(/(\\r)?\\n/, "\n") .gsub("\\t", "\t").

Ensuite, j’ai relancé l’importateur. Bien qu’il saute les données déjà en cours d’importation, il a fallu environ 6 heures pour atteindre le post qui génère une erreur, et les informations attendues pour afficher le contenu du post n’ont pas été ajoutées. Une idée de la raison ?

edit :

Voici probablement le contenu brut du post qui entraîne l’erreur :

I wonder if Billy is enjoying the parade.

Qwertyuiopasdfghjklzxcvbnm��

Je vais essayer de modifier le script d’importation pour qu’il saute (vraiment) les 1,4 million de posts précédents. Bonne chance à moi.

J’ai modifié de nombreux autres importateurs pour inclure un paramètre import_after afin de permettre l’importation uniquement des données récentes. Vous pouvez consulter d’autres exemples pour voir comment je l’ai fait.

Salut,
J’ai réussi à importer presque tous mes messages ! J’en ai corrigé quelques dizaines à la main et j’ai relancé l’importation à chaque fois qu’une nouvelle erreur UTF-8 survenait…

Maintenant, je dois importer les pièces jointes (qui sont stockées dans la base de données VBulletin), mais cela ne fonctionne pas :
Dès que le processus démarre, ma consommation de RAM augmente fortement en 10 ou 20 secondes, puis cette erreur apparaît :

importation des pièces jointes...
Échec de la création du téléchargement : Impossible d'allouer de la mémoire - grep
Échec

Ma RAM :

image505×113 3.89 KB

J’utilise une version de développement de Discourse sur un sous-système Ubuntu 18 sous Windows 10, et j’ai 16 Go de RAM.

Les pièces jointes représentent 7 Go sur les 13 Go de la base de données vBulletin.
Notez que j’utilise l’importateur vbulletin5.

Le problème vient de cette requête :

    SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
      FROM #{DB_PREFIX}attach a
      LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
      LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid

Si j’exécute cette requête dans MySQL, ma RAM restante est saturée en quelques secondes.

(édition de mon message pour supprimer les informations et questions inutiles, car je trouve des solutions et propose une solution de contournement)

Solution de contournement :

J’ai ajouté une limite et un décalage (offset) à la requête SQL de l’importateur. J’ai importé les pièces jointes en sélectionnant 20 000 à la fois :

    uploads = mysql_query <<-SQL
    SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
      FROM #{DB_PREFIX}attach a
      LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
      LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid
      LIMIT 20000 OFFSET 0
    SQL

J’ai également ajouté un exit à la fin de la boucle uploads.each do |upload| pour empêcher le script d’importation de continuer après avoir importé mes 20 000 pièces jointes.

Une fois mes 10 000 pièces jointes importées, j’édite le script (merci nano +353 ./scripts/import_scripts/vbulletin5.rb pour ouvrir le fichier à la bonne ligne) afin d’augmenter le OFFSET de la requête SQL de 10 000, puis je relance l’importateur… et je répète l’opération pour mes 65 000 pièces jointes.

Pendant l’importation des pièces jointes, j’ai rencontré plusieurs erreurs et avertissements, notamment :

• W, [2020-08-20T12:05:37.402860 #31042] WARN -- : Mauvaise valeur de date/heure "0000:00:00 00:00:00" : mon hors de portée
• Post for 490451 not found (probablement d’anciennes pièces jointes orphelines ?)
• quelques erreurs liées aux données EXIF, semble-t-il
• Échec Celle-ci m’a intrigué et a arrêté le script d’importation. J’ai vérifié le premier “Échec” obtenu et la pièce jointe du forum était en quelque sorte corrompue (pas de nom de fichier), alors j’ai commenté l’instruction exit pour laisser l’importateur continuer son travail même lorsqu’il “échoue”, en espérant que cela ne casserait rien.

       puts "Échec"
       #exit

J’ai également rencontré une erreur plus gênante qui a interrompu l’importation :

1: from /usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:53:in `save!'
/usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:80:in `raise_validation_error':
Validation failed: Body is limited to 32000 characters; you entered 32323. (ActiveRecord::RecordInvalid)

Heureusement, c’était une erreur rare, et j’ai simplement sauté cette pièce jointe jusqu’à ce que je rencontre la prochaine erreur identique. Cela s’est produit peut-être une douzaine de fois sur un total de 65 000 pièces jointes. J’ai simplement relancé le script d’importation avec un décalage (offset) de requête SQL différent.

Bonjour,

J’ai remarqué que le champ personnalisé import_pass manquait pour environ 400 utilisateurs sur mes 27 000 utilisateurs restants (j’ai supprimé 154 000 utilisateurs inactifs).

Avez-vous une idée de la raison ?

Le forum a été migré de phpBB vers vBulletin en mai. Est-ce que cela pourrait y être lié ?

Je ne vais pas essayer de « réparer » cela en important les mots de passe pour ces 400 utilisateurs (sauf s’il existe un moyen simple de le faire…), et ce n’est pas un problème majeur, donc je suis surtout curieux.

Salut à tous,
Les images importées ont un mauvais ratio largeur/hauteur sauf si je rebake les publications. Je souhaiterais trouver un moyen d’obtenir le bon ratio (par exemple lors de l’import) sans avoir à rebaker.

Description plus détaillée du problème :

D’après ce que je comprends, les publications importées ne sont pas « baked » lorsque Discourse crée la publication correspondante (bien que le champ cooked soit généré d’une manière ou d’une autre), c’est pourquoi l’importation de publications est beaucoup plus rapide que le baking des publications Discourse existantes.

Mon problème est que mes images importées ont un mauvais ratio largeur/hauteur.

Exemple du texte brut Discourse lié à une image importée :

![SH-MUniFrame.JPG|600x800](upload://6Li1nnjbA8zDz6YJ3FqeYHV5zXK.jpeg)

Le contenu du champ « cooked » :
<img src="https://d11a6trkgmumsb.cloudfront.net/original/3X/0/3/0379f53ed8221730ccb31807238e9c46e9fe1d37.jpeg" alt="SH-MUniFrame.JPG" data-base62-sha1="6Li1nnjbA8zDz6YJ3FqeYHV5zXK" width="517" height="500" class="d-lazyload">

Comment l’image apparaît dans : la publication

image517×501 102 KB

La taille originale de l’image dans la base de données vBulletin est :

select width, height from filedata where filedataid = 76237
+-------+--------+
| width | height |
+-------+--------+
|   600 |    800 |
+-------+--------+

Ma compréhension est que l’attribut height est contraint par le paramètre de Discourse qui définit une hauteur maximale de 500 px, d’où la même valeur dans l’attribut height de la balise <img>. La largeur de la balise <img> est quelque peu modifiée de 600 à 517, mais je ne parviens pas à comprendre comment et pourquoi.

Le problème est le même pour les anciennes images qui ont 0 dans les deux champs de pièce jointe width et height de vBulletin. Elles ont également un problème de ratio hauteur/largeur incorrect. Je ne sais pas si ces valeurs sont réellement utilisées lors de l’import.

Le problème est résolu en rebake (reconstruire le HTML) la publication. L’image sera alors correctement redimensionnée et le visualiseur d’images sera ajouté. Mais j’ai 1,6 million de publications et je préférerais éviter de rebaker toutes.

Une solution rapide consisterait à utiliser ce CSS sur mon Discourse :

.cooked img:not(.emoji) {
    height: auto;
    width: auto;
}

Mais cela implique que personne ne pourra choisir une taille arbitraire lors du téléchargement d’une image, et il peut y avoir des effets secondaires dont je ne suis pas conscient.

Avez-vous une idée de comment je pourrais obtenir un bon ratio largeur/hauteur pour les pièces jointes importées ?

Je soupçonne que c’est parce que vous n’avez pas laissé le temps aux posts de se cuire après l’importation. Je ne vois pas comment résoudre le problème sans recuire les posts. Peut-être voulez-vous simplement recuire les posts qui sont cassés plutôt que tous ?

Sont-elles censées être recalculées automatiquement au fil du temps après l’importation ? En commençant par le dernier ou le premier post créé ?

Ce n’est pas un gros problème, cependant, et si elles ne sont pas recalculées automatiquement, je lancerais probablement un recalcul de tous les posts et je serais patient, bien que j’avoue avoir lu ce post il y a quelques jours et cela m’a un peu effrayé : My journey into a massive posts rebake job. J’ai aussi des questions à ce sujet, mais je les poserai dans le sujet approprié.

Hmm, oui, cela ressemble bien à mon code. Désolé pour cela.

Cela devrait suivre ce modèle :

   batches(BATCH_SIZE) do |offset|
       (Code SQL)
        LIMIT #{BATCH_SIZE}
        OFFSET #{offset}
        (Autre code)
    end

Augmentez simplement le paramètre du site max post length avant l’importation.