Após a atualização para 3.1.1 de 2.8.x, todos os meus templates antigos que usam %{base_url}%{url} para incluir um link para um tópico agora estão sendo destacados como inválidos, a GUI dizendo A seguinte chave de interpolação é inválida: base_url
Mas na verdade é válido, porque se eu removê-lo e deixar apenas %{url}, o link fica quebrado (inclui apenas o caminho, sem o domínio) e se eu incluí-lo, o link é válido e completo.
Esta pode ser uma alteração em relação a versões mais antigas do Discourse, mas não acho que seja um bug. Encontrar as chaves de interpolação permitidas para modelos de e-mail sempre foi complicado. Agora temos um tópico que explica quais chaves podem ser usadas: Interpolation Keys for Customizing Text and System Email Templates. As chaves permitidas estão listadas aqui: discourse/app/models/translation_override.rb at main · discourse/discourse · GitHub.
{base_url} não está nessa lista.
Como você já sabe a URL base do seu site, não tenho certeza se a chave é necessária. Em vez de %{base_url}%{url}, use apenas a URL do seu site. Por exemplo, https://forum.example.com%{url}
Mas funciona, ou seja, %{base_url} é expandido corretamente, então não é inválido (é apenas a interface gráfica que reclama). Além disso, não se pode criar um link totalmente funcional sem ele (a menos que codifique a URL base completa, o que não é bom).
O propósito dos placeholders em geral é tornar o software robusto, o que inclui evitar codificar coisas. Se eu mudar o nome de domínio, nome do host ou caminho da minha instalação do Discourse (qualquer elemento de base_url), terei que editar todos os templates onde o codifiquei. Isso é uma má prática de codificação.
Como sei que o desenvolvimento do Discourse, de outra forma, segue práticas de codificação muito saudáveis e robustas, só posso presumir que foi uma falha/bug para (1) remover base_url ao validar o template, mas (2) ainda interpretar se ele está presente, e (3) não oferecer uma alternativa para construir uma URL totalmente funcional sem recorrer a más práticas de codificação…
Além disso, esta seria uma grande alteração incompatível com versões anteriores para a qual não vejo nenhum benefício real, mas causa muito trabalho manual para os usuários… mais um motivo para presumir que é um bug/falha.
(Também vi outros bugs introduzidos na versão 3.x relacionados a templates de texto, então ainda mais um motivo para presumir que foi uma falha)
Quando testo isso, não consigo salvar %{base_url}, então ele não está sendo usado.
Talvez seja uma falha. Concordo que isso pode quebrar modelos de e-mail existentes de sites mais antigos. Vou mover isso de volta para a categoria Bug e dar à equipe a chance de decidir o que fazer a respeito.
Como fui mencionado inicialmente, estou falando de modelos personalizados existentes rotulados incorretamente como inválidos após a atualização para a versão 3.x, ou seja, modelos que foram editados na versão 2.x e ainda existem após a atualização contendo %{base_url}. Remover esse placeholder impossibilita a criação de URLs completas sem recorrer à codificação rígida de URLs. Não removê-lo deixa óbvio que ele ainda é expandido perfeitamente na versão 3.1.1. Eu reli o primeiro post e não o acho pouco claro.
Você provavelmente poderia testar isso você mesmo editando o banco de dados diretamente (ou possivelmente também em um console Rails se o código não executar a mesma validação).
Eu descobri isso eventualmente. Não vou testar por mim mesmo, mas tenho certeza de que você está correto.
Isso realmente parece um bug. Talvez o que deveria acontecer é que %{url} deveria incluir o nome do host. Em um template endo, uma URL sem esse nome de host é bastante inútil (a menos que haja alguma forma de HTML de alterar a base relativa globalmente?)\n\nA equipe está em uma conferência esta semana, então levará um tempo até que eles possam opinar sobre isso.
Eu não acharia que essa seria uma boa prática, porque então não haveria como se referir à raiz do site. %{base_url} desempenha um papel importante por um motivo, para permitir a construção de URLs. Em geral, sistemas de template para URLs oferecem 3 placeholders: base, path, full_url, com este último oferecido apenas por conveniência (é a concatenação dos dois primeiros).
@pfaffman Isso ainda não foi corrigido nem na versão 3.2.1. Nada mudou desde o meu relatório inicial. Poderia isso ser priorizado para correção, por favor? Em resumo, praticamente TODO template deveria permitir %{base_url}, dado que %{url} inclui apenas o caminho após a base url.
No mínimo, não impeça o usuário de usá-lo (apesar de não aparecer na lista de chaves disponíveis).
Olá @nordize, ninguém que respondeu aqui é alguém que tenha poder para corrigir bugs.
Certo, o que você sugeriria nesse caso? Não sei a quem contatar ou se algo mais pode ser feito para chamar a atenção das pessoas relevantes.
Apenas para mantê-lo informado, um engenheiro foi designado para investigar isso. 
Alguém pode ajudar com o nome do objeto do Rails ou comando do console do Rails para forçar %{base_url} em um template que eu sei que aceita e expande (é apenas a GUI que diz que é inválido)?
Olá, @nordize!
Você poderia fornecer mais informações, como uma captura de tela e a chave do template que você está tentando atualizar. Não tenho problemas em usar base_url na minha instância, mas o problema pode estar relacionado a um template específico.
Você pode ver aqui um exemplo onde deveria existir: Help with Rails console to edit text template
Existem muitos outros também (a maioria dos modelos de e-mail, por exemplo).
Cada modelo de e-mail (se não todos os modelos de texto!) deveria permitir %{base_url}, já que essa é a raiz do site à qual se deve poder referenciar de qualquer lugar. Não entendo a decisão de removê-lo seletivamente de alguns modelos… a menos que tenha sido uma falha de supervisão.
Obrigado. Vou dar uma olhada.
Tenho quase certeza de que isso não é intencional.