هه، في هذا المثال، وفي مصدر البريد الإلكتروني الكامل الذي أرسلته لي (شكرًا لك!)، لا ينبغي أن يؤثر سمة moz-do-not-send على عرض وسوم <img> أو <a> التي تظهر فيها هذه السمة. إن mozfilter ينظر فقط إلى القيم في سمة class، ولا أستطيع رؤية أي مكان آخر قد يتم فيه التصفية فورًا.
وبالتالي، لا أستطيع فهم سبب فصل محتوى الرابط مع الاسم المستعار وقيمة href، إلا إذا كان مستورد Discourse يقرر فجأة استخدام جزء النص العادي من البريد الإلكتروني المشفر بـ Mime (والذي يحتوي بالفعل على النص والرابط منفصلين). ولماذا يفعل ذلك، فلا أدري.
في إعداد Discourse للاختبار لديك، هل يمكنك محاولة استيراد/إرسال بريد إلكتروني بصيغة HTML من Thunderbird يحتوي على رابط مع اسم مستعار، بالإضافة إلى صورة مدمجة أو أي شيء آخر يميزه كجزء HTML من البريد الإلكتروني؟
ما زلتُ أعتقد أن هذا قد يكون استخدامًا لـ Discourse مع أجزاء MIME أخرى (في هذه الحالة، جزء plain/text يتبعه جزء image/… للبريد الإلكتروني لإنشاء نسخته بصيغة Markdown، رغم أنني لا أعرف السبب. ربما يكون محقّق HTML يرفض جزء text/html بسبب سمات غير صالحة تمامًا مثل moz-do-not-send!؟
هل يمكنك إجراء اختبار واحد آخر، بنفس المنشور (بعض النص مع صورة في المنتصف، ولكن أيضًا اجعل بعض النص (وليس كله) عريضًا، حتى لو كانت كلمة واحدة فقط. أعتقد أن هذا سيحدد ما إذا كان جزء النص قادمًا من كتلة text/plain أم text/html.
وعذراً على السؤال، ولكن للتأكد فقط، هل قمت بتعيين incoming_email_prefer_html إلى true (مفعل)؟!
شكرًا لك @Flominator. أرى أن النص العريض أصبح مائلاً، لذا فهو بالتأكيد لا يستخدم HTML مباشرة، لكنه يستجيب للتوكيد بطريقة ما. أتساءل ما إذا كان جزء text/plain من البريد الإلكتروني يتلقى بعض التنسيق الإضافي. هل يمكنك إرسال مصدر البريد الإلكتروني عبر الرسائل الخاصة كما فعلت من قبل؟
مرحبًا @Flominator، شكرًا على البريد الإلكتروني الخام. عند النظر في جزء text/plain البديل من البريد، نرى بالفعل وجود نجوم حول النص الذي يكون عريضًا في جزء text/html. معظم محركات عرض الماركداون (مثل تلك الموجودة في ديسكورش) تفسر هذا على أنه نص مائل. إليك جزء text/plain منسوخًا ولصقًا بمفرده:
Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben ist
Gruß
Flo
وهو يبدو مطابقًا تمامًا لقطتك الشاشة.
لذا، أعتقد أن ما يحدث هو رفض جزء text/html باعتباره HTML غير صالح (ربما بسبب اسم السمة غير القياسي moz-do-not-send في وسوم a). سيتطلب هذا الأمر إجراء تصحيح لتغيير طريقة التحقق من صحة HTML (ربما بإزالة هذه السمات فقط)، وأنا أقل ثقة بشأن استقرار ذلك دون دمج التعديل في الكود الأساسي. سأقوم بمراجعة الأمر عندما يتاح لي بعض الوقت.
هذا يعني أن التصحيح المرفق في تعليق أعلاه سيفشل (ربما ليس “بشكل مذهل” ولكنه قد يتطلب إعادة بناء للحصول على ترقيات تعمل مرة أخرى) عند الترقية لتضمين هذا الالتزام الجديد (ربما ترقيتك التالية).
إذا كان يتم تطبيقه تلقائيًا (على سبيل المثال، باستخدام أمر 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 باستخدام التحديث الإداري عبر الويب
