Avaliação pré-migração para um grande fórum Drupal 7

Migração
1

Olá a todos, eu possuo e administro o que acredito ser um dos maiores fóruns baseados em Drupal da internet, com quase 2 milhões de posts. O Drupal 7 está morrendo, e o Drupal 8/9 está se tornando mais um framework para programadores web do que um sistema de gerenciamento de conteúdo pronto para uso. As novas versões do Drupal simplesmente não oferecem os módulos de terceiros que preciso para que meu fórum continue com suas funções básicas, e graças às maravilhas do PHP e às muitas outras peculiaridades do Drupal, a atualização seria tão infernal quanto migrar para uma plataforma completamente diferente. Então, terei que engolir o sapo e migrar para outra coisa. Tenho quase certeza de que terá que ser o Discourse devido a um aspecto único do estilo da minha comunidade de fórum: sou o único moderador, e não é meu trabalho em tempo integral. Então, ao longo dos anos, usei os frameworks flexíveis Rules e Flag no Drupal para criar um sistema fragmentado de moderação comunitária de spam e posts ofensivos, com remoção automática de posts e/ou fechamento de contas de usuários em certos limites com base em quão novo é o usuário e quantos usuários o sinalizaram, levando em consideração também a novidade e a atividade recente de sinalização dos usuários que o sinalizam. Em outras palavras, é quase exatamente o que o Discourse implementou. Fico muito feliz em ver que o Discourse reconheceu o valor da moderação comunitária e implementou um sistema tão abrangente e bem pensado “out-of-the-box”. O Drupal 7 foi e ainda é o único CMS flexível o suficiente para permitir esse tipo de funcionalidade personalizada sem ser um desenvolvedor experiente, o que eu não sou. Então, parece que vou migrar para o Discourse. No entanto, tenho algumas preocupações.

  1. Sistema de moderação comunitária: Nosso fórum está atualmente avaliando uma instalação “playground” do Discourse. Fiquei impressionado com o quão abrangente e bem pensado é todo o sistema. Mas a comunidade notou algumas peculiaridades:
    • Eu realmente não gosto de como ele esconde posts automaticamente removidos atrás de “Ver conteúdo ignorado”. Se um post é ruim o suficiente para ser removido pela comunidade, ele é altamente ofensivo ou spam puro, e eu não quero que visitantes ou usuários tenham a opção de vê-lo. Isso é especialmente problemático no caso de tópicos que são spam ou têm um título ofensivo. E os rastreadores de mecanismos de busca não veriam o conteúdo oculto de spam? É possível configurar o tempo sem intervenção do usuário antes que um post de spam oculto automaticamente seja completamente excluído da vista pública? E quanto aos tópicos e posts que foram sinalizados pela comunidade como inadequados?
    • Li aqui que “Nota: Todos os valores mencionados acima são as configurações padrão. Eles podem ser alterados pelos administradores nas configurações do site” em relação aos limites que levam à remoção de posts e/ou silenciamento de usuários, mas não estou vendo essas configurações granulares na minha instância de teste do Discourse. Tudo o que consigo encontrar é “sensibilidade de ocultar post” e “sensibilidade de silenciar novo usuário”, mas não entendo a que essa sensibilidade realmente se refere em termos concretos.
    • Eu gostaria de remover o motivo “fora de tópico” para sinalizar um post. Nossa comunidade de fórum é muito relaxada nesse sentido e tem uma cultura de fórum onde posts fora de tópico são muito comuns e bem aceitos. Atualização: Parece que isto pode funcionar.
  2. Migração de mensagens privadas: O fórum atual tem quase um milhão de threads de mensagens privadas usando o módulo Drupal 7 privatemsg, e o script de migração Drupal → Discourse não o lida. Isso parece uma omissão importante, porque, apesar de ser um módulo de terceiros (no estilo típico do Drupal), é basicamente a funcionalidade de mensagens privadas de facto que os administradores do Drupal 7 usam.
  3. Conversão de formato de post: Infelizmente, o fórum atual usa uma mistura de posts em HTML puro e Textile. Entendo que o script de migração pode lidar com HTML puro (por favor, corrija-me se estiver errado), mas não com Textile. Se possível, gostaria de converter os posts Textile para HTML ou Markdown, o que for mais fácil. Fui informado de que o Pandoc pode ser integrado ao script de migração, mas que isso também aumentaria massivamente o tempo de migração. Procurei módulos Drupal para converter o formato de posts existentes, mas só encontrei isto, que não suporta processamento em lote para a quantidade massiva de posts, e não suporta o paradigma de “comentários” do Drupal, que compõem a vasta maioria dos “posts” que precisam ser convertidos. Então, pensei em fazer algum tipo de find/replace offline no arquivo de dump do banco de dados com sed, semelhante ao que é descrito aqui. Sugestões ou soluções seriam bem-vindas. Sou um usuário experiente de Linux e trabalhei com expressões regulares intermitentemente, mas ainda não sou bom nelas. Edição: Isto é uma opção interessante para encontrar/substituir assim que os dados brutos estiverem no Discourse.
  4. Anúncios: Fico muito feliz em ver que o Plugin de Anúncios para Discourse parece ter amadurecido muito desde a última vez que o examinei. Entendo que os anúncios internos me permitirão colocar banners de imagem em locais específicos com um link de destino ao serem clicados, e que se vários anúncios forem atribuídos ao mesmo local, eles serão selecionados aleatoriamente, correto? No entanto, não tenho ideia de como lidar com o paradigma móvel. No meu fórum atual, tenho um banner horizontal superior e três banners verticais na barra lateral esquerda, todos os quais não seriam viáveis para usuários móveis na interface responsiva do Discourse. Edição: Pode ser que eu precise modificar o Plugin de Anúncios para minhas necessidades, oferta paga aqui.
  5. Permalinks: O esquema de URL do Drupal tem dois componentes principais: /node/XXXXXXX e links para comentários específicos dentro desses nós /comment/YYYYYYY#comment-YYYYYYY (YYYYYYY é o mesmo em ambas as ocorrências). O script de migração Drupal 7 → Discourse manterá automaticamente esses links para que os links em posts para outros tópicos ou posts ainda funcionem e mantenham o SEO? E quanto a um arquivo sitemap.xml para os mecanismos de busca?
  6. Processamento em lote: Durante a migração, ele será executado em lotes? O que acontece se ele atingir um erro? Após corrigi-lo, ele continuará ou exigirá que comece do início?
  7. Usuários de dispositivos Apple antigos: Claro, entendo os perigos de usar navegadores desatualizados. Para Windows e dispositivos Android antigos, quase sempre há uma maneira de instalar um navegador moderno compatível com o Discourse. Mas estou preocupado com um de meus usuários que afirma ter um Mac de 2015 que não recebe atualizações e não tem como instalar nada além da versão antiga do Safari, que está mostrando avisos de depreciação com o Discourse. Eu realmente sei muito pouco sobre dispositivos Apple, além do fato de que eles são muito mais restritos. É realmente tão difícil instalar outros navegadores modernos neles?
  8. Armazenamento de imagens / uploads: Meus usuários e eu adoramos a facilidade de fazer upload de imagens no Discourse, mas estou um pouco preocupado com o espaço de armazenamento e os custos. A melhor opção a longo prazo seria montar um volume de armazenamento de rede no VPS, se necessário. Se eu configurar inicialmente o Discourse com o local de upload padrão, isso causará problemas para movê-lo para um volume diferente mais tarde?
  9. Backups:
    • Gostaria que houvesse um sistema para backups diferenciais ou, melhor ainda, deduplicados. Atualmente uso o Duplicity com Amazon S3 para meu fórum Drupal, e os custos são incrivelmente baixos para um histórico muito longo de revisões. Alguém sabe de imediato em quanto tempo após a criação de um arquivo S3 uma regra pode fazer a transição para o Glacier?
    • A interface de backup do Discourse permite excluir arquivos no Amazon S3? Sei que é um pouco extremo, mas eu gostaria de desativar essa funcionalidade, pois configurei meus buckets S3 com apenas permissões PUT, GET e LIST para impedir que um hacker no sistema comprometido exclua meus backups remotos. Então, uma regra de ciclo de vida do S3 entra em vigor e exclui os arquivos mais antigos do lado do servidor após um certo tempo.
  10. Plugin Stop Forum Spam: Não quero usar Akismet, mas sempre tive bons resultados com o StopForumSpam.com para evitar a criação de muitas contas de spammers. Alguém sabe se o plugin para Discourse tem limites configuráveis para quantos hits um nome de usuário, IP ou endereço de e-mail deve ter no banco de dados para ser rejeitado? Edição: Não, não tem. Solicitado aqui. Infelizmente, também não intervém para realmente impedir a criação de contas se eles tiverem hits suficientes no banco de dados do SFS, como faz no Drupal.

