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: https://github.com/discourse/discourse/blob/main/app/models/translation_override.rb.
{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).