После обновления с версии 2.8.x до 3.1.1 все мои старые шаблоны, использующие %{base_url}%{url} для включения ссылки на тему, теперь помечаются как недопустимые: в интерфейсе отображается сообщение «Следующий ключ интерполяции недопустим: base_url».
Однако это действительно корректный ключ, потому что, если я удалю его и оставлю только %{url}, ссылка перестанет работать (будет содержать только путь без домена), а при его включении ссылка становится корректной и полной.
Это может быть изменением по сравнению со старыми версиями Discourse, но я не считаю это ошибкой. Поиск допустимых ключей интерполяции для шаблонов электронной почты всегда был сложным. Сейчас у нас есть тема, объясняющая, какие ключи можно использовать: Interpolation Keys for Customizing Text and System Email Templates. Список допустимых ключей доступен здесь: discourse/app/models/translation_override.rb at main · discourse/discourse · GitHub.
{base_url} отсутствует в этом списке.
Поскольку вы уже знаете базовый URL вашего сайта, я не уверен, что ключ необходим. Вместо %{base_url}%{url} просто используйте URL вашего сайта. Например: https://forum.example.com%{url}
Однако он работает, то есть %{base_url} успешно подставляется, поэтому это не является ошибкой (просто интерфейс выдает предупреждение). Более того, без него невозможно создать полностью рабочую ссылку (если только не прописать полный базовый URL вручную, что является плохой практикой).
Смысл использования плейсхолдеров в целом заключается в создании надежного программного обеспечения, что включает в себя избегание жесткого кодирования. Если я изменю доменное имя, имя хоста или путь к установке Discourse (любой элемент base_url), мне придется редактировать все шаблоны, где я прописал его вручную. Это плохая практика программирования.
Поскольку я знаю, что разработка Discourse в остальном следует очень здоровым и надежным принципам, могу предположить только, что это упущение/ошибка: (1) исключение base_url при валидации шаблона, но (2) фактическая его интерпретация при наличии, и (3) отсутствие альтернативы для построения полностью рабочего URL без прибегания к плохим практикам…
Кроме того, это было бы крупным обратно несовместимым изменением, от которого я не вижу никакой реальной пользы, но которое создает значительный объем ручной работы для пользователей… что еще больше подтверждает предположение об ошибке или упущении.
(Я также видел другие ошибки, введенные в версии 3.x, связанные с текстовыми шаблонами, что является еще одним аргументом в пользу того, что это было упущение).
Когда я тестирую это, мне не удаётся сохранить %{base_url}, поэтому он не используется.
Возможно, это упущение. Я согласен, что это может сломать существующие шаблоны писем со старых сайтов. Я верну это в категорию bug и дам команде возможность решить, что с этим делать.
Как я уже упоминал изначально, речь идёт о существующих пользовательских шаблонах, которые после обновления до версии 3.x ошибочно помечены как недействительные. То есть это шаблоны, отредактированные в версии 2.x и сохранившиеся после обновления, содержащие %{base_url}. Удаление этого плейсхолдера делает невозможным создание полных URL без использования жёстко заданных ссылок. Если же не удалять его, становится очевидно, что он по-прежнему корректно расширяется в версии 3.1.1. Я перечитал первый пост и не нахожу в нём неясностей.
Вы, вероятно, можете проверить это самостоятельно, отредактировав базу данных напрямую (или, возможно, также через консоль Rails, если код не выполняет ту же самую проверку).
В конце концов я это понял. Я не буду проверять это сам, но уверен, что вы правы.
Это действительно похоже на ошибку. Возможно, предполагалось, что %{url} должен включать имя хоста. В шаблоне endo URL без имени хоста практически бесполезен (если только нет какого-то способа глобально изменить относительную базу с помощью HTML?).
Команда на этой неделе находится на конференции, поэтому они смогут высказаться по этому вопросу немного позже.
Я бы не стал считать это хорошей практикой, так как в таком случае не будет возможности ссылаться на корень сайта. Переменная %{base_url} играет важную роль не просто так — она нужна для построения URL. В целом, системы шаблонов для URL предлагают три плейсхолдера: base, path и full_url, при этом последний предоставляется только для удобства (это конкатенация первых двух).
@pfaffman Это всё ещё не исправлено даже в версии 3.2.1. С момента моего первоначального сообщения ничего не изменилось. Не могли бы вы повысить приоритет этой задачи, чтобы она была исправлена, пожалуйста? Если кратко, практически ВСЕ шаблоны должны поддерживать %{base_url}, поскольку %{url} включает только путь после базового URL.
Как минимум, не запрещайте пользователям использовать его (несмотря на то, что он не отображается в списке доступных ключей).
Привет, @nordize, никто из тех, кто ответил здесь, не имеет полномочий для исправления ошибок.
Хорошо, что бы вы посоветовали в таком случае? Я не знаю, кого стоит уведомить или можно ли что-то ещё сделать, чтобы привлечь внимание нужных людей.
Чтобы держать вас в курсе, инженер назначен для изучения этого вопроса. 
Может кто-нибудь помочь с именем объекта rails или командой rails console, чтобы принудительно подставить %{base_url} в шаблоне, который, как я точно знаю, принимает его и расширяет (просто GUI говорит, что это недействительно)?
Привет, @nordize!
Не могли бы вы предоставить дополнительную информацию, например, скриншот и ключ шаблона, который вы пытаетесь обновить? У меня не возникает проблем с использованием base_url на моём экземпляре, но проблема может быть связана с конкретным шаблоном.
Вы можете посмотреть пример здесь, где это должно существовать: Help with Rails console to edit text template
Таких примеров множество (например, большинство шаблонов электронной почты).
Каждый шаблон электронной почты (если не каждый текстовый шаблон!) должен поддерживать %{base_url}, так как это корневой веб-сайт, на который можно ссылаться из любого места. Я не понимаю решения выборочно удалить его из некоторых шаблонов… если только это не было каким-то упущением.
Спасибо. Я посмотрю.
Я почти уверен, что это не было сделано намеренно.