لدينا المكون الإضافي لـ Wordpress مُعد لنشر مواضيع كاملة في فئة الإعلانات على منتدانا. يعمل هذا بشكل جيد للغاية، ولكن رسائل البريد الإلكتروني التي يرسلها Discourse مُعلمة بـ Content-Type: text/plain; charset=UTF-8.
على حد فهمي، هذا صحيح تقنيًا، حيث أن التنسيق المتوقع هو markdown، وهو نص عادي إلى حد ما. ولكن، بالطبع، يتضمن markdown أيضًا، سواء للأفضل أو للأسوأ، “html صالح أيضًا، yolo!”.
وفي الواقع، المنشورات القادمة من Wordpress هي عبارة عن مجموعة من HTML.
كيف يتعامل الآخرون مع هذا؟ هل هناك طريقة لجعل المنشورات المرسلة إلى Discourse بتنسيق markdown معقول للبشر بعد كل شيء؟ أو، هل هناك طريقة لفرض نوع محتوى HTML للبريد الإلكتروني المُنشأ في هذه الفئة؟ أو… أي أفكار أخرى على الإطلاق؟ شكرًا!
نعم، آسف. بقصد “رسائل البريد الإلكتروني” عندما قلت “رسائل”. وبقصد Discourse عندما قلت “هو”، وليس إضافة Wordpress. سأقوم بتحرير المنشور العلوي لتوضيح ذلك.
في خيالي، سيكون أفضل شيء هو أن تكون رسائل البريد الإلكتروني متعددة الأجزاء مع نص عادي مُصيّر بتنسيق markdown text/plain و text/html منفصل. لكنني لست متأكدًا حتى من كيفية عمل ذلك.
عذرًا، للتوضيح مرة أخرى، هل تثير هذا لأن إشعارات البريد الإلكتروني لمنشورات Discourse التي تحتوي على HTML (على سبيل المثال، المنشورات المرتبطة بمنشورات Wordpress في فئة الإعلانات الخاصة بك) تحتوي بشكل غير صحيح على كيانات HTML؟ إذا كان الأمر كذلك، هل يمكنك مشاركة مثال؟
السبب في إصراري على هذا هو أن إنشاء إشعارات البريد الإلكتروني في Discourse منفصل تمامًا عن أي شيء يتعلق بمكون Wordpress الإضافي. تتمتع إشعارات البريد الإلكتروني بخط أنابيب خاص بها وهناك طرق متعددة يمكن أن ينتهي بك الأمر بكيانات HTML في منشور Discourse، ومنشور من Wordpress هو مجرد واحد منها.
بمعنى آخر، حقيقة وجود HTML في منشور Discourse هي قضية مختلفة عن ما تحتويه إشعارات البريد الإلكتروني حول هذا المنشور وكيف يتم ترميزها. فهم المشكلة المحددة التي تواجهها / تثيرها سيساعد في توجيه العيون والاهتمام الصحيحين إليها.
قد أكون أسأت فهم ما يحدث، ولكن إليك ما أعتقد أنه يحدث:
يتم نشر تدوينة ووردبريس.
يستجيب المكون الإضافي لذلك وينشئ تدوينة ديسكورس.
تدوينات ديسكورس كلها بتنسيق ماركداون، ولكن يحدث أن التدوينة القادمة من ووردبريس عبر المكون الإضافي هي فوضى من HTML (وهو صالح تمامًا في ماركداون).
يحصل المستخدمون المشتركون في الإشعارات عبر البريد الإلكتروني على بريد إلكتروني يحتوي على هذا النص - والذي يبدو كفوضى من HTML.
أدرك أن شخصًا ما يمكنه إنشاء تدوينة ديسكورس يدويًا تحتوي على الكثير من HTML بنفس الطريقة، ولكن من الناحية العملية هذا ليس مشكلة عادةً (ولو كان كذلك، يمكن حله إلى حد كبير بـ “مرحبًا، هل يمكنك التوقف عن ذلك؟”).
تبدو هكذا، سواء في Discourse عند الذهاب لتعديل المشاركة أو عند إرسالها:
<small>نشرت في الأصل في: https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>مجموعة هندسة منصات المجتمع، أو CPE للاختصار، هي فريق Red Hat الذي يجمع بين هندسة تكنولوجيا المعلومات والإصدار لـ Fedora و CentOS. لدينا حاليًا منصب مفتوح لـ <a href="https://global-redhat.icims.com/jobs/96157/software-engineer/job?mobile=true&width=412&height=732&bga=true&needsRedirect=false&jan1offset=-480&jun1offset=-420">مهندس برمجيات في الهند</a>.</p>
<h2>عن الدور</h2>
<p>نحن <a href="https://global-redhat.icims.com/jobs/96157/software-engineer/job?mobile=true&width=412&height=732&bga=true&needsRedirect=false&jan1offset=-480&jun1offset=-420">نوظف مواهب جديدة</a> للعمل بدوام كامل على Fedora، بشكل أساسي كجزء من مجموعة هندسة الإصدار لدينا. ستعمل على البنية التحتية التي تبني وتشحن أصول وتحديثات إصدار Fedora Linux. هذا الدور مثالي لأي شخص لديه خبرة أو اهتمام بهندسة الإصدار.</p>
<h2>عن CPE</h2>
<p>هدفنا هو الحفاظ على تشغيل الخوادم والخدمات الأساسية وصيانتها، وبناء الإصدارات، وأداء المهام الاستراتيجية الأخرى التي تتطلب وقتًا أكثر تفانيًا مما يمكن للمتطوعين تقديمه.</p>
<p>راجع <a href="https://docs.fedoraproject.org/en-US/cpe/">مستنداتنا</a> لمزيد من المعلومات. نتطلع إلى مقابلتك وربما العمل معك قريبًا!</p>
حسنًا، سأقوم بالرد على المشكلات التي تثيرها هنا بشكل منفصل. أتفهم سبب ربطك لها، ولكن آمل أن ترى لماذا هي مشكلات منفصلة.
كيانات HTML في إشعارات البريد الإلكتروني النصية العادية
أفضل شيء هو أن تكون رسائل البريد الإلكتروني متعددة الأجزاء مع نص عادي مُصاغ من Markdown text/plain و text/html منفصل.
هذه هي الطريقة التي تعمل بها إشعارات البريد الإلكتروني لـ Discourse حاليًا. إذا نظرت إلى “الأصل” لإشعار بريد إلكتروني لـ Discourse، فسترى أن هناك إصدارًا نصيًا وإصدارًا بتنسيق HTML.
ما يبدو أنك تقوله، ولكنني لست متأكدًا بنسبة 100٪ من ذلك، هو أنك تحصل على كيانات HTML في الإصدار النصي العادي لإشعارات البريد الإلكتروني لـ Discourse، والنتيجة هي أنك ترى كيانات HTML الفعلية في نص البريد الإلكتروني عند عرضه في عميل بريد إلكتروني لا يدعم HTML. هل هذا ما تقوله؟ هل يمكنك مشاركة لقطة شاشة لهذا من عميل بريد إلكتروني (لا يدعم HTML)؟
إذا كان الأمر كذلك، فهذه مشكلة خاصة بإنشاء محتوى Discourse وتنسيقه، وسيكون من الأفضل فصلها إلى موضوع أكثر استهدافًا في Support أو Bug.
HTML في مشاركات Discourse
أنت تثير مشكلة ذات صلة هنا، ولكن من منظور تقني، تكمن المشكلة في كيفية تعامل Discourse مع المحتوى المستورد بشكل عام. الإعداد الافتراضي الحالي للمحتوى المستورد هو HTML، وليس Markdown.
سياقات أخرى يمكنك رؤية هذا فيها هي ملحق RSS Polling، والذي، مثل ملحق WP Discourse، يستورد HTML إلى محتوى المشاركة. لاحظ أيضًا أن إعداد الموقع embed support markdown معطل افتراضيًا وجميع إعدادات الموقع الأخرى التي تتعامل مع HTML المضمن في المشاركات (مثل allowed embed selectors).
أنا أخمن جزئيًا هنا، ولكن السبب الأكثر احتمالاً لاتخاذ هذا القرار الاستراتيجي في الأيام الأولى لتعامل Discourse مع المحتوى المستورد كان مزيجًا من البساطة والوفاء، أي أن التحويلات من HTML إلى Markdown ستكون غير مثالية. هناك استثناء رئيسي واحد لهذا سأذكره أدناه.
يمكن لملحق WP Discourse محاولة تحويل HTML لمشاركات WordPress إلى Markdown قبل إرسالها إلى Discourse. نعم، توجد مكتبات PHP موجودة لتحويل HTML إلى Markdown، ولكن الأمر ليس بهذه البساطة عند تحويل لغة ترميز، خاصة بالنظر إلى النكهات المختلفة لـ Markdown.
في الواقع، سيكون محاولة ملحق WP Discourse التعامل مع التحويل مضللة، نظرًا لوجود محول مخصص بالفعل HtmlToMarkdown في Discourse. حاليًا، يتعامل هذا المحول مع تحويل HTML إلى Markdown في رسائل البريد الإلكتروني المستوردة إلى Discourse. إذا تم تحويل HTML للمشاركات من WordPress إلى Markdown لـ Discourse، فسيتم التعامل معه بواسطة هذا المحول.
حاليًا، يستخدم ملحق WP Discourse واجهة برمجة تطبيقات Discourse لنشر المشاركات، أي نقطة النهاية /posts. لذا، ما تقوله أساسًا هو أنك تريد إضافة دعم محول HtmlToMarkdown إلى نقطة النهاية /posts لـ Discourse (أي كمعلمة استعلام اختيارية). يمكنك الدعوة لهذا، وإذا تم تنفيذه، فسيعتمده ملحق WP Discourse كإعداد اختياري.