Después de actualizar a la versión 3.1.1 desde la 2.8.x, todas mis plantillas antiguas que usan %{base_url}%{url} para incluir un enlace a un tema ahora se marcan como inválidas, la GUI dice La siguiente clave de interpolación no es válida: base_url
Pero en realidad es válida, porque si la elimino y solo dejo %{url}, el enlace se rompe (solo incluye la ruta, sin el dominio) y si la incluyo, el enlace es válido y completo.
Esto puede ser un cambio respecto a versiones anteriores de Discourse, pero no creo que sea un error. Encontrar las claves de interpolación permitidas para las plantillas de correo electrónico siempre ha sido complicado. Ahora tenemos un tema que explica qué claves se pueden usar: Interpolation Keys for Customizing Text and System Email Templates. Las claves permitidas se enumeran aquí: discourse/app/models/translation_override.rb at main · discourse/discourse · GitHub.
{base_url} no está en esa lista.
Dado que ya conoces la URL base de tu sitio, no estoy seguro de que la clave sea necesaria. En lugar de %{base_url}%{url}, simplemente usa la URL de tu sitio. Por ejemplo https://forum.example.com%{url}
Pero funciona, es decir, %{base_url} se expande bien, así que no es inválido (es solo la GUI la que se queja). Además, no se puede crear un enlace completamente funcional sin él (a menos que codifiques la URL base completa, lo cual no es bueno).
El propósito de los marcadores de posición en general es crear software robusto, lo que incluye evitar la codificación rígida de las cosas. Si cambio el nombre de dominio, el nombre de host o la ruta de mi instalación de Discourse (cualquier elemento de base_url), tendría que editar todas las plantillas donde lo codifiqué. Esa es una mala práctica de codificación.
Dado que sé que el desarrollo de Discourse sigue prácticas de codificación muy saludables y robustas, solo puedo asumir que fue una omisión/error (1) eliminar base_url al validar la plantilla pero (2) en realidad seguir interpretándola si está presente, y (3) no ofrecer una alternativa para construir una URL completamente funcional sin recurrir a malas prácticas de codificación…
Además, este sería un gran cambio incompatible con versiones anteriores para el cual no veo ningún beneficio real, pero que causa mucho trabajo manual para los usuarios… más una razón para asumir que es un error/omisión.
(También he visto otros errores introducidos en la versión 3.x relacionados con plantillas de texto, por lo que es aún más una razón para asumir que fue una omisión).
Cuando pruebo esto, no puedo hacer que %{base_url} se guarde, por lo que no se está utilizando.
Quizás sea una omisión. Estoy de acuerdo en que podría romper las plantillas de correo electrónico existentes de sitios más antiguos. Moveré esto de nuevo a la categoría Bug y le daré al equipo la oportunidad de decidir qué hacer al respecto.
Como mencioné inicialmente, estoy hablando de plantillas personalizadas existentes etiquetadas incorrectamente como inválidas después de actualizar a la versión 3.x, es decir, plantillas que se editaron en la versión 2.x y que todavía existen después de la actualización y contienen % {base_url}. Eliminar ese marcador de posición hace imposible crear URL completas sin recurrir a la codificación de URL. No eliminarlo hace obvio que todavía se expande bien en la versión 3.1.1. Volví a leer la primera publicación y no me parece poco clara.
Probablemente podrías probarlo tú mismo editando la base de datos directamente (o posiblemente también en una consola de Rails si el código no ejecuta la misma validación).
Eventualmente me di cuenta. No lo probaré yo mismo, pero estoy seguro de que tienes razón.
Esto sí suena a un error. Quizás lo que se supone que debe suceder es que %{url} deba incluir el nombre del host. En una plantilla endo, una URL sin ese nombre de host es bastante inútil (¿a menos que haya alguna forma HTML de cambiar la base relativa globalmente?).
El equipo está en una conferencia esta semana, así que pasará un tiempo antes de que puedan opinar sobre esto.
No creo que eso sea una buena práctica, porque entonces no hay forma de referirse a la raíz del sitio web. %{base_url} juega un papel importante por una razón, para permitir la construcción de URL. En general, los sistemas de plantillas para URL ofrecen 3 marcadores de posición: base, ruta, url_completa, y este último se ofrece solo por conveniencia (es la concatenación de los dos primeros).
@pfaffman Esto todavía no está arreglado ni en la versión 3.2.1. Nada ha cambiado desde mi informe inicial. ¿Podría esto ser escalado para ser arreglado, por favor? En resumen, prácticamente CUALQUIER plantilla debería permitir %{base_url} dado que %{url} solo incluye la ruta después de la url base.
Como mínimo, no impidas que el usuario lo use (a pesar de que no aparezca en la lista de claves disponibles).
Oye @nordize, nadie que ha respondido aquí es alguien que tenga poder para corregir errores.
Bien, ¿qué sugerirías en ese caso? No sé a quién contactar o si se puede hacer algo más para llamar la atención de las personas relevantes.
Para mantenerte informado, se ha asignado un ingeniero para investigar esto. 
¿Alguien puede ayudar con el nombre del objeto de Rails o el comando de la consola de Rails para forzar %{base_url} en una plantilla que sé que lo acepta y lo expande (es solo la GUI la que dice que no es válido)?
Hola, @nordize.
¿Podrías proporcionar más información, como una captura de pantalla y la clave de la plantilla que intentas actualizar? No tengo problemas para usar base_url en mi instancia, pero el problema podría estar relacionado con una plantilla en particular.
Aquí puedes ver un ejemplo de dónde debería existir: Help with Rails console to edit text template
Hay muchos otros también (la mayoría de las plantillas de correo electrónico, por ejemplo).
Cada plantilla de correo electrónico (¡si no cada plantilla de texto!) debería permitir %{base_url} ya que esa es la raíz del sitio web a la que uno debería poder hacer referencia desde cualquier lugar. No entiendo la decisión de eliminarlo selectivamente de algunas plantillas… a menos que haya sido un descuido.
Gracias. Le echaré un vistazo.
Estoy casi seguro de que esto no es intencional.