Desculpe pelo post longo. Agradeço antecipadamente a todos pela visão, e muitos agradecimentos a toda a equipe do projeto Discourse por este excelente produto.

2

Acabei de me deparar com isto:

aplica um conjunto de transformações baseadas em regexp, como substituir tags BBCode por Markdown

Foi atualizado pela última vez em 2016, não tenho certeza se ainda é uma opção relevante.

Isso ainda é relevante? No script de importação do Drupal, estou vendo código como:

 create_posts(results, total: total_count, offset: offset) do |row|
        topic_mapping = topic_lookup_from_imported_post_id("nid:#{row['nid']}")
      end

 def create_permalinks
    puts '', 'criando permalinks...'

    Topic.listable_topics.find_each do |topic|
      begin
        tcf = topic.custom_fields
        if tcf && tcf['import_id']
          node_id = tcf['import_id'][/nid:(\d+)/, 1]
          slug = "/topic/#{node_id}"
          Permalink.create(url: slug, topic_id: topic.id)
        end
1 curtida
3

O script normalmente puxa 1000 posts por vez.

Ele rastreia o que foi processado, para que execuções subsequentes possam pular dados já processados. Em scripts que toquei, também incluo uma configuração de import_after que acelera ainda mais as execuções subsequentes carregando apenas dados recentes (também útil para testar com apenas um pequeno subconjunto dos dados).

