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”.
