إضافة ووردبريس و html كنص (خاصة للبريد الإلكتروني)

لدينا المكون الإضافي لـ Wordpress مُعد لنشر مواضيع كاملة في فئة الإعلانات على منتدانا. يعمل هذا بشكل جيد للغاية، ولكن رسائل البريد الإلكتروني التي يرسلها Discourse مُعلمة بـ Content-Type: text/plain; charset=UTF-8.

على حد فهمي، هذا صحيح تقنيًا، حيث أن التنسيق المتوقع هو markdown، وهو نص عادي إلى حد ما. ولكن، بالطبع، يتضمن markdown أيضًا، سواء للأفضل أو للأسوأ، “html صالح أيضًا، yolo!”.

وفي الواقع، المنشورات القادمة من Wordpress هي عبارة عن مجموعة من HTML.

كيف يتعامل الآخرون مع هذا؟ هل هناك طريقة لجعل المنشورات المرسلة إلى Discourse بتنسيق markdown معقول للبشر بعد كل شيء؟ أو، هل هناك طريقة لفرض نوع محتوى HTML للبريد الإلكتروني المُنشأ في هذه الفئة؟ أو… أي أفكار أخرى على الإطلاق؟ شكرًا!

لتوضيح الأمر فقط يا @mattdm، عندما تقول

هل تقصد بـ “الرسائل” إشعارات البريد الإلكتروني التي تتلقاها من Discourse حول المنشورات الجديدة في فئة الإعلانات الخاصة بك؟

أنا فقط أحاول فهم نقطة الألم المحددة للمستخدم التي تحاول معالجتها هنا.

نعم، آسف. بقصد “رسائل البريد الإلكتروني” عندما قلت “رسائل”. وبقصد Discourse عندما قلت “هو”، وليس إضافة Wordpress. سأقوم بتحرير المنشور العلوي لتوضيح ذلك.

في خيالي، سيكون أفضل شيء هو أن تكون رسائل البريد الإلكتروني متعددة الأجزاء مع نص عادي مُصيّر بتنسيق markdown text/plain و text/html منفصل. لكنني لست متأكدًا حتى من كيفية عمل ذلك.

عذرًا، للتوضيح مرة أخرى، هل تثير هذا لأن إشعارات البريد الإلكتروني لمنشورات Discourse التي تحتوي على HTML (على سبيل المثال، المنشورات المرتبطة بمنشورات Wordpress في فئة الإعلانات الخاصة بك) تحتوي بشكل غير صحيح على كيانات HTML؟ إذا كان الأمر كذلك، هل يمكنك مشاركة مثال؟

السبب في إصراري على هذا هو أن إنشاء إشعارات البريد الإلكتروني في Discourse منفصل تمامًا عن أي شيء يتعلق بمكون Wordpress الإضافي. تتمتع إشعارات البريد الإلكتروني بخط أنابيب خاص بها وهناك طرق متعددة يمكن أن ينتهي بك الأمر بكيانات HTML في منشور Discourse، ومنشور من Wordpress هو مجرد واحد منها.

بمعنى آخر، حقيقة وجود HTML في منشور Discourse هي قضية مختلفة عن ما تحتويه إشعارات البريد الإلكتروني حول هذا المنشور وكيف يتم ترميزها. فهم المشكلة المحددة التي تواجهها / تثيرها سيساعد في توجيه العيون والاهتمام الصحيحين إليها.

قد أكون أسأت فهم ما يحدث، ولكن إليك ما أعتقد أنه يحدث:

  1. يتم نشر تدوينة ووردبريس.
  2. يستجيب المكون الإضافي لذلك وينشئ تدوينة ديسكورس.
  3. تدوينات ديسكورس كلها بتنسيق ماركداون، ولكن يحدث أن التدوينة القادمة من ووردبريس عبر المكون الإضافي هي فوضى من HTML (وهو صالح تمامًا في ماركداون).
  4. يحصل المستخدمون المشتركون في الإشعارات عبر البريد الإلكتروني على بريد إلكتروني يحتوي على هذا النص - والذي يبدو كفوضى من 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 في إشعارات البريد النصي العادي

