Se o erro disser que reactions, data explorer e solved ainda estão no seu arquivo yml, então eles provavelmente estão. Se você acredita que os comentou, eles podem ter sido inseridos duas vezes?
Vale a pena revisar a configuração e garantir que você editou o arquivo yml que corresponde ao seu site.
Olá
Consegui atualizar meu fórum para a versão estável mais recente 3.4.6. Antes disso, eu estava usando o plugin independente discourse-oauth2-basic para autenticação.
Não há login Oauth2 Basic em /admin/plugins.
Minha versão do discourse é 3.4.6.
DICA: O plugin ‘discourse-oauth2-basic’ agora está incluído no Discourse e não deve ser incluído na configuração do seu contêiner.
Remova a linha ‘git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse’ do seu arquivo containers/app.yml, e então tente novamente.
Para mais informações, veja Bundling more popular plugins with Discourse core
Eu tive que remover o plugin discourse-oauth2-basic antes de atualizar para a 3.4.6.
Você poderia me ajudar a entender o que pode ter dado errado?
Obrigado!
Hmm… será que é porque você está na versão estável?
Seguindo o prompt do sistema, removi o plugin discourse-oauth2-basic antes de atualizar com sucesso para a versão estável 3.4.6.
No entanto, descobri agora que as opções de configuração para OAuth 2 Basic estão faltando no painel de administração.
Se você estiver na versão estável, então nenhum desses tópicos se aplicará até depois do próximo lançamento estável no início de agosto. Portanto, você deve adicionar oauth2-basic de volta ao seu app.yml. A falha original deve ter sido por algum outro motivo.
Infelizmente, a lógica de ‘dica’ não é muito inteligente e não está ciente de estável vs. testes aprovados.
Eu também, mas o que podemos fazer a respeito, né? lol Acho que mais recursos nativos, ou seja, plugins, mesmo que desativados, não são uma boa solução para ajudar iniciantes a auto-hospedar.
@nat Olha isso, a tradução da minha citação e minha resposta
Não importa como eu tentei comentar as linhas de clone na seção de plugins, mas ele estava lendo essas linhas como se eu quisesse instalar os plugins. O que eu fiz? Removi a linha e finalmente funcionou.
Quando você atualiza, precisa verificar a lista de plugins incluídos no núcleo do Discourse para não adicioná-los na seção de plugins para instalar ou remover essa linha se ela estiver no seu arquivo app.yml.
Acho que, como estes são pré-instalados. Deveria haver opções que separem esses 
da lista instalada. Como a lista instalada é removível versus apenas poder ser desativada.
Talvez para plugins principais mesclados devessem estar sob algo como Plugins em Destaque. Ou Plugins Principais.
Com, é claro, talvez um filtro de Todos.
A sugestão deles não é ideal, mas funciona. Exemplo:
## Plugins vão aqui
## veja https://meta.discourse.org/t/19157 para detalhes
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
#- git clone https://github.com/discourse/discourse-hcaptcha.git
#- git clone https://github.com/discourse/discourse-calendar.git
- rm -rf discourse-adplugin
- rm -rf discourse-affiliate
- rm -rf discourse-ai
- rm -rf discourse-apple-auth
- rm -rf discourse-assign
- rm -rf discourse-login-with-amazon
- rm -rf discourse-lti
- rm -rf discourse-microsoft-auth
- rm -rf discourse-patreon
- rm -rf discourse-subscriptions
- rm -rf discourse-zendesk-plugin
(Ajuste conforme desejado)
7 posts foram divididos em um novo tópico: Solução de problemas de falhas de bootstrap no Discourse
A realidade aqui é que a branch estável é um LTS, e um muito bom. Ela recebe atualizações de segurança e é bem claro quais versões de plugins são compatíveis com ela (graças ao arquivo .discourse-compatibility). Admito totalmente que demorou muito para que tudo isso funcionasse, mas nos últimos dois anos, funcionou – o que é uma grande conquista da equipe.
Agora para a segunda parte da sua declaração. É de fato o caso que stable é frequentemente representado como algo que você não deveria querer. Mas na hospedagem Communiteq, oferecemos aos clientes a escolha gratuita entre stable (“estabilidade primeiro, novas atualizações duas vezes por ano, atualizações de segurança uma vez por mês”) e tests-passed (“sempre na vanguarda, novos recursos uma vez por mês”) nos últimos 2,5 anos e 85% escolhe ficar no stable.
Eu entendo isso. Mas isso não é um problema de desenvolvimento e não um problema de produção? Posso entender totalmente que você está fazendo isso em desenvolvimento. Mas adicionar esses plugins em uma instalação de produção padrão meio que anula a ideia de ter um plugin (que é algo não padrão por definição).
A única vantagem real de produção que vejo é a questão muito, muito específica de desinstalar plugins e hosts multisite. (Novamente, isso é uma coisa boa, todas as outras questões de produção foram resolvidas ao longo do tempo!)
Isso também poderia ter sido resolvido no script de configuração mostrando uma lista de plugins que os usuários podem marcar e, em seguida, adicioná-los ao app.yml.
Mas você ainda oferece conjuntos diferentes (subconjuntos) de plugins para diferentes níveis, certo?
Eu também teria preferido a abordagem de descomentar o app.yml.
Todos esses plugins são instalados em todos os nossos planos self-serve. Alguns níveis não têm acesso, mas eles permanecem instalados mesmo que não tenham acesso.
Não vamos mudar essa decisão, então isso é simplesmente algo com que as pessoas terão que conviver. Entendo que algumas pessoas estão chateadas, algumas pessoas são contra isso, mas isso simplesmente não vai mudar.
Isso nos dá velocidade durante o desenvolvimento, define nossas preferências, garante que o Discourse, como usado pela grande maioria das pessoas, seja mais estável.
Existem outros plugins… plugins principais não são os únicos plugins.
Uma postagem foi dividida em um novo tópico: Discourse não envia uma versão LTS
Concordo plenamente que faz sentido mover plugins populares e sua funcionalidade para a imagem principal. Especialmente se eles vierem dos mesmos codificadores (CDCK) do núcleo em si. Esta é uma prática comum até mesmo para outros projetos de software. Mas devemos resolver os problemas de inicialização - ainda estou otimista 
É o motivo pelo qual você não consegue reconstruir.
Este seria definitivamente o melhor caminho. Ainda pode ser implementado usando o código de remoção de plugin na postagem anterior.
Adicionar isso ao script de instalação oferece muito mais opções logo de cara e é bastante comum em programas permitir que você escolha se deseja ou não instalar certos recursos opcionais.
O arquivo de comparabilidade é legal. Embora, na minha opinião, informações de comparabilidade devam ser adicionadas aos tópicos. Com um link ou instruções para se o TC/plugin está disponível para instruções de instalação Stable e Tests-passed.
Obrigado pelo guia; isso funciona muito bem, exceto pelo plugin “automation”, que não pode ser removido, pois parece que o plugin de chat depende dele.
O plugin de automação é algo que realmente não deveria ser removido, para ser sincero. Ele tem tantos usos potenciais úteis. Precisa de mais tempo investido, na minha humilde opinião, para obter mais opções de automação.
Mas sim, é legal que haja uma opção para organizar, removendo complementos que, como o @RGJ apontou, os extras verdadeiros recentemente mesclados podem questionar se essas opções são desejadas para instalar. Talvez até um script separado para depois da instalação, apenas para tornar as coisas mais amigáveis para auto-hospedados, para que alguns que possam querer evitar ter que editar o app.yml.