Migrar um fórum vBulletin 4 para Discourse

Sim, eles são convertidos. Vou te enviar um e-mail amanhã!

Você precisa atingir o nível de confiança 1 para desbloquear mensagens privadas, e ainda não passou tempo suficiente lendo tópicos aqui para alcançar isso.

Olá, estou em um contêiner Docker (DigitalOcean) e estou tentando importar o mybb (sei que este tutorial é para o Vbulletin, mas a coisa do Gemfile é similar). Estou travado no bundle install:

mybb1229×386 68 KB

Olá,
Tentamos importar o vBulletin v3.8 para o Discourse. Este script funciona bem com um banco de dados de 300 MB, cerca de 40 mil usuários e 60 mil posts. No entanto, ao final do processo de importação, enfrentamos um problema com a codificação de caracteres.

• Nosso vBulletin 3.8 está codificado com o charset: latin1
  ----> ao executar o script de importação, o MySQL 5.6 no Docker do Discourse também está configurado com o charset UTF-8,
• O script de importação força a conversão dos dados para UTF-8 durante o processo,
  portanto, ao final da importação, o fórum do Discourse exibe os dados com erro de codificação UTF-8. Parece como na imagem abaixo.

1. Antes da importação, vB 3.8

2. Após a importação para o Discourse
   

   

   image581×583 20.9 KB

Tentamos:

• Converter o charset do vB 3.8 para UTF-8 antes de executar o script de importação
• Testar este banco de dados do vB 3.8 em um novo servidor MySQL, onde o texto foi exibido normalmente, sem erros de codificação.
  Então, você tem algum conselho para este caso?

Agradecemos qualquer suporte sobre isso (e peço desculpas pelo meu inglês, caso tenha sido difícil de entender).

Aqui está um trecho de como resolvi um problema semelhante:

    ### Codificação 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}\nWin1252 falhou para \n\n#{raw}\n\n"
      win_encoded = ''
    end
    raw = win_encoded

Você salvou minha vida.
Para o caminho mais fácil, tentei o script de converso no post Migrate a phpBB3 forum to Discourse - #540 by gerhard, me ajudou a resolver meu problema de codificação de caracteres do banco de dados rapidamente, e agora funciona como um charme.
Muito obrigado pelo conselho.

Alguém migrou usando o importador do vBulletin 5? Posso usá-lo no futuro e gostaria de saber se já foi utilizado sem problemas.

Acabei de importar o vBulletin5 e adicionei alguns recursos (links permanentes, alguma formatação e talvez outras coisas que não me lembro). Tenho a intenção de enviar um PR, mas ainda não aconteceu.

Tenho um dump de banco de dados vb5 que contém anexos. Posso importá-los no Discourse ou preciso ter todos os anexos como arquivos?

Também estou confuso quanto a isso. Onde exatamente devo copiar os arquivos de anexo na pasta do Discourse?

Olá novamente,
Pelo que entendi, os anexos do banco de dados funcionarão, pois parecem ser tratados da mesma forma que os avatares, que também estão no banco de dados.

Minha importação está indo bem, mas encontrei um erro em 91% das postagens importadas

importando postagens...
  1425149 / 1564573 ( 91.1%)  [1040 itens/min]  Traceback (última chamada):
        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': sequência de bytes inválida em UTF-8 (ArgumentError)

Como posso identificar corretamente a postagem para ver como é o conteúdo no banco de dados do vbulletin?

Alguém sugeriu maneiras de usar rescue para resolver isso, então você pode voltar e encontrar isso (não me lembro se foi neste tópico ou em outro). Você poderia colocar um puts no rescue para imprimir o id e/ou o texto que causou o problema.

Você tem um problema de codificação.

Usei isso em uma importação semelhante (acho que você colocaria em 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 falhou para \n\n#{raw}\n\n"
      win_encoded = ''
    end

Olá,
Modifiquei o importador e adicionei seu script da seguinte forma:

  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}\nWin1252 falhou para \n\n#{raw}\n\n"
      win_encoded = ''
    end
    # decodificar entidades HTML
    raw = @htmlentities.decode(raw)

    # corrigir espaços em branco
    raw = raw.gsub(/(\r)?\n/, "\n")
      .gsub("\t", "\t")

A sequência de bytes inválida em UTF-8 ocorre nesta parte: raw = raw.gsub(/(\r)?\n/, "\n") .gsub("\t", "\t").

Em seguida, iniciei o importador novamente. Embora ele pule os dados já importados, levou cerca de 6 horas para chegar à postagem que gera o erro, e as informações esperadas para visualizar o conteúdo da postagem não foram adicionadas. Alguma ideia do porquê?

edit:

Provavelmente este é o conteúdo bruto da postagem que causa o erro:

I wonder if Billy is enjoying the parade.

Qwertyuiopasdfghjklzxcvbnm��

Vou tentar modificar o script do importador para fazer com que ele pule (de verdade) as 1,4 milhões de postagens anteriores. Boa sorte para mim.

Modifiquei muitos outros importadores para incluir uma configuração import_after, permitindo importar apenas dados recentes. Você pode consultar alguns deles para ver como fiz isso.

Oi,
Consegui importar quase todas as minhas postagens! Corrigi algumas dezenas manualmente e reiniciei a importação sempre que encontrava um novo erro de UTF-8…

Agora, preciso importar os anexos (que estão armazenados no banco de dados do VBulletin), mas não está funcionando:
Quando o processo inicia, meu consumo de RAM aumenta bastante em cerca de 10 ou 20 segundos e ocorre este erro:

importando anexos...
Falha ao criar upload: Não foi possível alocar memória - grep
Fail

Minha RAM:

image505×113 3.89 KB

