مئات المرات التي كنت فيها على صفحة CSS تلك، ولم ألاحظ أبدًا CSS للتضمينات…
إعجاب واحد (1)
حاولت تطبيق هذا اليوم ولكن هناك بعض المشاكل بالنسبة لي:
- في منشور المنتدى، يتم تحويل عنوان URL المشتق (من discourseEmbedUrl؟) إلى أحرف صغيرة، مما يؤدي إلى كسر عناوين URL الحساسة لحالة الأحرف في الرابط الذي يلي النص “هذا موضوع مناقشة مصاحب للمدخل الأصلي على …”.
- عند تحميل الصفحة لأول مرة، يعرض التضمين “جارٍ تحميل المناقشة…” ويتوقف. عند تحميل الصفحة للمرة الثانية، يعمل كل شيء.
- تقليب الصفحات: عند تحميل الإطار المضمن (iframe)، سيكون له ارتفاع افتراضي، ولكن إذا لم يتم العثور على تعليقات، فإن الارتفاع يعود ليظهر سطرًا واحدًا فقط مع “بدء المناقشة”. هذا يجعل خطأ “تحميل المناقشة” أسوأ، لأنه يحتفظ بارتفاع عمودي كبير.
- سيكون من الجيد لو فضلت البيانات التي تم كشطها من الوالد (parent) للتضمين علامة meta بدلاً من تحويل الصفحة بأكملها إلى نص، أفترض أن هذا سلوك عام لـ discourse.
كانت أكبر مفاجأة هي معرفة أنه في كل مرة تزور فيها عنوان URL مع تضمين، يتم إنشاء موضوع جديد. هذا في OP:
الحل الوحيد الذي يمكنني التفكير فيه هو حل غير أنيق، يعتمد على SSR/التخزين المؤقت قصير المدى لتنبيه نقطة نهاية التضمين:
لذا أعتقد أن المنطق سيكون:
-
تحقق من
$discourse/embed/info?embed_url=$link -
إذا كان الموضوع موجودًا، فاعرض التضمين كالمعتاد.
-
إذا لم يكن كذلك، فاعرض زر “بدء محادثة” يربط بـ
$discourse/new-topic?subject=$link.
هل سينجح ذلك، أم أن هناك ارتباطًا آخر يحتاج إلى إجرائه؟
يتم إنشاء موضوع جديد فقط عند زيارة صفحة تحتوي على تضمين لأول مرة. في الزيارات اللاحقة، يتم عرض الموضوع الموجود المرتبط بعنوان URL.
إذا كنت لا ترغب في إنشاء الموضوع تلقائيًا، يمكنك إنشاء المواضيع عبر استدعاءات API بالطريقة التي تناسبك بشكل أفضل ثم تمرير topicID إلى التضمين للتحكم يدويًا في الارتباط.
مفهوم، هذا قاسٍ بالنسبة لحالتي لأن هناك عشرات الآلاف من الصفحات
مثل هذا؟
- التحقق من API لمعرفة ما إذا كان الموضوع موجودًا
- لا يوجد، عرض الزر
- النقر على الزر، إضافة API للموضوع
- ناجح، يتحول حاوية الزر إلى تضمين
… هذا له بعض المشاكل أيضًا، مثل نقرات الأزرار بدون تفاعل متابعة.
هل هناك أي طريقة لإنشاء الموضوع فقط عندما يعلق المستخدم بالفعل، شيء مثل هذا؟:
$discourse/new-topic?subject=$link.
أم أن المشكلة هنا هي أنه لا يمكننا تمرير topicID للاقتران الحتمي؟
لا، لا يمكن الرد على موضوع غير موجود في Discourse.
لمعالجة هذه الحاجة، جعلنا من الممكن إنشاء جميع المواضيع المضمنة كمواضيع غير مدرجة يتم إدراجها تلقائيًا في المرة الأولى التي يرد فيها شخص ما.
أعتقد أن إنشاء الموضوع سيتطلب طلبًا مصادقًا عليه يتم تشغيله على الخادم. إذا كنت لا ترغب في التعامل مع ذلك، فإن نهجًا آخر هو إضافة زر إلى واجهة المستخدم يقوم بتشغيل رمز مشابه لهذا (الرمز الذي سيتم إضافته تلقائيًا إلى علامة رأس الصفحة): discourse/public/javascripts/embed.js at 581dbca97f2b55c9bbbe40dc3b58a9df7409d77f · discourse/discourse · GitHub. إنه مجرد إنشاء عنصر iframe باستخدام هذه البيانات:
<div id='discourse-comments'></div>
<meta name='discourse-username' content='DISCOURSE_USERNAME'>
<script type="text/javascript">
DiscourseEmbed = {
discourseUrl: 'http://127.0.0.1:4200/',
discourseEmbedUrl: 'EMBED_URL',
// className: 'CLASS_NAME',
};
</script>
تعديل: كان علي أن أجرب. هذا مجرد إثبات مفهوم: discourse-embed-iframe-test/app/routes/triggering-embed-code.tsx at main · scossar/discourse-embed-iframe-test · GitHub. لا أعتقد أنه حل رائع لمشكلتك.
المنطق موجود بالكامل على العميل (وظيفة المحمل هي فقط للراحة). للأسف، لا توجد طريقة رائعة للعميل لمعرفة ما إذا كان الموضوع موجودًا على Discourse. لذلك لا يمكن تخصيص واجهة المستخدم بناءً على ما إذا كان الموضوع موجودًا بالفعل أم لا. هناك طرق يمكن حلها، ولكنها قد تتطلب كتابة شيء ما في قاعدة بيانات التطبيق.
يستخدم Discourse Window: postMessage() لتمرير البيانات من iframe إلى المستند الأصلي. على سبيل المثال، عند النقر فوق رابط الرد في التعليقات المضمنة: discourse/app/assets/javascripts/discourse/scripts/embed-application.js at 581dbca97f2b55c9bbbe40dc3b58a9df7409d77f · discourse/discourse · GitHub. أتساءل عما إذا كان يمكن إرسال رسالة إلى المستند الأصلي للإشارة إلى أنه تم إنشاء موضوع. سيسمح ذلك للمواقع بالقيام بأشياء مثل تعيين مؤشرات تحميل مخصصة، أو عرض واجهة مستخدم مختلفة اعتمادًا على ما إذا كان الموضوع جاهزًا لتلقي التعليقات أم لا.
إعجاب واحد (1)
لا أعتقد أن هذا ضروري إذا كان من الممكن تعيين رابط أساسي لمنشور جديد:
$discourse/new-topic-link?link=$link
والذي من المفترض أن يعيد التوجيه إلى الموضوع إذا كان موجودًا بالفعل ويستخدم المنطق الحالي في تضمين المسؤول. ربما مع قوالب؟
أعتقد أن طريقة أخرى لحل هذا هي البحث عن أي منشورات تشير إلى الرابط المعني وإظهار أي مطابقات كجزء من محادثة على مستوى الموقع، وعرضها مباشرة في الصفحة عبر SSR. قد يكون هذا مكافئًا نظرًا لأن التضمينات للقراءة فقط على أي حال. المشكلة الأكثر وضوحًا هناك ستكون اختيار الموضوع الذي سيتم إرسال المستخدم إليه عندما يريد المشاركة.
تحرير: إذا تمكنت من معرفة كيفية البحث عن المنشورات حسب محتوى الرابط
أتساءل عما إذا كان يمكن استخدام هذه الميزة لمهاجمة منتدى Discourse. على وجه التحديد، هل من الممكن لشخص ما تزوير زيارات الصفحات ضمن عناوين URL متعددة لمضيف وإنشاء العديد من المواضيع؟
مرحباً بمجتمع Discourse!
يسعدني أن أشارككم إضافة قمت بتطويرها لأولئك الذين يستخدمون Docusaurus v3 ويرغبون في تضمين تعليقات Discourse على مواقعهم.
docusaurus-plugin-discourse-comments
تسهل هذه الإضافة دمج تعليقات Discourse في موقع Docusaurus v3 الخاص بك. إليك بعض الميزات الرئيسية:
- تكامل سلس مع Docusaurus v3
- مسارات تضمين قابلة للتكوين
- وضع تصحيح الأخطاء لتسهيل استكشاف الأخطاء وإصلاحها
- معالجة تلقائية لعناوين URL للتضمين
- وضع قابل للتخصيص للتعليقات
إذا كنت تستخدم Docusaurus v3 وترغب في إضافة تعليقات Discourse إلى وثائقك أو منشورات مدونتك، فإن هذه الإضافة تبسط العملية بشكل كبير.
يمكنك العثور على الإضافة على npm: docusaurus-plugin-discourse-comments
4 إعجابات
لنفترض أن لديّ مضيفًا واحدًا قابلاً للتضمين، وهو blog.example.com وقائمة سماح بمسار حرف بدل مثل /.*.
أود إضافة تضمين إضافي باستخدام نفس المضيف، ولكن هذه المرة بقائمة سماح مختلفة، مثل /new-release.* وبعلامة إضافية، ولنقل releases.
من الواضح أن موضوع “الإصدار الجديد” يمكن أن يطابق كلا مجموعتي المضيف/المسار، ولكن أي من المجموعتين ستكون له الأسبقية؟ بأي ترتيب يتم تقييم القواعد؟
هل لا يزال من غير الممكن تضمين موضوع من منتدى خاص على مضيف منفصل؟ حالة الاستخدام الخاصة بي هي أننا نستخدم Kajabi لاستضافة المنتج ونستخدم Discourse كمنصة تعليقات لدينا. يتطلب كل منهما تسجيل دخول منفصل، لذلك أظن أن الإجابة لا تزال “غير ممكنة”، ولكن هذا أحد العوامل المقيدة لمستخدمينا ومصدر إزعاج كبير حيث لدينا أكثر من 750 وحدة، لكل منها مساحة مناقشة مخصصة. إذا كان بإمكاني تضمين موضوع Discourse لكل وحدة Kajabi في نفس الصفحة، حتى بدون القدرة على التعليق على الصفحة، فسيؤدي ذلك إلى تبسيط كل شيء ويسمح بالربط السهل بالموضوع ذي الصلة في Discourse. إذن، هل هناك أي تقدم في هذا الأمر أم أن هذا سيظل دائمًا قيدًا على المنتديات الخاصة؟
أرى أنه لا يمكن تضمين التعليقات من منتدى خاص (على موقع يستخدم نطاقًا منفصلاً):
[اقتباس=“Discourse, post:1, topic:31963”]
بالنسبة لحالات Discourse الخاصة، إذا كان Discourse موجودًا على نطاق فرعي من نطاق المدونة، فسيتم عرض التعليقات للمستخدمين المسجلين الدخول إلى Discourse. سيرى المستخدمون غير المسجلين الدخول إلى Discourse رسالة ‘رفض الاتصال’. إذا كان Discourse والمدونة على نطاقين منفصلين تمامًا، فلن يتم عرض أي تعليقات للمنتديات الخاصة.
[/اقتباس]
ما يستخدمه زميل للتعليقات على موقع Ghost هو منتدى عام (على نطاق مختلف تمامًا)، وينشر معظم المنشورات المجانية. لقد نشر مؤخرًا أول منشور خاص بالأعضاء فقط، وعندما قمت بتغيير الموضوع المرتبط به على Discourse إلى فئة غير قابلة للعرض بواسطة “الجميع” بل لمجموعة معينة (مرتبطة بالأعضاء الذين يدفعون على موقع Ghost)، يعرض التضمين الآن الرسالة “خطأ في التضمين”.
على الرغم من أن صاحب الموضوع الأصلي (OP) قال إن المنتديات الخاصة (على نطاقات منفصلة) لن تسمح للتضمين بالعمل، إلا أن هذا منتدى عام ولكنه يحتوي على فئة خاصة. هل المشكلة التي أراها ناتجة عن كون فئة خاصة في منتدى عام هي نفس الشيء وظيفيًا مثل منتدى خاص؟ لقد قرأت بالفعل التعليق التالي، الذي يبدو أنه يدعم هذا التأكيد:
[اقتباس=“simon, post:448, topic:31963”]
طالما أنك لا تقوم بتضمين المواضيع في فئة Discourse خاصة، فإن وجود المدونة على نطاق مختلف عن Discourse لا ينبغي أن يسبب مشكلة.
[/اقتباس]
إذا كان الأمر كذلك بأن المواضيع من الفئات الخاصة في المنتديات العامة لا يمكن تضمينها بشكل افتراضي، فهل هناك أي طريقة يمكن بها القيام بذلك مع بعض التعديلات على التضمين (و/أو المنصة)؟ لست في عجلة من أمري لـ (أتمنى) “إصلاح” هذه المشكلة حيث أنني موافق إلى حد ما على تعيين الفئة الخاصة إلى عامة مؤقتًا (حيث لا يمكن لـ Discourse كشط محتوى منشور Ghost الخاص وبالتالي عرضه عن طريق الخطأ للمستخدمين غير الدافعين على Discourse)، ولكن إذا كان من الممكن جعل هذا يعمل، فلن أمانع في توظيف شخص ما في وقت لاحق لتعديل التضمين و/أو تقديم طلب سحب (PR) للمنصة.
مرحباً، أنا أستخدم وظيفة التضمين مع مدونتي Ghost، ومع ذلك أواجه بعض المشكلات في كيفية ظهور منشورات المدونة في منتداي. لدي الإعدادات المضيفة التالية:
بسبب التحديات مع إعداد النطاق الفرعي (لدي نطاقي مع مزود خدمة إنترنت مختلف عن المكان الذي يوجد فيه منتدى Discourse الخاص بي)، قررت استخدام مسار العلامات.
المشكلة التي أواجهها هي أن جميع منشورات مدونتي تنتهي في فئة المدونة على منتدى Discourse الخاص بي. أستخدم مستخدمًا إداريًا لمؤلف المنشورات على Discourse، وتسمح جميع الفئات الثلاث للمسؤولين بإنشاء مواضيع جديدة.
هل هناك أي رؤى حول ما قد يسبب هذا؟
ربما تحدد المسارات لكل منها؟ على سبيل المثال، إذا كانت المنشورات من المفترض أن تكون في فئة المدونة تحت /blog/<slug>، على ما أذكر يمكنك فعل /blog/*.
إعجاب واحد (1)
هذا لا يعمل مع مدونة Ghost (على الأقل ليس مع تثبيت قياسي إلى حد ما). أنا أستخدم نطاقي الرئيسي (alphagamer.net)، تضيف مدونة Ghost المسار تلقائيًا بناءً على عنوان منشور المدونة بعد النطاق. حاولت إضافة مسار ولكنه يزيله ببساطة.
إعجاب واحد (1)
كنت أتساءل عما إذا كان يمكن تضمين تعليقات discourse (موضوع) في موضوع discourse؟ ربما باستخدام Iframe يتضمن زر الرد ولكن ليس بقية الموقع. أي بدون رأس أو تذييل.
لقد استخدمته مع Ghost دون مشاكل بخلاف الافتقار إلى تكامل SSO، مما يزعج المستخدمين.
أتذكر أنني احتجت إلى تعديل الكود المثال قليلاً.
أعتقد أنه يعمل بشكل جيد إذا كان لديك تضمين واحد، وأعتقد أنه إذا كنت تحاول تضمين أنواع مختلفة من منشورات المدونة في فئات مختلفة من Discourse، فستحتاج إلى المزيد من التعديلات.
اعتقدت أنني أستطيع جعله يعمل باستخدام العلامات، لكن العلامات وحدها لا تبدو كافية (بالنسبة لإعداداتي). أعتقد أنه في Ghost سأحتاج إلى إنشاء مجموعات المحتوى والتي تسمح لي أساسًا بإضافة بنية مجلدات (مثل alphagamer.net/blog/ وغيرها التي أحتاجها). سأجرب هذا في عطلة نهاية الأسبوع، وأقوم بتحديث “قائمة السماح بالمسارات” الخاصة بي وأشارك هنا إذا تمكنت من جعل هذا يعمل.
هل يمكن أن تكون القائمة المسموح بها مفصولة بفواصل مثل هذه؟
/blog/.*,/articles/.*
تعديل: يبدو أن هذا لا يعمل. وهذا أيضًا لا يعمل:
/(blog|articles)/.*
ربما يحتاجون إلى أن يكونوا مضيفين منفصلين؟