Nas próximas semanas, moveremos vários plugins populares do Discourse para o repositório principal. Isso significa que o Discourse virá com um número maior de plugins por padrão, e será mais fácil para nós mantê-los todos testados e atualizados.
Todos esses plugins permanecerão desativados por padrão, portanto, isso não terá nenhum impacto visível nas comunidades existentes. Se você usa um serviço de hospedagem gerenciada como o discourse.org, não precisa fazer nada.
Comunidades auto-hospedadas
Se você auto-hospeda o Discourse e já está usando um desses plugins, será solicitado a remover a linha relevante do seu arquivo app.yml antes da próxima reconstrução.
Ambiente de Desenvolvimento
Se você já tem um dos plugins instalado localmente e, em seguida, puxa a versão mais recente do core do Discourse, uma de duas coisas acontecerá.
Se você usa links simbólicos para seus plugins, você receberá um erro durante git pull. Para resolver o problema, exclua o link simbólico e execute git pull novamente.
Se você clona plugins diretamente, o git pull do core será bem-sucedido, mas você terá algumas ‘alterações não preparadas’ surpreendentes causadas pelos repositórios git aninhados. A melhor maneira de prosseguir é excluir o diretório afetado e, em seguida, restaurá-lo do main. Por exemplo:
Obrigado. Com meu conhecimento limitado de desenvolvimento e programação, ainda gostaria de lhe fazer uma pergunta. Esses plugins, que são originalmente componentes destinados a serem adicionados a uma instalação básica, podem um dia perder seu caráter de plugin e se tornar parte integrante de uma instalação básica, sem serem chamados de plugins?
Eles podem fazer isso, sim. Em particular, os plugins de autenticação (por exemplo, apple-auth) são muito propensos a serem absorvidos pelo núcleo, assim como nossos outros métodos de autenticação integrados (por exemplo, Google, Facebook, etc.).
Se me lembro corretamente da minha experiência, você só poderá atualizar o docker primeiro. Depois de atualizar o docker, você verá uma mensagem na interface do usuário de atualização explicando que você tem que atualizar via linha de comando e como fazer isso.
Então, quando você atualizar na linha de comando, você verá a DICA para cada plugin que você precisa remover de app.yml, como explicado na primeira postagem acima.
Esta é uma boa atualização, mas isso foi realmente necessário? Dar uma falha na reconstrução parece um pouco severo para mim… um aviso na interface do usuário ou uma atualização automática (ou simplesmente ignorá-los completamente) teria sido melhor do que colocar uma arma na minha cabeça e dizer “remova isso agora”
Isso me pegou desprevenido na semana passada quando tentei atualizar pela linha de comando e falhou (plugin de reações).
Isso me pegou desprevenido novamente quando minha atualização pela linha de comando falhou novamente esta manhã (plugin de explorador de dados).
Eu agradeceria muito um aviso na linha de comando antes que o processo de atualização comece e, inevitavelmente, falhe.
Duas vezes em duas semanas minhas atualizações falharam e isso significou que meu Discourse ficou offline durante o tempo que levei para depurar o problema, editar configurações, tentar novamente, etc. - tudo isso em um leve estado de pânico porque tudo está quebrado.
Não é apenas uma questão de excluir clones de plugins redundantes.
Também temos o problema de conflitos de versão de gem.
Estou passando por um processo de downgrade de dependências específicas em alguns dos meus próprios plugins porque o plugin principal está bem atrasado.
Portanto, essa mudança introduz algumas dependências extras desnecessárias, na minha opinião, e torna a reconstrução mais frágil.
Estou curioso, você obteve essa lista de plugins de instalações do Discourse em uso? Ela corresponde a quase 50% da minha própria instalação principal!
Estou imaginando, ter todos esses plugins agrupados no núcleo não sobrecarregaria os fóruns? Por exemplo, provavelmente haverá alguns plugins que os administradores não querem em seus fóruns (por exemplo, Discourse AI), mas não terão escolha a não ser tê-lo adicionado. Ele pode ser desativado, é claro, mas estou imaginando se os arquivos adicionados e outras coisas não deixarão os fóruns mais lentos?
No lado do cliente, o Discourse não serve nenhum ativo JavaScript para plugins desativados, portanto, não haverá impacto lá.
No lado do servidor, para plugins implementados corretamente (como todos estes são), as personalizações de plugins são ignoradas quando desativados. Então, sim, tecnicamente pode haver uma pequena sobrecarga para verificar o estado ativado/desativado, mas deve ser minúscula.
Os plugins que estamos mesclando aqui são aqueles que executamos em todas as instâncias do Discourse em nossa hospedagem discourse.org. Portanto, todos eles são muito bem testados em escala.
Existe alguma razão para que você esteja fazendo tudo isso de uma vez, pouco antes do lançamento? Para os tradutores que fazem isso em seu tempo livre, 3.000 strings adicionais em duas semanas é muito. E mesmo em idiomas onde os plugins foram traduzidos anteriormente, todos os 3.000 textos precisam ser revisados novamente. De vez em quando, 300 seriam provavelmente mais gerenciáveis do que 3.000.
Para comunidades auto-hospedadas que já executam um ou mais desses plugins, os plugins perderão dados de configuração ao serem removidos do app.yml e incorporados ao core?
Tenho o plugin de IA configurado exatamente como quero; se eu precisar reconfigurá-lo (ou pelo menos anotar as opções de configuração para poder adicioná-las novamente), seria bom saber agora.
Temos tentado tornar isso o mais tranquilo possível para os tradutores, utilizando a memória de tradução no crowdin, para que as traduções não precisem ser refeitas do zero. Mas ainda assim, concordo, há muito para revisar.
Gostaria de saber se há mais que podemos automatizar aqui, por exemplo, talvez possamos “aprovar automaticamente” quaisquer strings desses plugins, em vez de exigir uma revisão
Este tópico meta não é realmente o que você gostaria de ver.\n\nA dificuldade reside em saber quais plugins remover do seu app.yml e quais não remover.