أفضل شيء سيكون أن تكون رسائل البريد متعددة الأجزاء، مع عرض نصي نظيف بتنسيق ماركداون text/plain وإصدار منفصل text/html

هذا في الواقع كيف تعمل إشعارات البريد في Discourse حالياً. إذا نظرت إلى “الأصلي” لإشعار بريد Discourse، فسترى أن هناك نسخة نصية ونسخة HTML.

ما يبدو أنك تقوله، لكنني لست واضحاً بنسبة 100% بعد، هو أنك تتلقى كيانات HTML في النسخة النصية العادية لإشعارات بريد Discourse، والنتيجة هي أنك ترى كيانات HTML الفعلية في جسم البريد عند النظر إليه في عميل بريد لا يدعم HTML. هل هذا ما تقوله؟ هل يمكنك مشاركة لقطة شاشة لهذا من عميل بريد (لا يدعم HTML)؟

إذا كانت هذه هي الحالة، فهذه قضية خاصة بتوليد محتوى بريد Discourse وتنسيقه، وسيكون من الأفضل فصلها إلى موضوع أكثر تركيزاً في Support أو Contribute > Bug

HTML في منشورات Discourse

أنت تثير قضية ذات صلة هنا، ولكن من الناحية التقنية، تكمن السؤال في كيفية تعامل Discourse مع المحتوى المستورد بشكل أوسع. الإعداد الافتراضي الحالي للمحتوى المستورد هو HTML، وليس ماركداون.

سياقات أخرى يمكنك رؤية هذا فيها هي إضافة RSS Polling، والتي، مثل إضافة WP Discourse، تستورد HTML إلى محتوى المنشور. لاحظ أيضاً أن إعداد الموقع embed support markdown غير مفعّل افتراضياً وجميع إعدادات الموقع الأخرى المتعلقة بـ HTML المضمن في المنشورات (على سبيل المثال allowed embed selectors).

أنا أخمن جزئياً هنا، لكن السبب(الأسباب) الأكثر احتمالاً لاتخاذ هذا القرار الاستراتيجي في الأيام الأولى لـ Discourse في التعامل مع المحتوى المستورد كان مزيجاً من البساطة والدقة، أي أن التحويلات من HTML إلى ماركداون ستكون غير مثالية. هناك استثناء رئيسي واحد لهذا سأذكره أدناه.

يمكن لإضافة WP Discourse محاولة تحويل HTML من منشورات ووردبريس إلى ماركداون قبل إرسالها إلى Discourse. نعم، هناك مكتبات PHP موجودة تحول HTML إلى ماركداون، لكنها ليست بهذه البساطة أبداً عند تحويل لغة ترميز، خاصة مع مراعاة النكهات المختلفة لـ ماركداون.

في الواقع، محاولة إضافة WP Discourse للتعامل مع التحويل ستكون مضللة، نظراً لأنه يوجد بالفعل محول HtmlToMarkdown مخصص في Discourse. حالياً، يتعامل هذا المحول مع تحويل HTML إلى ماركداون في رسائل البريد المستوردة إلى Discourse. إذا تم تحويل HTML من منشورات ووردبريس إلى ماركداون Discourse، فسيتم التعامل معه بواسطة ذلك المحول.

في الوقت الحالي، تستخدم إضافة WP Discourse واجهة برمجة تطبيقات Discourse لنشر المنشورات، أي نقطة النهاية /posts. لذا فإن ما تقوله بشكل أساسي هو أنك تريد إضافة دعم لمحول HtmlToMarkdown إلى نقطة نهاية /posts في Discourse (أي كـ معامل استعلام اختياري). يمكنك الدعوة إلى ذلك، وإذا تم تنفيذه، ستتبنى إضافة WP Discourse ذلك كإعداد اختياري.