Tendo sido afetado pelo problema de “falha na reconstrução do plugin” no início da minha auto-hospedagem do Discourse, posso apreciar o desejo de agrupar versões conhecidas e boas no núcleo. E potencialmente oferecer uma seleção mais rica de recursos.
Uma organização focada no cliente poderia ter feito uma pesquisa sobre a direção do plugin principal, ou pelo menos o momento. Talvez eu tenha perdido isso. Como fornecedor de ferramentas de TI para meus clientes (ou seja, usuários finais) tentando realizar um trabalho real com TI, vi muitos produtos serem revisados para excesso de complexidade e substituição final. Agora teremos auto-hospedadores removendo plugins que não precisam. Eu entendo isso e posso me juntar a esse clube. Na minha experiência, código adicional aumenta a complexidade de integração, o risco de erros de configuração e a superfície de ataque. Mas, mais cedo ou mais tarde, remover algo que o desenvolvedor do aplicativo assume que estará lá, também quebrará algo.
Eu teria preferido muito mais que os esforços dos jedi do Discourse fossem direcionados para trabalhar em um método robusto, mantido e com script para habilitar o armazenamento em nuvem de imagens, incluindo integração com CDN. A integração de e-mail SMTP é trivial em comparação, e isso foi quebrado com mudanças na MailGun e em outros serviços, causando problemas para sites auto-hospedados.
De fato, eu fortemente desaconselharia o uso de rm -rf nesses plugins. Como você disse, existem riscos em torno de interdependências inesperadas no futuro. Mas também, você criará uma diferença no repositório git principal, o que significa que as atualizações da interface do usuário via docker_manager quase certamente falharão.
Claro, deixar esses plugins em seu estado padrão ‘desabilitado’ é totalmente suportado e garantirá que eles não tenham nenhum impacto mensurável no desempenho.
Para auto-hospedeiros ou aqueles como eu que fornecem serviços de hospedagem para clientes, aqui está um grep simples que listará se algum dos novos plugins incluídos já está em seu containers/app.yml
Talvez considere alterá-lo para referenciar containers.*.yml para que também ajude qualquer pessoa que tenha feito uma instalação padrão de dois contêineres onde eles estariam em apenas web? Você realmente não quer que eles estejam em nenhuma de suas definições de contêiner, afinal.
@david você consideraria adicionar isso à postagem principal e mantê-la depois de integrar o cakeday?
Agradeça ao ChatGPT, que o elaborou exatamente corretamente em uma única tentativa a partir deste prompt:
Por favor, extraia as URLs do GitHub de cada um dos plugins mencionados neste post https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3
Compile-os em uma lista e crie um comando Unix que me diga se algum desses plugins já está mencionado em um ‘git clone’ no arquivo containers/app.yml desse Discourse.
Superficialmente, para mim, isso parece uma coisa razoável a se considerar em algum momento – ter uma maneira mais declarativa de definir quais plugins são carregados ou não no momento da inicialização, mesmo que a origem ainda esteja lá no disco.
Dito isso, não sei qual seria a viabilidade ou o esforço para fazer isso.
É certamente possível. Mas isso adiciona complexidade - mais uma coisa para dar suporte/manter. E seria útil apenas em ambientes de inquilino único (ou seja, não em ambientes de hospedagem compartilhada, onde inquilinos diferentes desejam plugins diferentes).
Se alguma coisa, acho que seria mais benéfico gastar tempo melhorando a experiência do usuário e o desempenho de plugins ‘desativados’ (o que já começamos a fazer desde esta grande fusão no núcleo).
além disso, não tentei remover os plugins, porque sinto que isso comprometeria meus relatórios de bugs para a meta, assim como até mesmo a tentativa de uma instalação de hospedagem compartilhada
Ufa, essa foi uma atualização complicada. Identificar o problema na bagunça do log de reconstrução não é nada trivial para começar. Encontrei, negligenciei outro plugin para remover da nossa configuração duas vezes, daí a 3ª tentativa de reconstrução finalmente passou dessa parte. Teria sido realmente útil verificar e avisar em primeiro lugar que a configuração precisa ser ajustada. discourse-doctor verifica (muito simples, mas pode ser usado como um começo) os plugins na configuração, então isso pode ser usado como base. Provavelmente tarde demais agora, 3 semanas depois, enfim…
Mas isso não foi tudo, também encontramos erros em db:migrate. Tentei novamente 2 vezes, depois executei o discourse-doctor, que também executou a reconstrução e, estranhamente, foi bem-sucedido. Verifiquei o código dele e ele não faz absolutamente nada, e chama a reconstrução da mesma forma que fazemos. Daí parece que o db:migrate foi bem-sucedido na 3ª tentativa por algum motivo? Li no tópico que o grande número de plugins adicionados adiciona dependências, que podem conflitar/ser mais antigas do que o que foi usado anteriormente. Felizmente, não precisamos adicionar uma etapa manual de remoção de plugin, ajuste de dependência ou alteração de banco de dados, como outros parecem ter precisado. É de alguma forma esperado que executar o db:migrate várias vezes finalmente tenha sucesso? Só posso esperar que nada esteja quebrado…
Ele foi instalado anteriormente, apenas o omitimos da interface do usuário junto com o restante dos plugins agrupados de antes. Nossa interface do usuário foi aprimorada para exibir corretamente tudo o que existe. (Tínhamos uma série de omissões, incluindo o Chat, que estava oculto via CSS)
Já observei um aumento na velocidade da equipe de desenvolvimento interna no curtíssimo tempo em que isso está em vigor. Isso está levando a um produto mais estável, algo que me deixa muito feliz.
Não há planos de voltar atrás. Você precisa se ajustar ao novo mundo.
IMO, se algo quebrar porque um plugin não está instalado, então isso em si é um bug. O Core não deve depender de plugins. Os próprios plugins devem listar claramente seus requisitos em suas respectivas páginas.
Mas sim, isso tornará a versão auto-hospedada ainda menos estável daqui para frente, pois serão os auto-hospedadores tropeçando nesses problemas. Entre isso e o tópico dividido, eu realmente não tenho a impressão de que a estabilidade dos auto-hospedadores seja uma alta prioridade para a equipe.
Não tínhamos pensado nisso com antecedência, então algumas aprovações podem ter se perdido. Mas conseguimos transferir uma boa parte delas dos projetos de plugin no Crowdin para o core. Faremos melhor da próxima vez, pois agora temos as ferramentas para transferir aprovações entre projetos.
Não, não verificamos com antecedência, mas eu verifiquei depois. Nenhum dos plugins tinha comentários sem resposta no Crowdin. Temos uma ferramenta interna que armazena todos os comentários postados em nossos plugins do Crowdin. Poderíamos até usá-la para postar novamente comentários ausentes no Crowdin, por exemplo, quando o Crowdin exclui comentários porque a string de origem foi atualizada. Simplesmente não tem sido uma prioridade implementar isso.
Concordo. Talvez uma opção para listar plugins principais habilitados instalados. Em vez de apenas mostrar todos os plugins. Opções de filtragem adicionais definitivamente melhores.
Concordo com o sentimento. Na minha opinião, a verdadeira desconexão é mantê-los listados como plugins.
Uma vez mesclado, deve ser movido para algo com marca como “Recursos Principais”, pois os plugins são vistos como componentes opcionais que podem ser instalados. Em vez de parte do programa principal. Portanto, é um equívoco, na minha opinião, mantê-los listados como plugins quando a intenção não é desinstalá-los.
Semelhante aos TCs que foram mesclados no núcleo, como “bolhas pessoais”, não está listado em Componentes de Tema. Concedido, nesse caso específico, você não pode desativar o antigo TC. Se você quisesse voltar ao que era antes, precisaria criar um TC para desfazer as alterações
Isso evitaria a lista inicial massiva em Plugins Instalados.
Concordo totalmente com opções de filtragem adicionais. Para também ter uma para plugins desativados.
No entanto, após mais reflexão e leitura de mais posts. Se os plugins forem mesclados com o núcleo. Eles realmente talvez não devam mais ser chamados de plugins e não listados em Plugins. Mas talvez algo como Recursos Principais ou Recursos Opcionais. Já que estes não são mais realmente para serem desinstalados.
Não há razão para que um software de fórum devidamente projetado exija código de publicidade para funcionar.
Se o Discourse decidir incorporar anti-recursos, a única coisa que forçará as pessoas a fazer é criar um fork do Discourse ou migrar para outra coisa. Aqueles de nós que não gostam de big tech / coisas de anúncios sentem isso muito fortemente. O Discourse NÃO nos forçará, não importa o quanto seja pressionado. (O Ubuntu tentou isso conosco e agora meu repositório com mais estrelas é algo que remove os anúncios ;))
Não tenho certeza se entendi. Se por código de publicidade você quer dizer plugins que são mesclados ao produto principal em vez de permanecerem como add-ons/instalações opcionais. Se voltarmos, você encontrará uma variedade de “código de publicidade” que foi mesclado ao núcleo.
Posso ver da perspectiva da equipe de desenvolvimento que muitos de seus plugins podem ter começado como plugins para permitir testes mais flexíveis antes de serem integrados ao programa principal.
Posso apreciar que, como em qualquer software, muitas vezes há recursos que as pessoas podem não usar e optam por desativá-los e encontrar maneiras de desinstalar recursos.
Embora eu admita que há muitos plugins recentes mesclados que provavelmente não usaria. Mas ter um simples desativar e filtrá-los é algo bom para todos.
Entendo que, em parte, como declarado pela equipe, a intenção é facilitar as coisas com add-ons para auto-hospedagem.
Agora, na minha opinião, a interface de administração deveria ser mais personalizável como já foi. Isso também pode ajudar as pessoas que migram de outra plataforma, sendo capaz de carregar um administrador lá que tenha um layout semelhante ao da plataforma de onde vêm. Muito parecido com o que o Linux faz, imitando outros sistemas operacionais. Mas esse é outro tópico.
Posso apreciar a sensação de que o Discourse pode estar começando a se encaminhar para o bloatware. Os Reatores demonstraram o quão mais enxuto o Windows NT poderia ser.
