Na versão mais recente do Discourse, o uso de arquivos .hbs em temas e plugins está obsoleto. O suporte para este formato de arquivo será removido após o próximo lançamento do ESR.
Os templates Handlebars devem ser substituídos pelo formato .gjs mais moderno, que oferece uma experiência de desenvolvimento muito melhor e possibilitará grandes melhorias de desempenho nas futuras versões do Discourse.
Para casos simples, compartilhe seu código com https://ask.discourse.com/ e peça para reescrevê-lo no formato .gjs.
Para casos mais complexos, as atualizações podem ser automatizadas usando este codemod:
É muito provável que descontinuemos o suporte na versão 2026.8.0-latest. Mas é possível que seja mais tarde, dependendo de dados reais e feedback da comunidade.
Obrigado! Espero que a maioria das pessoas já tenha cuidado disso, já que foram descontinuados com um banner de administrador por quase um ano. Apenas por precaução, adicionei esta nota:
Para minha parte, eu tentei com meu pequeno plugin pessoal e consegui com a ajuda do ask Discourse, que mesclou meus arquivos hbs e js em um único arquivo gjs.
Eu recomendo fortemente o uso do ask Discourse para resolver este problema para aqueles como eu que têm dificuldades de desenvolvimento
Não faço a menor ideia do que é um arquivo .gjs, nem tenho tempo para aprender sobre eles e reescrever vários plugins. Isso é ridículo.
Qual é o ponto de ter uma API de plugins se ela é tão frágil quanto a do Discourse? Manter plugins para esse software de fórum tem sido apenas problemas.
Se você não tem orçamento ou capacidade para gerenciar customizações, eu o aconselharia a simplificar sua configuração.
Na minha opinião, é o preço (razoável) que se paga por permanecer em uma plataforma de ponta e de alta velocidade que continua a inovar, melhorar o desempenho, lançar patches de segurança frequentes e acompanhar os padrões em evolução.
A equipe do Discourse parece se esforçar bastante para garantir que existam mensagens de aviso de descontinuação bem antes da perda de funcionalidade.
Você preferiria ficar preso em uma plataforma insegura com menos recursos?
Pense no valor que você obtém do núcleo bem mantido que você pode baixar gratuitamente?
Mas com a ajuda do ask.discourse.com, ele leu meu código e converteu meu arquivo hbs e js para .gjs, então não hesite se o primeiro método não funcionar.
Não estou mais fazendo nenhum trabalho adicional em nenhum dos meus plugins do Discourse. Simplesmente não vale a pena.
Considerando que outras pessoas estão usando dois deles, qual é o processo para excluí-los sem causar problemas a outras pessoas?
Já tive o suficiente deles ficarem quebrados, geralmente por motivos completamente absurdos, a cada poucos meses, e da quantidade de tempo e esforço que leva apenas para manter meu fórum funcionando.
Não quero estar “na vanguarda”. Quero apenas um fórum web funcional e estável.
“Não atualizar” também não é uma opção, já que precisamos de atualizações de segurança. É ridículo que alguém tenha sugerido isso da última vez que reclamei.
A equipe do Discourse realmente precisa se importar mais com a compatibilidade e em não quebrar fóruns e códigos existentes. Eles nem parecem pensar nisso. Eles fazem mudanças que quebram funcionalidades apenas para arrumar um pouco as coisas do lado deles. Não é assim que se gerencia uma plataforma e uma API usadas por outras pessoas, e não quero fazer mais parte disso.
Se você realmente deseja seguir por esse caminho, recomendo adicionar uma nota ao README e ao tópico Meta, marcando-o como broken e, em seguida, arquivando o repositório do GitHub. Dessa forma, ele ainda estará disponível para que outros o façam um fork (desde que a licença seja suficientemente permissiva).
Nós nos importamos absolutamente com compatibilidade e em manter tudo funcionando. É por isso que temos longos períodos de depreciação com caminhos de atualização totalmente automatizados.
Estamos sempre tentando encontrar o equilíbrio entre personalização e estabilidade — temas e plugins do Discourse são tão poderosos porque damos a eles acesso direto às APIs subjacentes do navegador/framework. Esse imenso poder vem com certa responsabilidade de se manter atualizado em relação às mudanças subjacentes.
De fato — manter-se atualizado é importante. Nos últimos meses, investimos pesadamente em nosso pipeline de lançamento para tornar as coisas muito melhores para usuários ESR (anteriormente ‘estáveis’). Mais detalhes aqui. Você ainda precisa atualizar, mas há muito mais flexibilidade quanto ao momento e à urgência.
Quanto a essa depreciação específica, a solução é totalmente automatizada. Se puder nos informar os nomes dos plugins, ficaremos felizes em executar o codemod para você e abrir um PR. Já fizemos isso para todos os mais de 600 temas/plugins que mantemos, então é um processo bem afinado neste ponto.
Entendo que não é fácil se alguém voltar após alguns meses e descobrir que muitas coisas mudaram. Acompanhar as mudanças pode não ser fácil, mas, na minha opinião, é um preço a pagar por um software de fórum de ponta com uma API extensa.
Então, por que continuam fazendo mudanças motivadas apenas por arrumar pequenos resquícios do seu lado, às custas da compatibilidade?
Esse resíduo legado faz parte do preço de manter uma plataforma ou API. Não causa problemas reais. Mas vocês insistem em alterar/remover isso, fazendo com que outras pessoas tenham trabalho extra e precisem realizar testes como consequência.
Os ESRs duram apenas 9 meses, o que dificilmente pode ser considerado suporte estendido.
E usá-los significa apenas que você terá que lidar com todas as mudanças que quebram compatibilidade de uma vez só, com uma lista muito maior de commits para pesquisar se estiver tentando entender por que um problema ocorreu.
O ESR, como está hoje, vai piorar esse problema, não melhorar.
A única solução é realmente se importar com a API e mantê-la. Faça mudanças que quebram compatibilidade apenas como último recurso, não para “pequenos ajustes agradáveis”. E não descarte um framework inteiro que as pessoas estão usando só porque você sente vontade de usar outro, ou por qualquer outro motivo.
O processo aqui é manter a produção em ESR e o staging nas versões mensais ou nas versões com testes aprovados.
Se você atualizar o staging todos os dias/semanas/meses — você pode até automatizar isso — será possível atualizar iterativamente seus plugins e temas e mantê-los em estado funcional.
O fato de você manter a produção em ESR oferece um prazo mínimo de três meses para corrigir problemas.
Você parece incapaz de compreender o conceito de que uma API publicada não deve ser um alvo em constante movimento.
Imagine se a Microsoft obrigasse todos os desenvolvedores do Windows a alterar seu código a cada 6 meses. É impensável. Você pode pegar um código escrito para o Windows 95 há 30 anos e compilá-lo e executá-lo em uma máquina moderna hoje, sem absolutamente nenhuma alteração.
Você não pode afirmar se preocupar com compatibilidade quando o código escrito conforme suas especificações deixará de funcionar inteiramente devido a decisões que você tomou.
O Windows controla toda a sua pilha tecnológica, enquanto o Discourse está construindo uma plataforma sobre um ecossistema vivo. O Ember, sozinho, quebrou a compatibilidade retroativa repetidamente em várias versões principais. E isso é até mesmo a norma no ecossistema de frontend, não a exceção.
Para mim, fica muito claro que o modelo correto aqui não é o do Windows, mas sim o que outras plataformas de API fazem: versionamento claro, avisos de descontinuação e uma janela de migração razoável.
