Hmmm, in that example, and in the full email source you messaged me (thank you!) the moz-do-not-send attribute should not affect the display of the <img> or <a> tags that that attribute appears in. The mozfilter is only looking at values in the class attribute, and I can’t immediately see anywhere else that it might get filtered.
As such I can’t work out why the link-with-alias’s content and href get separated out, unless for some reason the discourse importer is suddenly deciding to use the plain/text part of the Mime encoded email (which does have the text and URL separated). Why it would do that I don’t know.
In your test discourse setup can you try importing/emailing a thunderbird HTML email with both a link-with-alias and, say an embedded image or something else that will mark it out as the HTML part of the email?
I’m still thinking this might be discourse using the other mime parts (in this case a plain/text part followed by an image/… part of the email to create its markdown version, though why I don’t know. Perhaps an HTML validator is rejecting the text/html part because of strictly-non-validating attributes like moz-do-not-send!?
Could you do one more test, with the same post (some text with an image in the middle, but also make some (but not all) of the text bold, even just one work. I think that will determine if the text part is coming from a text/plain or text/html block.
And sorry to ask, but just to make sure, you have incoming_email_prefer_html set to true (checked)?!
Thanks @Flominator . I see that the emboldened text has become italicised, so it’s definitely not using the HTML directly, but it is picking up on the emphasis somehow. I wonder if the text/plain part of the email gets some kind of markup/down added – would you be able to PM me the email source like last time?
Hi @Flominator , thanks for the raw email. Looking at the text/plain alternative part of the email does indeed put asterisks around the text that’s in bold in the text/html part. Most markdown renderers (such as the one in discourse) interpret this as italicised. Here’s the text/plain segment copied and pasted on its own:
Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben ist
Gruß
Flo
which looks identical to your screenshot.
So what I think is happening is that the text/html segment is being rejected as invalid HTML (probably down to the non-standard moz-do-not-send attribute name in the a tags). This will require the patch to change how valid HTML is checked (possibly just removing those attributes) and I’m less confident how stable that will be without it going into the core code. I’ll have a look when I get some time.
هذا يعني أن التصحيح المرفق في تعليق أعلاه سيفشل (ربما ليس “بشكل مذهل” ولكنه قد يتطلب إعادة بناء للحصول على ترقيات تعمل مرة أخرى) عند الترقية لتضمين هذا الالتزام الجديد (ربما ترقيتك التالية).
إذا كان يتم تطبيقه تلقائيًا (على سبيل المثال، باستخدام أمر git apply في ملف app.yml الخاص بك كما هو موضح أعلاه)، فيجب عليك إزالته قبل ترقيتك التالية. في الواقع، قد يكون من المناسب إجراء إعادة بناء لأن هذا الالتزام قد يفشل في التطبيق نظرًا لأن المكان في ملف receiver.rb الذي يريد تطبيق فرق الالتزام فيه قد تم تغييره بالفعل بواسطة التصحيح.
سأقوم بـ 1) إزالة أمر git apply من ملف app.yml، و 2) إعادة بناء التطبيق، و 3) التحديث (إذا لم يحدث ذلك بالفعل في إعادة البناء). سأخبركم كيف سارت الأمور…
[بعد 10 دقائق…]
في النهاية، قمت بما يلي بدلاً من ذلك لأنه لا يتطلب أي وقت توقف أثناء إعادة البناء.
إزالة git apply للتصحيح من ملف app.yml (يجب القيام بذلك فقط قبل إعادة بناء حاوية التطبيق التالية)
التراجع عن الملف المصحح باستخدام:
i) launcher enter app
ii) (الآن داخل حاوية التطبيق) cd /var/www/discourse git checkout ./lib/email/receiver.rb exit
تحديث discourse باستخدام التحديث الإداري عبر الويب
