### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Avril 16, 2025, 2:55 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/2 "2025-04-16T14:55:15Z")
J’ai créé une PR :
>
>
> In digest.html.erb there are hooks for custom html, but they don't allow HTML.
> …
> \<%= digest\_custom\_html("above\_popular\_topics").html\_safe %\>
>
> Also, above\_popular\_topics was below the popular topics.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Avril 16, 2025, 5:57 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/3 "2025-04-16T17:57:29Z")
J’ai décidé que `digest_custom_html` ne produisant pas de HTML analysable est un bug, je le donc reclassifie.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Avril 18, 2025, 5:21 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/4 "2025-04-18T17:21:22Z")
@martin, désolé de te pointer du doigt, mais tu es la dernière personne à avoir touché à [digest.html.erb](https://github.com/discourse/discourse/blob/e47b0996ed3f8064f2e0abd54678c8110bd5a6da/app/views/user_notifications/digest.html.erb) (il y a deux ans). Pourrais-tu jeter un œil à cette PR ?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Avril 23, 2025, 3:33 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/5 "2025-04-23T15:33:12Z")
Ce plugin a été déployé et je l’oublierai probablement très bientôt, donc si quelqu’un veut utiliser ces champs `digest_custom_html` comme prévu, vous pouvez ajouter du code comme celui-ci à votre `app.yml` pour patcher la source. J’étais trop paresseux pour créer une regex qui les remplace toutes, et j’ai plutôt fait celle que j’utilisais. Modifiez selon vos besoins.
J’ai créé un modèle dans le plugin qui peut ensuite être inclus dans le `app.yml`. Cela le rend un peu plus facile que de s’embêter avec un bloc entier de yaml.
```plaintext
hooks:
after_code:
- replace:
filename: "/var/www/discourse/app/views/user_notifications/digest.html.erb"
from: 'digest_custom_html("above_footer") '
to: 'digest_custom_html("above_footer").html_safe '
```
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [Avril 23, 2025, 6:11 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/6 "2025-04-23T18:11:00Z")
Est-ce que ce serait pertinent d’avoir une étiquette pour aider à avertir l’équipe d’ouvrir des PR (Pull Requests) ?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Avril 28, 2025, 4:40 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/7 "2025-04-28T16:40:16Z")
Salut @david. Je vais essayer une dernière fois pour voir si quelqu’un est intéressé par cette PR. Comme décrit ci-dessus ; le code ne fonctionne clairement pas comme prévu, mais personne ne s’en est jamais soucié. J’ai trouvé une solution de contournement et déployé le code avec une correction pour patcher le template au déploiement, mais ce n’est pas une solution élégante.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [Avril 28, 2025, 5:49 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/8 "2025-04-28T17:49:36Z")
> [@pfaffman](#):
>
> ```plaintext
> module ::UserNotificationsHelperOverride
> def digest_custom_html(position_key)
>
> ```
Pourriez-vous ajouter `.html_safe` au résultat de votre remplacement de méthode ? Je ne pense pas qu’il y ait de raison qu’il doive être dans le modèle erb ?
L’objectif général, à la fois dans Rails et dans Ember, est de placer la mention « cette chaîne est html safe » aussi près que possible du point d’auteur/génération, afin qu’il soit très clair pour les développeurs qu’ils doivent s’assurer que le HTML est effectivement sûr (c’est-à-dire que toute entrée utilisateur est échappée)
> [@pfaffman](#):
>
> si quelqu’un veut utiliser ces champs `digest_custom_html` comme prévu
Ce que vous faites est acceptable (tant qu’il est testé), mais ce n’est pas l’utilisation « prévue » pour ces méthodes. S’il s’agissait d’une API de plugin intentionnelle, elle se trouverait dans plugin/instance.rb avec les autres.
L’utilisation prévue de cette méthode est de mettre du markdown dans la clé de traduction correspondante :
>
(Notez également le `html_safe` ici - c’est la même technique que vous devriez utiliser dans n’importe quel remplacement)
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Avril 28, 2025, 8:43 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/9 "2025-04-28T20:43:21Z")
> [@david](#):
>
> Pourriez-vous ajouter `.html_safe` au résultat de votre remplacement de méthode ?
O.M.G. Apparemment . . . Je peux!!! Il ne me serait jamais venu à l’esprit que je pourrais le mettre là et pas tout en haut du modèle où (dans ma tête, du moins) il est rendu.
Je vois et comprends maintenant que `digest_custom` et qu’il appelle `.html_safe`, joliment comme il faut, dans un code que j’ai regardé et essayé de comprendre, mais c’est déroutant (pour moi) qu’il utilise cette syntaxe funky sans parenthèses. (Ou peut-être que je ne l’aurais jamais vu).
> [@david](#):
>
> mais ce n’est pas l’utilisation « prévue » pour ces méthodes. Si c’était une API de plugin intentionnelle, elle serait dans plugin/instance.rb avec les autres.
Eh bien, je vois les valeurs dans les locales, mais comparé à la surcharge du modèle comme je le faisais auparavant, c’est une solution beaucoup moins risquée.
Merci infiniment de m’avoir mis sur la bonne voie !
Voici une autre chose que je fais et qui me semble stupide. Mon `digest_custom_html` a besoin de l’utilisateur pour lequel il est rendu, donc ce que je fais, c’est de remplacer `digest` pour définir `@user` afin que mon `digets_custom_html` puisse avoir accès à l’utilisateur pour lequel le digest est destiné. Y a-t-il un moyen super simple d’éviter cela ?
```plaintext
after_initialize do
# Code qui doit s'exécuter après le démarrage complet de Rails
# require_relative \"lib/discourse_add_jobs_to_digest/user_notifications_helper_override\"
require_relative \"lib/discourse_add_jobs_to_digest/engine\"
require_relative \"lib/discourse_add_jobs_to_digest/job_api\"
require_dependency \"user_notifications\"
module ::UserNotificationsHelperOverride
def digest_custom_html(position_key)
if position_key == \"above_footer\"
DiscourseAddJobsToDigest::JobApi.get_jobs_html(@user).html_safe
else
super
end
end
end
UserNotificationsHelper.prepend(::UserNotificationsHelperOverride)
module ::UserNotificationsOverride
def digest(user, opts = {})
@user = user
super
end
end
UserNotifications.prepend(::UserNotificationsOverride)
end
```
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [Avril 29, 2025, 9:10 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/10 "2025-04-29T09:10:10Z")
Je ne vois rien d’autre dans le template/les méthodes qui utilise une variable `user`, donc oui, ce que vous avez fait est probablement la meilleure façon de procéder.
Cependant, ce type de substitutions ne peut pas être « pris en charge » et peut casser à tout moment. Assurez-vous d’avoir des tests pour détecter cela lorsqu’il se produira éventuellement.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Avril 29, 2025, 2:38 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/11 "2025-04-29T14:38:50Z")
> [@david](#):
>
> Je ne vois rien d’autre dans le modèle/les méthodes qui utilise une variable `user`, donc oui, ce que vous avez fait est probablement la meilleure façon de procéder.
Merci pour la confirmation ! J’apprécie votre temps.
> [@david](#):
>
> ces types de substitutions ne peuvent pas être « pris en charge » et peuvent casser à tout moment.
Compris. C’est toujours bien mieux que de remplacer tout le modèle, ce qui était ma solution précédente pour un plugin similaire.
Et oui, il devrait y avoir des tests. 😉
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Mai 29, 2025, 2:39 UTC](https://meta.discourse.org/t/fixing-digest-custom-html-to-be-treated-as-html-was-overriding-digest-html-erb/361988/12 "2025-05-29T14:39:14Z")
Ce sujet a été automatiquement fermé 30 jours après la dernière réponse. Les nouvelles réponses ne sont plus autorisées.