Hmm, dans cet exemple, et dans le code source complet du courriel que vous m’avez envoyé (merci !), l’attribut moz-do-not-send ne devrait pas affecter l’affichage des balises \u003cimg\u003e ou \u003ca\u003e dans lesquelles cet attribut apparaît. Le mozfilter examine uniquement les valeurs de l’attribut class, et je ne vois pas immédiatement ailleurs où il pourrait être filtré.
Par conséquent, je ne parviens pas à comprendre pourquoi le contenu et le href du lien avec alias sont séparés, sauf si, pour une raison quelconque, l’importateur Discourse décide soudainement d’utiliser la partie texte/brut du courriel codé en Mime (qui sépare effectivement le texte et l’URL). Je ne sais pas pourquoi il ferait cela.
Dans votre configuration de test de Discourse, pouvez-vous essayer d’importer ou d’envoyer par courriel un courriel HTML de Thunderbird contenant à la fois un lien avec alias et, par exemple, une image intégrée ou tout autre élément qui permettra de l’identifier comme la partie HTML du courriel ?
Je pense toujours que cela pourrait être Discourse utilisant les autres parties MIME (dans ce cas, une partie text/plain suivie d’une partie image/… de l’e-mail pour générer sa version Markdown, bien que je ne sache pas pourquoi. Peut-être qu’un validateur HTML rejette la partie text/html à cause d’attributs strictement non validants comme moz-do-not-send !?
Pourrais-tu faire un test de plus avec le même message (du texte avec une image au milieu, mais rends aussi certaines parties du texte en gras, même un seul mot, pas tout). Je pense que cela permettra de déterminer si la partie texte provient d’un bloc text/plain ou text/html.
Et désolé de demander, mais juste pour être sûr, as-tu bien défini incoming_email_prefer_html à true (coché) ?!
Merci @Flominator. Je vois que le texte en gras est devenu italique, donc ce n’est certainement pas du HTML direct, mais il semble tout de même capter l’emphase d’une manière ou d’une autre. Je me demande si la partie text/plain de l’e-mail reçoit une sorte de balisage ou de mise en forme ajoutée — pourriez-vous m’envoyer en MP le code source de l’e-mail comme la dernière fois ?
Bonjour @Flominator, merci pour l’email brut. En examinant la partie alternative text/plain de l’email, on constate effectivement que des astérisques entourent le texte qui est en gras dans la partie text/html. La plupart des moteurs de rendu Markdown (comme celui de Discourse) interprètent cela comme de l’italique. Voici le segment text/plain copié et collé seul :
Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben ist
Gruß
Flo
Ce qui ressemble exactement à votre capture d’écran.
Donc, ce que je pense se produire, c’est que le segment text/html est rejeté en tant que HTML invalide (probablement à cause du nom d’attribut non standard moz-do-not-send dans les balises a). Cela nécessitera un correctif pour modifier la façon dont le HTML valide est vérifié (peut-être simplement en supprimant ces attributs), et je suis moins confiant quant à la stabilité de cette approche sans qu’elle soit intégrée dans le code principal. Je m’en occuperai quand j’aurai un moment.
Cela signifie que le patch joint dans un commentaire précédent échouera (probablement pas de manière « spectaculaire » mais il pourrait alors nécessiter une reconstruction pour que les mises à niveau reprennent) lorsque vous mettrez à niveau pour inclure ce nouveau commit (probablement votre prochaine mise à niveau).
Si vous l’avez appliqué automatiquement (par exemple avec une cmdgit apply dans votre app.yml comme décrit ci-dessus), vous devriez le supprimer avant votre prochaine mise à niveau. En fait, une reconstruction pourrait être nécessaire car ce commit pourrait ne pas s’appliquer car l’endroit dans receiver.rb où il voudra appliquer le diff du commit a déjà été modifié par le patch.
Je vais 1) supprimer la cmdgit apply de app.yml, 2) reconstruire l’application, 3) mettre à jour (si ce n’est pas déjà fait lors de la reconstruction). Je vous dirai comment cela se passe…
[10 minutes plus tard…]
Finalement, j’ai fait ceci à la place car cela ne nécessite aucun temps d’arrêt pendant la reconstruction.
supprimer le git apply pour le patch de app.yml (il suffit de le faire avant votre prochaine reconstruction du conteneur d’application)
annuler le fichier patché avec :
i) launcher enter app
ii) (maintenant dans le conteneur d’application) cd /var/www/discourse git checkout ./lib/email/receiver.rb exit
mettre à jour discourse en utilisant la mise à jour de l’administrateur web