Precisarei analisar mais detalhadamente para ver se os posts estão incluídos em permalinks. Normalmente não estão, mas isso pode ser feito.

Você vai querer todos os seus uploads no S3, então seu backup incluirá apenas o dump do banco de dados. Você não pode realmente fazer nada para otimizar isso. Você pode deixar o Discourse manter um certo número ou dizer para não fazer isso (ou apenas definir o número de backups para um número grande) e deixar suas regras cuidarem disso.

1 curtida
4

Ah, esse é um ponto muito bom. Agora que penso sobre isso, serei cobrado de qualquer forma pelo armazenamento de uploads no S3, quer os uploads vão diretamente (e apenas) para o S3, ou se eles estarão dentro de múltiplos tarballs do backup do Discourse.

E quanto ao uso de um bucket sem permissões de exclusão para os backups do Discourse?

5

Mas se eles estiverem no S3, você terá apenas uma cópia.

Suspeito que funcionará se o Discourse não tiver permissão para excluir, embora eu não saiba.

6

Certo, e com os níveis insanos de redundância de dados do S3, isso seria geralmente considerado uma maneira responsável de armazenar uploads? Não mexi nas opções do S3 recentemente, mas acredito que eles também tenham regras de ciclo de vida para recuperar arquivos excluídos por um período? Estou pensando no caso de os uploads serem excluídos de alguma forma devido a uma chamada equivocada do Discourse, seja um bug de codificação (improvável e massivo) ou erro do usuário. Ou um evento de hacking, voltando à minha preocupação original sobre as permissões de exclusão no bucket.

7

Sim, você pode ativar o versionamento para que os arquivos não sejam excluídos quando forem marcados como excluídos. Se você não se importa com quanto espaço está pagando, pode fazer isso. Quando o Discourse exclui um arquivo porque ele não é mais usado, ele o move para uma pasta de “lápide” por um tempo antes de excluí-lo. Recomendo que você confie no Discourse para gerenciar os arquivos. Não sei se proibir o acesso de exclusão quebrará alguma coisa.

Você pode colocar backups em um bucket separado com permissões diferentes (mas as mesmas credenciais), se desejar.

1 curtida
8

Pergunta para @pfaffman ou qualquer outra pessoa que faça uploads no S3 – Sei que depende de um milhão de fatores, mas vocês têm pelo menos informações anedóticas sobre as cobranças de largura de banda e solicitações do S3 para um fórum de médio a grande porte com seus uploads no S3? Muito obrigado!

1 curtida
9

Pequena atualização aqui: Então, o que eu acho que vou fazer é manter meus uploads locais; terei armazenamento local suficiente por enquanto e a opção de expandi-lo com volumes de armazenamento adicionais, se necessário. Eu simplesmente não quero lidar com a complexidade e o custo de uma CDN e as cobranças imprevisíveis de armazenamento de objetos e, acima de tudo, os custos de transferência para servir imagens do site ao vivo. Em seguida, farei backups automáticos do S3 para o Backblaze B2, incluindo uploads e a opção s3 disable cleanup. O preço do Backblaze é tão barato que não deve ser um problema manter algumas semanas de backups diários, mesmo com os uploads redundantes. Acontece que o Backblaze B2 tem duas opções muito simples para buckets que são exatamente o que eu preciso: 1) regras automáticas de ciclo de vida para excluir arquivos após X dias e 2) impedir a exclusão ou modificação de arquivos por N dias (para evitar a pequena possibilidade de o servidor ser hackeado e o hacker usar as credenciais armazenadas para excluir meus backups remotos). Testei isso e parece funcionar bem; tentei excluir um arquivo de backup da GUI do Discourse que foi proibido de ser excluído pelo Backblaze, e ele simplesmente não fez nada.

Apenas para esclarecer para mim e para os outros: É possível fazer backup automático de uploads em armazenamento local para S3 se a opção backup with uploads estiver habilitada (padrão), certo?

1 curtida
10

Sim. Por padrão, os uploads locais são incluídos no arquivo de backup.

1 curtida