Après la mise à niveau vers la version 3.1.1 depuis la version 2.8.x, tous mes anciens modèles utilisant %{base_url}%{url} pour inclure un lien vers un sujet sont maintenant signalés comme invalides, l’interface graphique indiquant La clé d'interpolation suivante est invalide : base_url
Mais c’est en fait valide, car si je le supprime et ne laisse que %{url}, le lien est brisé (il n’inclut que le chemin, sans le domaine) et si je l’inclus, le lien est valide et complet.
Ceci peut être un changement par rapport aux anciennes versions de Discourse, mais je ne pense pas que ce soit un bug. Trouver les clés d’interpolation autorisées pour les modèles d’e-mail a toujours été délicat. Nous avons maintenant un sujet qui explique quelles clés peuvent être utilisées : Interpolation Keys for Customizing Text and System Email Templates. Les clés autorisées sont listées ici : discourse/app/models/translation_override.rb at main · discourse/discourse · GitHub.
{base_url} ne figure pas dans cette liste.
Puisque vous connaissez déjà l’URL de base de votre site, je ne suis pas sûr que la clé soit nécessaire. Au lieu de %{base_url}%{url}, utilisez simplement l’URL de votre site. Par exemple https://forum.example.com%{url}
Mais cela fonctionne, c’est-à-dire que %{base_url} est correctement développé, donc ce n’est pas invalide (c’est juste l’interface graphique qui se plaint). De plus, on ne peut pas créer un lien entièrement fonctionnel sans cela (à moins de coder en dur l’URL de base complète, ce qui est à proscrire).
Le but des espaces réservés en général est de créer des logiciels robustes, ce qui inclut d’éviter de coder en dur les choses. Si je change le nom de domaine, le nom d’hôte ou le chemin de mon installation Discourse (n’importe quel élément de base_url), je devrai modifier tous les modèles où je l’ai codé en dur. C’est une mauvaise pratique de codage.
Puisque je sais que le développement de Discourse suit par ailleurs des pratiques de codage très saines et robustes, je ne peux que supposer qu’il s’agit d’un oubli/bug de (1) supprimer base_url lors de la validation du modèle mais (2) de l’interpréter réellement s’il est présent, et (3) de ne pas offrir d’alternative pour construire une URL entièrement fonctionnelle sans recourir à de mauvaises pratiques de codage…
De plus, ce serait un changement rétrocompatible majeur pour lequel je ne vois aucun avantage réel, mais qui cause beaucoup de travail manuel pour les utilisateurs… une raison de plus de supposer qu’il s’agit d’un bug/oubli.
(J’ai également vu d’autres bugs introduits dans la version 3.x liés aux modèles de texte, ce qui renforce la supposition qu’il s’agissait d’un oubli)
Lorsque je teste cela, je n’arrive pas à sauvegarder %{base_url}, donc il n’est pas utilisé.
C’est peut-être un oubli. Je suis d’accord que cela pourrait casser les modèles d’e-mails existants des anciens sites. Je vais déplacer cela dans la catégorie Bug et donner à l’équipe une chance de décider quoi en faire.
Comme je l’ai mentionné initialement, je parle de modèles personnalisés existants mal étiquetés comme invalides après la mise à niveau vers la version 3.x, c’est-à-dire des modèles qui ont été modifiés sous la version 2.x et qui existent toujours après la mise à niveau contenant %{base_url}. La suppression de cet espace réservé rend impossible la création d’URL complètes sans recourir à l’encodage en dur des URL. Ne pas le supprimer montre qu’il est toujours développé sans problème sous la version 3.1.1. J’ai relu le premier message et je ne le trouve pas peu clair.
Vous pourriez probablement le tester vous-même en modifiant directement la base de données (ou éventuellement aussi dans une console Rails si le code n’exécute pas la même validation).
J’ai fini par comprendre. Je ne vais pas le tester moi-même, mais je suis sûr que vous avez raison.
Cela ressemble effectivement à un bug. Ce qui est peut-être censé se produire, c’est que %{url} est censé inclure le nom d’hôte. Dans un modèle endo, une URL sans ce nom d’hôte est assez inutile (à moins qu’il n’y ait un moyen HTML de changer la base relative globalement ?)
L’équipe est en conférence cette semaine, il faudra donc un peu de temps avant qu’elle ne puisse se prononcer sur ce point.
Je ne penserais pas que ce soit une bonne pratique, car il n’y a alors aucun moyen de faire référence à la racine du site Web. %{base_url} joue un rôle important pour une raison, pour permettre la construction d’URL. En général, les systèmes de mise en modèle pour les URL offrent 3 espaces réservés : base, chemin, url_complète, ce dernier n’étant proposé que par commodité (c’est la concaténation des deux premiers).
@pfaffman Ce n’est toujours pas corrigé, même en 3.2.1. Rien n’a changé depuis mon rapport initial. Pourriez-vous s’il vous plaît faire remonter ce problème pour qu’il soit corrigé ? En bref, pratiquement TOUS les modèles devraient autoriser %{base_url} étant donné que %{url} n’inclut que le chemin après l’URL de base.
Au minimum, n’empêchez pas l’utilisateur de l’utiliser (même s’il n’apparaît pas dans la liste des clés disponibles).
Salut @nordize, personne qui a répondu ici n’a le pouvoir de corriger les bugs.
Dans ce cas, que suggéreriez-vous ? Je ne sais pas qui contacter ni si quelque chose d’autre peut être fait pour attirer l’attention des personnes concernées.
Pour information, un ingénieur a été affecté à ce problème. 
Quelqu’un peut-il m’aider avec le nom de l’objet rails ou la commande rails console pour forcer %{base_url} dans un modèle qui, je le sais avec certitude, l’accepte et le développe (c’est juste l’interface graphique qui dit qu’il est invalide) ?
Bonjour, @nordize !
Pourriez-vous fournir plus d’informations, comme une capture d’écran et la clé du modèle que vous essayez de mettre à jour ? Je n’ai aucun problème à utiliser base_url sur mon instance, mais le problème pourrait être lié à un modèle particulier.
Vous pouvez voir ici un exemple où il devrait exister : Help with Rails console to edit text template
Il y en a beaucoup d’autres aussi (la plupart des modèles d’e-mails, par exemple).
Chaque modèle d’e-mail (sinon chaque modèle de texte !) devrait autoriser %{base_url} car c’est la racine du site Web à laquelle on devrait pouvoir faire référence n’importe où. Je ne comprends pas la décision de le supprimer sélectivement de certains modèles… à moins que ce ne soit une négligence.
Merci. Je vais jeter un œil.
Je suis presque certain que ce n’est pas intentionnel.