Estou usando uma versão de desenvolvimento do Discourse em um subsistema Ubuntu 18 no Windows 10 e tenho 16 GB de RAM.

Os anexos ocupam 7 GB dos 13 GB do banco de dados vBulletin.
Observe que estou usando o importador vbulletin5.

O problema vem desta consulta:

    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

Se eu executar essa consulta no MySQL, minha RAM restante é preenchida em segundos.

(editando minha postagem para remover informações e perguntas desnecessárias, já que estou resolvendo o problema e fornecendo uma solução alternativa)

Solução alternativa:

Adicionei um limite e um deslocamento (offset) à consulta SQL do importador. Importei os anexos selecionando 20.000 de cada vez:

    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

Também adicionei um exit no final do loop uploads.each do |upload| para impedir que o script de importação continue fazendo outras coisas após importar meus 20.000 uploads.

Quando meus 10.000 uploads foram importados, editei o script (graças ao nano +353 ./scripts/import_scripts/vbulletin5.rb para abrir o arquivo na linha correta) para aumentar o OFFSET da consulta SQL em 10.000 e iniciei o importador novamente… E fiz isso para meus 65.000 anexos.

Durante a importação dos anexos, encontrei vários erros e avisos, incluindo:

• W, [2020-08-20T12:05:37.402860 #31042] WARN -- : Valor de data/hora inválido "0000:00:00 00:00:00": mês fora do intervalo
• Postagem para 490451 não encontrada (acho que são anexos antigos órfãos?)
• algum erro de dados EXIF, parece
• Fail Este me deixou confuso e parou o script de importação. Verifiquei o primeiro “Fail” que recebi e o anexo do fórum estava meio corrompido (sem nome de arquivo), então comentei a instrução exit para permitir que o importador continuasse seu trabalho quando “falhar”, esperando que isso não quebrasse nada.

       puts "Fail"
       #exit

Também tive um erro mais chato que interrompeu a importação:

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)

Felizmente, foi um erro raro, e apenas pulei este anexo até encontrar o próximo erro idêntico. Isso aconteceu talvez uma dúzia de vezes em um total de 65.000 anexos. Eu apenas reiniciei o script de importação com um deslocamento (offset) diferente na consulta SQL.

Oi,
Percebi que o campo personalizado import_pass estava ausente em cerca de 400 usuários dos meus 27.000 restantes (eu removi 154.000 usuários inativos).

Alguma ideia do porquê?

O fórum foi migrado do phpBB para o vBulletin em maio. Isso poderia ter algo a ver com isso?

Não vou tentar “consertar” isso e importar senhas para esses 400 usuários (a menos que exista uma maneira fácil de fazer isso…?) e isso não é um grande problema, então estou apenas curioso, mais do que qualquer outra coisa.

Ei pessoal,
As imagens importadas têm uma proporção de largura/altura incorreta, a menos que eu rebake os posts. Gostaria de encontrar uma maneira de ter a proporção correta (durante a importação, por exemplo) sem precisar rebake.

Descrição mais detalhada do problema:

Pelo que entendi, os posts importados não são “baked” quando o Discourse cria o post correspondente (embora o campo cooked seja gerado de alguma forma), por isso importar posts é muito mais rápido do que fazer o bake de posts existentes no Discourse.

Meu problema é que minhas imagens importadas têm uma proporção de largura/altura incorreta.

Exemplo do texto bruto do Discourse relacionado a uma imagem importada:

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

O conteúdo do campo “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">

Como a imagem aparece no: post

image517×501 102 KB

O tamanho original da imagem no banco de dados do vBulletin é:

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

Minha compreensão é que o atributo height é limitado pela configuração do Discourse, que define uma altura máxima de 500px, daí o mesmo valor no atributo height da tag <img>. A largura da tag <img> é modificada de 600 para 517, embora eu não consiga entender como e por que isso acontece.

O problema é o mesmo para imagens mais antigas que têm 0 nos campos de largura e altura dos anexos do vBulletin. Elas também apresentam o problema incorreto de altura/largura. Não sei se esses valores são realmente usados durante a importação.

O problema é resolvido ao rebake (reconstruir o HTML) do post. A imagem será então redimensionada corretamente e o visualizador de imagens será adicionado. Mas tenho 1,6 milhão de posts e prefiro evitar rebake todos eles.

Uma solução rápida seria usar este CSS no meu Discourse:

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

Mas isso implica que ninguém poderá escolher um tamanho arbitrário ao fazer upload de uma imagem, e podem haver efeitos colaterais dos quais não tenho conhecimento.

Alguma ideia de como eu poderia ter a proporção correta de largura/altura nas imagens importadas dos anexos?

Suspeito que seja porque você não deixou eles assarem após a importação. Não consigo imaginar uma maneira de resolver o problema sem refazer o cozimento dos posts. Talvez você queira refazer apenas os posts quebrados, em vez de todos eles?

Eles deveriam ser processados automaticamente ao longo do tempo após a importação? Começando do último ou do primeiro post criado?

Isso não é um grande problema, no entanto, e se não forem processados automaticamente, eu provavelmente iniciaria um rebake de todos os posts e teria paciência, embora eu admita que li este post alguns dias atrás e ele me assustou um pouco: My journey into a massive posts rebake job. Também tenho dúvidas sobre isso, mas vou fazê-las no tópico adequado.

Hmm, sim, parece que é o meu código. Desculpe por isso.

Isso deve seguir o seguinte padrão:

   batches(BATCH_SIZE) do |offset|
       (código SQL)
        LIMIT #{BATCH_SIZE}
        OFFSET #{offset}
        (outro código)
    end

Aumente a configuração do site max post length antes da importação.