Framework de script para reorganizar tópicos e categorias

Para criar scripts para reorganizar um Discourse grande em colaboração com a liderança do meu site, escrevi um framework simples para empacotar um monte de pequenos scripts Ruby que seriam controlados por um arquivo de configuração YAML. Dessa forma, posso restaurar um backup em um site de staging, executar meu script, obter feedback, alterar algumas linhas do YAML, restaurar o backup, executar o script com a nova configuração e repetir até ficar satisfeito.

Tenho quase 600 linhas de configuração para o meu site, e fazer isso por manipulação manual através da UI simplesmente não aconteceria. Nem uma vez, muito menos várias vezes para acertar. Sei disso porque da última vez que propus fazer mudanças drásticas, desisti literalmente de tentar. Em contraste, com este script, agora posso completar todo o ciclo em apenas alguns minutos por iteração, mesmo que o site tenha cerca de meio milhão de posts e mais de 100 categorias. Isso me permite obter feedback rápido da liderança do meu site e estarei preparado para migrar meu site rapidamente.

Documentação mais detalhada está no arquivo README no repositório com o código:

:warning: Este script não faz verificação de erros. É bastante insano executá-lo no seu site ao vivo. Ele se destina a ser executado em um site de staging, validar o resultado e, em seguida, ser levado para o ar. Como autor, ainda pretendo executá-lo dessa forma. Se você executá-lo diretamente em um site ao vivo, você ficará com todos os pedaços quando ele quebrar. :warning:

Da documentação, um arquivo de configuração pode parecer com isto:

---
- describe:
    context: Old Name
    category: 7
    name: New Name
    description: New description of category
    slug: new-slug
- movePosts:
    context: move only faq posts from the Support category to the Documentation category
    source: 3 # Support category ID
    target: 6 # Documentation category ID
    withTag: faq
    hide: false # do not hide the Support category when done
- movePosts:
    context: consolidate How-To category into documentation with how-to tag
    source: 8 # How-To category ID
    target: 6 # Documentation category ID
    addTag: how-to
    hide: true # hide the old How-To category, visible only to Admin

A saída de progresso enquanto ele está em execução pode então parecer com isto.

==========
Move hidden categories out of the way so they don't clutter admin view
setHiddenCategory: {:category=>11}
==========
Rename Old Name to New Name
describe: {:category=>7, :name=>"New Name", :description=>"New description of category", :slug=>"new-slug"}
==========
move only faq posts from the Support category to the Documentation category
movePosts: {:source=>3, :withTag=>"faq", :target=>6}
==========

Para usar isto, coloque o seu arquivo YAML em /var/discourse/shared/app/tmp/rearrange.yaml e, em seguida:

cd /var/discourse
./launcher enter app
git clone https://github.com/johnsonm/discourse-site-rearranger.git script/discourse-site-rearranger
ruby script/discourse-site-rearranger/rearrange.rb /shared/tmp/rearrange.yaml

No entanto, é razoavelmente provável que este script não faça exatamente tudo o que você precisa. É realmente um framework que torna muito fácil adicionar novas ações que automatizam mais aspectos de uma modificação de site com script com apenas algumas linhas de código. Tudo o que você precisa fazer é definir um método com algumas linhas de código, e você será capaz de invocá-lo corretamente a partir do arquivo YAML.

Você tem pensado em melhorar a organização do seu site, mas hesitando em usar a UI, ou se perguntando como confiar que você será capaz de replicar seus testes em um site de staging para tornar as alterações ao vivo? Dê uma olhada e me diga o que você acha!

5 curtidas

Estou usando este script para criar um site de teste, como um clone do meu site principal. Alta fidelidade visual é parte do objetivo, mas pode facilitar a postagem acidental no site errado ao revisar alterações, e essas postagens acidentais serem perdidas na próxima vez que eu atualizar o site de teste.

Primeiro, tornei meu site de teste somente leitura quando pedi feedback público. Mas o login é desativado enquanto o site está em modo somente leitura, então eles não puderam fazer login quando pedi.

Adicionei uma nova ação publicCategoriesReadonly que torna as categorias visíveis anonimamente graváveis apenas por :admins e :readonly por :everyone para permitir que as pessoas façam login e explorem, mas ajudem a evitar postagens acidentais no site errado. Agora o site como um todo não está em modo somente leitura, mas as categorias públicas estão.

É possível referenciar categorias como hashtags por slugs. Este script permite mover o conteúdo de categorias juntas e alterar slugs, o que faria com que posts anteriores não mais fossem vinculados após um rebake. (Antes de um rebake, os redirecionamentos de permalink fariam os links funcionarem.)

Atualizei o script para rastrear tags antes e depois da migração e remapear referências a categorias alteradas em posts.

Adicionei uma ação migrateRetortToReactions ao framework para aqueles de nós que instalaram o Retort e desejam migrar para um plugin compatível.

2 curtidas

Uau! Essa é uma ótima notícia. Seria ótimo se alguém pudesse transformá-la em uma tarefa do rake e enviá-la para o plugin de reações.

Vou dar uma olhada nisso em breve.

1 curtida

Ter isso como uma tarefa do Rake no plugin parece inteligente para mim.

Assinei o CLA da CDCK para que qualquer interesse de direitos autorais da minha parte no trabalho resultante não atrapalhe, e ele pode ser colocado sob a mesma licença do próprio plugin.

Também posso imaginar que errei em algo; se você encontrar algo errado nisso, adoraria saber porque planejo executar esse script no meu próprio site em algumas semanas. :smiley:

Em uma escala maior, se você achar este framework útil para o seu próprio trabalho de suporte a instalações do Discourse, mas gostaria de mais tratamento de erros, eu aceitaria PRs. Eu apenas quero ter certeza de que qualquer PR para ele seja de alguém que assinou o CLA e concorda que quaisquer partes úteis dele possam ser incorporadas ao Discourse oficial, o que sei que é verdade para você…

2 curtidas

Descobri no tópico Retort que @angus tem um branch com conversão orientada por UI, o que eu tinha perdido completamente.

Meu script mergulha nos internos que poderiam concebivelmente mudar algum dia, e depois que eu fizer minhas conversões com este script eu não notarei se esses internos mudarem. Eu primeiro tentei fazer “do jeito certo”, mas descobri que o plugin Reactions não expõe uma interface que permite isso. @angus tem uma visão mais longa:

@pfaffman se você fizer uma tarefa rake, você pode querer colocá-la em um PR que também faça as mudanças nas interfaces para que, por exemplo, created_by possa ser passado, assim como silencioso, em vez de usar o “atalho” que eu usei. Nesse ponto, a tarefa rake estaria lá para migrações de linha de comando, e simultaneamente desbloquearia @angus fazendo uma migração orientada por UI.