Acho que o que eles estão sugerindo é que, se um plugin que já estava incluído no núcleo fosse listado em app.yaml, ele seria simplesmente ignorado. Com uma notificação afirmando que incluí-lo em app.yaml era redundante e o proprietário poderia removê-lo.
Eu também acho um pouco irritante que, desde que eu tenha quaisquer plugins listados em meu app.yaml, eu sempre corro o risco de uma atualização falhar. Portanto, toda vez que faço a atualização, preciso verificar novamente para ver se algum dos meus plugins foi adicionado ao núcleo.
Por que não simplesmente ter um script que faça isso para o Sysop?
Eu mesmo organizo os plugins por equipe ou autor para facilitar um pouco a minha vida, então sei quais plugins são oficiais e tal. Mas se a ideia é tornar o Discourse mais amigável, isso precisa ser feito do lado da equipe.
Não é muito diferente de quando você aconselhou as pessoas quando um usuário tem uma atualização quebrada devido a uma falha na atualização do Postreq (então?).
Com plugins, é exatamente aí que o conceito do Procourse Installer foi uma ótima ideia para simplificar a instalação e desinstalação de plugins sem precisar usar a linha de comando.
Concedo que entendo que pode ter precisado de mais polimento em caso de algo dar errado. Mas isso poderia ser fácil o suficiente com um arquivo de log ou um simples fallback, se necessário, da linha de comando. Agradeço que isso possa torná-lo mais atraente para auto-hospedagem em vez de um plano pago. No entanto, existem vantagens suficientes para um plano pago para ainda seguir esse caminho.
Este tipo de gerenciador de plugins também poderia ser criado ou adaptado para permitir que planos hospedados instalem plugins dentro de seu nível hospedado, pois alguns plugins podem não ser necessários no plano específico.
De fato, perdi uma postagem antiga sobre o chat estar incluído e tentei instalar. Não acho que a tag foi atualizada no plugin. Claro que isso travou o site, pois não gostou de tentar instalar o plugin quando, em teoria, ele poderia simplesmente ter ignorado a entrada com uma reconstrução completa avisando que poderia ser removida por ser desnecessária.
Com a recente iniciativa de agrupar mais plugins oficiais no core, eu estava me perguntando se o plugin Who’s Online está sendo considerado para inclusão.
Notei que ele está disponível nos planos de hospedagem oficiais (contando para a cota de plugins), então estou curioso se isso indica um movimento em direção à adoção mais ampla.
Entendo totalmente se restrições de desempenho ou adequação filosófica significarem que ele deve permanecer desativado por padrão, a menos que especificado de outra forma em app.yml.
Atualmente, não planejamos mover mais plugins para o core. Cakeday foi o último, e teve que ser feito separadamente do lote principal por causa de algumas complicações na forma como ele estava anteriormente habilitado por padrão.
Completamente entendo a frustração sobre o processo aqui - certamente não é tão suave quanto eu gostaria. Para dar algum contexto: o problema fundamental é que os arquivos app.yml não são um arquivo de configuração do Discourse. Eles são uma configuração do pups, e as linhas de instalação de plugins são apenas comandos shell.
Trazer lógica específica do Discourse para o pups, e fazê-lo ignorar certos comandos shell, não é realmente uma opção. Esta ferramenta não é usada apenas para o Discourse. Além disso, suspeito que um número de pessoas ficaria infeliz se mudássemos os comandos shell em execução durante o bootstrap sem o conhecimento delas.
Então, chegamos à solução mais limpa que pudemos encontrar com as ferramentas disponíveis: forçar uma reconstrução da CLI e, em seguida, exibir uma mensagem pedindo às pessoas para removerem a linha afetada de sua configuração.
Pense cuidadosamente antes de instalar este plugin
Acho que “instalar” pode ser melhor expresso como “habilitar” lá - se isso for tecnicamente correto.
A formulação atual pode dar a impressão de que ter plugins adicionais agrupados é uma preocupação filosófica ou de desempenho - quando na verdade se trata apenas de se eles estão habilitados. Como um plugin recém-agrupado que não estava habilitado antes é desabilitado por padrão após a reconstrução, o risco não está em tê-lo instalado com o core, mas em ativá-lo.
Agora que esse problema específico foi resolvido (na maior parte) nos plugins empacotados, mas em outros plugins isso pode ainda estar acontecendo aqui e ali.
O plugin discourse-categories-suppressed adiciona uma interface de usuário simples e opcional para ocultar categorias selecionadas do feed “Mais recentes”. Ele se integra através de um único menu suspenso em:
Admin → Configurações → Categorias
“Categorias suprimidas da página inicial”
Isso parece uma configuração central muito natural — especialmente porque:
• É oficial e ativamente mantido
• Permanece desativado por padrão, a menos que um administrador opte por ele
• Muitas comunidades (incluindo a minha) dependem de “Mais recentes” como a visualização principal e desejam um controle mais refinado sobre o que aparece lá
A equipe consideraria incluir este plugin (ainda desativado por padrão), para que os administradores possam usar essa opção sem precisar instalar nada extra?
Obrigado pela consideração — parece uma pequena preferência de interface de usuário que muitos sites se beneficiariam por ter disponível “pronto para uso”.
Não tenho certeza se isso é intencional, mas queria relatar:
Estamos em uma versão estável desatualizada v3.5.4 e estávamos usando o plugin cakeday. No entanto, as reconstruções (da mesma versão do Discourse) pararam de funcionar porque o cakeday havia sido mesclado ao core. Então, desativei o plugin no arquivo yml e… bem, ele sumiu. Agora ele reconstrói novamente, mas não temos mais aniversários de conta, pois a interface de administração não mostra nenhum sinal da funcionalidade estar instalada.
Eu suponho que seja porque estamos em uma versão estável desatualizada, mas ainda foi um resultado inesperado para uma reconstrução da mesma versão do Discourse.
O plugin cakeday não está incluído na versão 3.5.4, então é por isso que você não o está vendo mais.
Você tem certeza de que foi por isso que elas começaram a falhar? Se você viu algo como:
HINT: O plugin ‘$plugin’ agora está incluído no Discourse e não deve ser incluído na sua configuração de contêiner
Então, receio que isso seja exibido para qualquer reconstrução com falha quando o plugin cakeday estiver incluído no arquivo de configuração. Esta foi a maneira mais eficiente que encontramos para alertar as pessoas sobre o problema, mas pode ser confuso para quem está executando versões mais antigas do núcleo.
Portanto, se você precisa do plugin cakeday, acho que você deve ser capaz de adicioná-lo novamente ao seu arquivo app.yml e reconstruir. Suspeito que a falha foi causada por outra coisa, que você já resolveu.
Como um aparte: eu recomendaria fortemente a atualização para uma versão suportada. A versão 3.5 não está mais recebendo atualizações de segurança e pode estar vulnerável a ataques.
Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
Adicionar o plugin novamente ao app.yml causa o erro acima. Removê-lo imediatamente faz com que a compilação funcione novamente. Este plugin parece ser o único problema.
Estou ciente de que estamos em uma versão desatualizada e que a atualização está no roteiro. Apenas queria apontar que, embora não tenhamos mudado a versão que estamos usando, a 3.5.4 passou de compilar bem (com o plugin) para não compilar mais com o plugin, e não parece haver como recuperar a funcionalidade do plugin (através de plugin ou no core).
Interessante! Eu me pergunto se é porque nossa imagem docker agora inclui o discourse-cakeday, e então quando o core é “rebaixado” para 3.5, ele deixa um diretório vazio para trás.
Se você adicionar rm -rf discourse-cakeday antes da linha git clone https://.../discourse-cakeday, isso deve limpar. Então ficaria algo como:
Desculpe por levar isso para uma pequena tangente, mas não acho que haja um tópico mais adequado e está um pouco relacionado com o problema anterior.
Desde minha mensagem anterior, acho que houve mais alterações feitas no discourse/docker_manager que estão quebrando mais coisas em compilações de versões mais antigas. Após uma reconstrução hoje, toda a seção de administração do Discourse parou de funcionar com erros como este:
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
Eu consegui consertar a compilação usando isto no yml:
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
Não sei qual foi o commit ofensivo, mas isso foi o suficiente para fazer funcionar novamente.
Eu sei, eu sei, eu devo atualizar (quero dizer isso). Mas provavelmente existem outras pessoas como nós que estão presas a versões mais antigas por mais tempo do que o planejado por um motivo ou outro, e ter as compilações mais antigas quebrando sem alterar a versão é um pouco inesperado.
De qualquer forma, já encontrei uma solução alternativa até atualizarmos, então estou apenas compartilhando isso caso seja útil para outros na mesma situação.
