Na verdade, é 3.3, então estou fazendo o trabalho preparatório pendente para que os PRs tornem o script compatível com essa versão do phpBB, ou posso tentar com o script atual usando a edição que você sugeriu anteriormente para a verificação de versão…
Então, acho que precisarei trabalhar com xml_to_markdown.rb?
Minha tentativa de fazer uma importação de teste com um fórum phpBB 3.3.x foi um grande fracasso, mas falarei mais sobre isso depois.
Aprendi muito no processo de tentar, e pensei em compartilhar o que aprendi porque pode ser útil para outras importações e quando o script de importação for atualizado para phpBB 3.3.
Se você precisar editar /script/import_scripts/phpbb3/database/database.rb para passar pela verificação de versão, ou /script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb para adicionar BBcodes personalizados, o momento de fazê-lo é depois de iniciar a importação com este comando:
/var/discourse/launcher enter import
Nesse ponto, você pode usar o nano para editar os arquivos.
Como minha tentativa de executar a importação no meu fórum phpBB 3.3 falhou, não tenho certeza se minhas alterações personalizadas de BBcode teriam sido eficazes, mas parece que tudo o que você precisa fazer para phpBB 3.2+ é editar o arquivo:
/script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb
conforme observado acima, e adicionar uma definição no formato de:
def visit_<seu BBcode personalizado sensível a maiúsculas e minúsculas aqui>(xml_node, md_node)
# código para lidar com as coisas vai aqui
end
Novamente, ainda não testei isso, mas um BBcode personalizado muito comum no phpBB que não aparece na versão do xml_to_markdown.rb que eu tinha é este:
[YouTube]{Identifier}[/YouTube]
onde o {Identifier} é o valor “v” da string de consulta do URL do YouTube.
Então, minha tentativa de noob em Ruby para adicionar esse código ao xml_to_markdown.rb é:
def visit_YouTube(xml_node, md_node)
content = xml_node.content
url = "https://www.youtube.com/watch?v=" + content
md_node.text = "#{url}"
md_node.prefix_linebreaks = md_node.postfix_linebreaks = 2
md_node.prefix_linebreak_type = LINEBREAK_HTML
end
Finalmente, quando executei o script de importação, cheguei apenas à etapa de carregamento do banco de dados e recebi este erro:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Não tenho certeza se isso é um problema do DB Engine - o original usa InnoDB - ou o quê, mas suspeito que será abordado na versão 3.3 do script para phpBB.
Ok, então eu não consegui deixar isso de lado.
Embora eu suponha que seja possível que o erro que recebi possa ser tratado pelo script de importação, parece-me que é um problema com a estrutura do banco de dados do phpBB3, e o fato de que a colação do meu banco de dados é UTF8. Recebi este erro executando o script de importação:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Quando olhei para a linha 1233035 do meu arquivo phpbb_mysql.sql - estou usando uma cópia local do dump de dados - vi isto:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
Olhando para a coluna config_name na tabela phpbb_config, descobri que ela está definida como VARCHAR(255).
Graças a esta postagem no Stackoverflow, descobri que posso usar um “índice de prefixo” para encurtar o comprimento da chave. Eu testei e funcionou.
Para o meu banco de dados phpBB 3.3.8, na verdade quatro tabelas foram afetadas:
Se mais alguém quiser tentar, aqui estão os passos para a tabela phpbb_config, e incluirei as consultas para as outras tabelas no final.
Calcule o menor valor para o índice de prefixo usando esta consulta:
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config`;
No meu caso, mostrou que 100% das linhas usavam menos de 50 caracteres, então editei meu arquivo de dump de dados:
nano /var/discourse/shared/standalone/import/data/phpbb_mysql.sql
e usei a busca Ctrl+W para a seguinte string:
ALTER TABLE `phpbb_config`
então mudei isto:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
para isto:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`(50)),
ADD KEY `is_dynamic` (`is_dynamic`);
O (50) aí é o comprimento do índice de prefixo.
No meu caso, tive que repetir o processo com as outras três tabelas usando estas consultas para obter o comprimento ideal da chave de prefixo:
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config_text`;
SELECT
ROUND(SUM(LENGTH(`migration_name`)<10)*100/COUNT(`migration_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`migration_name`)<20)*100/COUNT(`migration_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`migration_name`)<50)*100/COUNT(`migration_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`migration_name`)<100)*100/COUNT(`migration_name`),2) AS pct_length_100
FROM `phpbb_migrations`;
SELECT
ROUND(SUM(LENGTH(`provider`)<10)*100/COUNT(`provider`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`provider`)<20)*100/COUNT(`provider`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`provider`)<50)*100/COUNT(`provider`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`provider`)<100)*100/COUNT(`provider`),2) AS pct_length_100
FROM `phpbb_oauth_accounts`;
Aqui estão as strings de busca para as outras tabelas para economizar seu tempo:
ALTER TABLE `phpbb_config_text`
ALTER TABLE `phpbb_migrations`
ALTER TABLE `phpbb_oauth_accounts`
Não vou dizer que estou livre de problemas, mas o acima resolveu meu erro inicial de banco de dados, e a importação está em andamento:
#import_phpbb3.sh
O início da importação do phpBB3...
Carregando grupos existentes...
Carregando usuários existentes...
Carregando categorias existentes...
Carregando posts existentes...
Carregando tópicos existentes...
importando de phpBB 3.3.8
criando usuários
722 / 5014 ( 14.4%) [58 itens/min]
Atualização:
A importação do script terminou em 9 horas e 28 minutos. Graças ao Screen. Este script é incrível!
O pós-processamento está em andamento.
Existe um log da saída do script de importação em algum lugar, ou eu deveria ter redirecionado para um arquivo?
Qual procedimento para o importador phpbb3 deve ser usado ao executar discourse_dev em um contêiner Docker sob WSL?
Tentei usar o procedimento 1. Importando usando um contêiner Docker e o procedimento 2. Importando usando o ambiente de desenvolvimento. Nenhum deles funcionou, embora eu tenha conseguido executar o script até a conclusão no procedimento 1, mas nenhum dado realmente entrou no banco de dados do fórum, apesar de as muitas consultas parecerem ter sido bem-sucedidas à medida que avançavam. Poderia haver um banco de dados diferente envolvido que está sendo preenchido devido à importação ser executada em seu próprio contêiner separado do contêiner discourse_dev?
No caso do procedimento 2, simplesmente não é possível executar a compilação, que falha com “Ocorreu um erro ao instalar tiny_tds (2.1.5), e o Bundler não pode continuar.”
Devo tentar fazer uma ‘instalação padrão’ (sem Docker, sem ambiente de desenvolvimento) no WSL e depois fazer a importação baseada em Docker?
É isso que eu recomendo. Raramente faço uma migração em desenvolvimento.
Além disso, você não precisa do tiny_tds, a menos que esteja usando mssql em vez de mysql/mariadb.
Muito obrigado, Jay. Seus tutoriais foram perfeitos, agradeço muito por tê-los.
Instalei o Discourse com sucesso em um novo VPS usando o processo de instalação padrão do Docker. Em seguida, executei o processo de importação de acordo com estas instruções e o script foi concluído sem problemas. Saí do contêiner e, em seguida, emiti o comando stop import e recebi a mensagem de que:
''Você tem menos de 5 GB de espaço livre no disco onde /var/lib/docker está localizado. Você precisará de mais espaço para continuar
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 24G 20G 2.7G 89% /
Gostaria de tentar recuperar espaço limpando imagens e contêineres do docker no sistema? (s/N)‘’
A recuperação de espaço não produziu espaço adicional. Então, como proceder? Posso excluir com segurança todos os arquivos de imagem que carreguei em /data? Não tenho certeza se eles ainda são necessários.
Obrigado.
Se a importação parecer ter sido concluída e você estiver falando sobre as imagens que deveriam ter sido importadas, tudo deve ficar bem, mas você provavelmente não terá espaço suficiente para fazer um backup. Eu recomendaria fazer um upgrade do droplet para ter mais espaço. O preço por dia não deve ser um grande problema.
Obrigado por este conselho, Jay.
Caso estes detalhes sejam úteis para outros, removi apenas os arquivos de imagem, o que liberou ~ 3,4 GB, totalizando 6,1 GB disponíveis, e o Sidekiq então processou com sucesso o pós-processamento. O espaço em disco foi desde então aumentado em 20 GB adicionais.
Para constar, esta foi uma importação de um fórum phpBB versão 3.3.0 com pouco mais de 73.000 posts em pouco mais de 8.000 tópicos com pouco mais de 1300 usuários.
O único problema que encontrei, até agora, é que alguns nomes de usuário são estranhos, mas isso foi discutido acima e não é fatal.
Haverá um intervalo entre esta importação e o encerramento do fórum phpBB de origem. Posso simplesmente deixar o contêiner Docker de importação no lugar e depois usá-lo em um backup incremental para migrar posts feitos após esta importação?
Quando fiz minha migração do phpBB 3.3.x, para fazer minha importação final, coloquei o site phpBB em "modo de manutenção", usei rsync para atualizar os anexos, avatares e smilies, depois importei um novo dump de dados e tive que reconstruir a importação para fazer a execução final do script de importação, mas eu havia saído da importação antes disso.
@DonH Você importou as senhas do phpBB e fez com que funcionassem com o plugin Migrate Passwords?
Não importei senhas do phpBB por algumas razões. Eu não queria potenciais conflitos com plugins e queria forçar as pessoas a atualizarem suas senhas, e essa migração parecia uma boa maneira (e uma boa desculpa) para fazer isso. A segurança no servidor de hospedagem web do phpBB é tratada pela empresa de hospedagem, com o novo VPS não há tal luxo.
Para ser claro, você reimportou todo o seu banco de dados pela última vez e não fez uma atualização incremental?
Minha compreensão e experiência é que, se você fizer um dump de dados do seu fórum phpBB - do phpMyAdmin, por exemplo - e carregar o arquivo para /var/discourse/shared/standalone/import/data, reconstruir a importação e, em seguida, executar novamente o comando de importação, o script de migração não tocará em contas de usuário, postagens, etc. já importadas, apenas em entradas de banco de dados que não foram importadas anteriormente.
Em essência, ele está fazendo uma atualização incremental, mas não toca em entradas existentes, então você pode perder alguns dados; digamos, se um usuário editou uma postagem já importada ou alterou seu endereço de e-mail.
Se você deixar a configuração do plugin migratepassword_allow_insecure_passwords desmarcada, o plugin migratepassword não permitirá senhas migratórias consideradas inseguras pelo Discourse, honrando todas as configurações de complexidade, como comprimento mínimo e caracteres exclusivos.
Não tenho certeza a que tipo de conflitos de plugin você está se referindo?
@RGJ O plugin migratepassword funcionará com o phpBB 3.3?
Estou no processo de fazer uma importação com um fórum phpBB 3.3.8 neste momento, e estou importando as senhas para tentar.
Como você seria capaz de migrar do myBB?
Você pode pesquisar por myBB e a tag #migration::tag, talvez você encontre um howto
Ok, obrigado pelas informações!
Obrigado por esse esclarecimento, Richard. Eu não estava me referindo a nenhum conflito específico, apenas à possibilidade de algo inesperado acontecer em território desconhecido. Fiz a importação deliberadamente antes de adicionar quaisquer plugins. Principalmente, porém, quero forçar nossos membros a atualizarem suas senhas.
Essa migração ocorreu sem problemas, realmente, então parabéns a Gerhard e a todos os outros envolvidos por um script bem temperado. Estou ansioso para personalizar nosso novo quadro de mensagens.
Sim, funcionará, nós adicionamos recentemente o suporte a Argon2 no plugin.
Richard apoia o plugin em sua hospedagem. Nunca ouvi falar que causou problemas. Muitos importadores importam as senhas e funciona. Eu até o fiz funcionar para um script de importação que escrevi para outro fórum aleatório.