After upgrading to 3.1.1 from 2.8.x all my old template using %{base_url}%{url} to include a link to the a topic are now highlighted as invalid, the GUi saying The following interpolation key is invalid: base_url
But it is actually valid, because if I remove it and leave only %{url} then the link is broken (only includes the path, without the domain) and if I include it then the link is valid and in full.
This may be a change from older versions of Discourse, but I don’t think it’s a bug. Finding the allowed interpolation keys for email templates has always been tricky. We’ve got a topic now that explains what keys can be used: Interpolation Keys for Customizing Text and Email Templates. The allowed keys are listed here: discourse/app/models/translation_override.rb at main · discourse/discourse · GitHub.
{base_url} is not in that list.
Since you already know your site’s base URL, I’m not sure the key is needed. Instead of %{base_url}%{url}, just use your site’s URL. For example https://forum.example.com%{url}
But it does work, i.e. %{base_url} is expanded just fine, so it’s not invalid (it’s just the GUI that complains). Moreover, one cannot create a fully working link without it (unless they hardcode the full base URL, which is a no no)
The purpose of placeholders in general is to make robust software, which includes avoiding hard coding things. If I change the domain name, host name, or path to my Discourse installation (any element of base_url) then I’d have to edit all the templates where I hardcoded it. That’s bad coding practice.
Since I know Discourse development otherwise follows very healthy and robust coding practices, I can only assume it was an oversight/bug to (1) remove base_url when validating the template but (2) actually still interpret if it’s present, and (3) not offer an alternative to build a fully working url without resorting to bad coding practices…
Also, this would be a big backwards incompatible change for which I see no actual benefit, but does cause a lot of manual work for users … more of a reason to assume it’s a bug/oversight.
(I’ve also seen other bugs introduced in 3.x related to text templates, so even more of a reason to assume it was an oversight)
When I test this, I can’t get %{base_url} to save, so it isn’t getting used.
Maybe it’s an oversight. I agree that it could break existing email templates from older sites. I’ll move this back to the bug category and give the team a chance to decide what to do about it.
As I was mentioned initially, I’m talking about existing custom templates mislabeled as invalid after upgrading to 3.x, i.e. templates that were edited under 2.x and still exist after upgrade containing %{base_url}. Removing that placeholder makes it impossible to create full URLs without resorting to hard coding URLs. Not removing it makes it obvious that it is still expanded just fine under 3.1.1. I re-read the first post and I don’t find it unclear.
You could probably test it yourself by editing the database directly (or possibly also in a Rails console if the code doesn’t run the same validation).
I figured that out eventually. I’m not going to test it myself, but I’m sure you are correct.
This does sound like a bug. Maybe what’s supposed to happen is that %{url} is supposed to include the host name. In an endo template a url without that host name is pretty useless (unless there is some html way of changing the relative base globally?)
The team is at a conference this week, so it’ll be a bit before they can weigh in on this one.
I wouldn’t think that would be good practice, because then there’s no way to refer to the website root. %{base_url} plays an important role for a reason, to allow building urls. In general, templating systems for urls offer 3 placeholders: base, path, full_url, with the latter offered only for convenience (it’s the concatenation of the first two).
@pfaffman This is still not fixed even in 3.2.1. Nothing changed since my initial report. Could this be bumped up to get fixed, please? In short, pretty much EVERY template should allow %{base_url} given that %{url} only includes the path after the base url.
At the very least don’t prevent the user from using it (despite it not showing in the list of available keys).
Hey @nordize, no one who has replied here is someone who has any power over fixing bugs.
Right, what would you suggest in that case? I don’t know who to ping or if anything else can be done to push it to relevant people’s attention
Just to keep you in the loop, an engineer has been assigned to look into this. 
Can anyone help with the rails object name or rails console command to force %{base_url} in a template that I know for a fact accepts it and expands it (it’s just the GUI that says it’s invalid)?
Hello, @nordize!
Could you please provide some more info. like a screenshot and the key of the template you’re trying to update. I have no problem using base_url on my instance, but the issue might be related to a particular template.
You can see here for an example where it should exist: Help with Rails console to edit text template
There are plenty of others too (most email templates, for example).
Every single email template (if not every text template!) should allow %{base_url} since that’s the root website that one should be able to reference from anywhere. I don’t understand the decision to remove it selectively from some templates … unless it was somehow an oversight
Thanks. I’ll have a look.
I’m almost certain this isn’t intentional.