أنا فقط أتابع هذا الموضوع - ولكني بالتأكيد أعتقد أن الإجابة هي نعم
بسبب نجاح مجتمع المؤسسة لدينا (مع المستخدمين لدينا، وداخل أعمالنا) ، تواصل فريق التوثيق لدينا وسأل عما إذا كان بإمكاننا بناء نظام تعليقات لجميع وثائق sailpoint.com. من المظهر، سنكون قادرين على القيام بكل شيء تقريبًا نريد تحقيقه كحد أدنى:
تضمين التعليقات (ميزة التضمين)
نريد أيضًا استخدام مستخدمين مختلفين للنشر، وتطبيق مجموعات مختلفة من العلامات، بناءً على التضمين. هذه الميزة قادمة قريبًا جدًا:
من هناك، كان كل ما أراده فريق الوثائق (وفريقي) موجودًا في Discourse لنفصل هذه التجربة بفعالية عن بقية استخدامنا “اليومي” للمنتدى، مع الاستمرار في منح الأشخاص القدرة على التعليق، وتلقي إشعارات بالردود، وما إلى ذلك.
القدرة على تحديد المستخدمين الذين يمكنهم التعليق والذين لا يمكنهم ذلك
تعيين مشرفي الفئات للمواضيع المرتبطة
قمع هذه الوفرة من الفئات لهذه الوثائق من موقعنا الرئيسي
الفئة غير قابلة للبحث
مكون سمة مستخدم لإخفائه من قائمة الفئات الرئيسية
قمع من الملخص
إضافة إلى الفئات المكتومة افتراضيًا
إزالة التعليقات بعد ن أيام
بعض الإعدادات الأخرى…
أود بالتأكيد أن أرى العديد من الميزات المذكورة هنا مطبقة، على الرغم من ذلك!
هل الهدف هو السماح للمستخدمين بإنشاء تعليقات على https://documentation.sailpoint.com/، أم أنكم على ما يرام مع مجرد تضمين التعليقات على موقع التوثيق والسماح للمستخدمين بزيارة موقع Discourse الخاص بكم للتعليق على المقالات؟
الأولى هي ميزة أرحب بها وأحب أن أحصل عليها (اقرأ: من فضلك قم ببنائها يا CDCK)، لكن الأخيرة تلبي الحد الأدنى من متطلباتنا، على الأقل.
في الواقع، سأستكشف فكرة في المستقبل القريب لجعل Discourse يقدم وثائق markdown الخاصة بنا (لا، ليس في المواضيع، ولكن في وثائق بأسلوب markdown التقليدي) وفي هذه الحالة ستكون التعليقات والتسجيل لإنشائها شاملة. لكن هذا الاستكشاف لم يبدأ بعد.
مع النهج الذي أعمل عليه الآن، سيكون من الممكن تقنيًا السماح بإنشاء تعليقات Discourse مباشرة على صفحات MkDocs، ولكن سيتطلب ذلك استخدام إطار عمل من جانب الخادم (Remix، Rails، إلخ) لتقديم صفحات MkDocs. سيجعل ذلك من الممكن مصادقة المستخدمين (باستخدام DiscourseConnect) على موقع المستندات والسماح أيضًا باستخدام قاعدة بيانات في الذاكرة للتخزين المؤقت للتعليقات التي تم إرجاعها مسبقًا.
(تعديل: للتوضيح فقط، أنا أتحدث عن استخدام Discourse كموفر هوية للموقع، وليس الموقع كموفر هوية لـ Discourse. النهج الأخير يعمل، ولكنه غير مرن للغاية لمعظم حالات الاستخدام.)
سيكون هذا تغييرًا كبيرًا لطلب تقديمه من فريقك.
أنا متأكد من أنه من وجهة نظرك سيكون الأمر أكثر وضوحًا إذا تم تحقيق ذلك بالكامل داخل Discourse، ولكن من الممكن أيضًا استخدام Discourse كنظام إدارة محتوى. في هذه الحالة، سيتم إنشاء وثائق markdown كمواضيع Discourse عادية. سيتم استخدام خطافات Discourse لتشغيل إنشاء صفحة مستندات على موقع خارجي. هذا هو في الواقع أساس موقع عرض تعليقات Discourse الذي أقوم بإعداده.
بما أن هذا الموضوع تم ربطه اليوم، فقد قررت تحديثه بالاستنتاجات التي توصلت إليها بعد بذل بعض الجهد في هذه الفكرة.
ما زلت أعتقد أن Discourse ستكون منصة تعليقات جيدة للأسباب التي أوضحتها في المنشور الأصلي.
فيما يتعلق بكيفية تحقيق ذلك، أعتقد أن العمل يجب أن يتم من جانب Discourse - بشكل مثالي عن طريق تحسين نص تضمين تعليقات Discourse. يمكن القيام بذلك بشكل تدريجي.
من الممكن تقنيًا استخدام Discourse كخادم لمنصة تعليقات عن طريق القيام بكل العمل على عميل Discourse (على سبيل المثال، المكون الإضافي WP Discourse)، ولكن بسبب الحاجة إلى إدارة الحالة بين العميل و Discourse، وتجاوز مشكلات تحديد المعدل، يصبح الأمر مشكلة معقدة. إنه بالتأكيد أكثر تعقيدًا مما أرغب في تحمل مسؤوليته في صيانته.
أشارت بعض المشاركات في هذا الموضوع إلى أن الناس سيكونون مهتمين فقط بالسماح للمستخدمين بـ إنشاء تعليقات Discourse على موقع مدونة. من وجهة نظري، هذا ليس حلاً رائعًا، ولكنه يمكن تحقيقه الآن باستخدام واجهة برمجة تطبيقات Discourse. تكمن التعقيدات في محاولة إنشاء نظام تعليقات كامل، حيث يمكن للمستخدمين التفاعل مع تعليقات Discourse على موقع ويب بطريقة مشابهة لكيفية توقعهم التفاعل مع التعليقات على موقع إخباري رئيسي نموذجي.
بالنظر إلى خبرتي مع ActivityPub و WP Discourse، أعتقد أن التعليق ثنائي الاتجاه عبر جافا سكريبت مضمن قابل للتحقيق. سيحتوي برنامج التضمين النصي على ما يلي:
“قراءة” غير مصادق عليها تعمل بطريقة مماثلة لبرنامج التضمين النصي الحالي (مع بعض التحسينات).
يقوم المستخدم بالمصادقة (مع Discourse) لاسترداد مفتاح واجهة برمجة التطبيقات للمستخدم الخاص بالجلسة والذي يتم تخزينه في التخزين المحلي للمتصفح.
يتم نشر كل نشاط (تعليق، إعجاب، إلخ) مباشرة إلى نقطة نهاية مخصصة مع الضمانات المناسبة وإدارة المهام.
مع الميزانية الصحيحة، أعتقد أنه يمكنني جعل الإصدار الأول جاهزًا للإنتاج ومتكاملًا مع discourse/discourse في 6-8 أشهر. بعد الإصدار الأولي، يمكنني القيام بما يلي:
إضافة دعم صريح لـ Wordpress و Ghost ومنصات أخرى مختارة.
حاول تنفيذه بطريقة منطقية للمستخدمين غير التقنيين. توفر المنصات الحالية مثل Disqus وتعليقات Facebook أمثلة جيدة على الأرجح.
بعض خيارات المصادقة الإضافية:
يصبح موقع العميل عميل DiscourseConnect. هذا سهل التنفيذ، ولكنه يتطلب إضافة كود من جانب الخادم إلى موقع العميل.
يقوم المستخدمون بالمصادقة على العميل ويتم تمرير حالة المصادقة الخاصة بهم إلى الإطار المضمن (iframe) باستخدام واجهة برمجة تطبيقات postMessage: Window: postMessage() method - Web APIs | MDN
يقوم المستخدمون بتسجيل الدخول مباشرة إلى Discourse عبر الإطار المضمن (iframe)
ترددي في تطوير هذا بشكل حصري من جانب العميل جاء من النظر في مشاكل عمل النظام بأي نوع من أنواع التوسع. في الأساس، اضطررت إلى وضع طلبات واجهة برمجة التطبيقات (API) في قائمة انتظار والتعامل مع الاستجابات من الطلبات المعلقة. لم يبدو الأمر قوياً بما يكفي للتعامل مع، على سبيل المثال، 1000 مستخدم متزامن. ستكون لدي مخاوف مماثلة، ولكن لأسباب مختلفة مع نهج التضمين باستخدام جافاسكريبت. أشك في أنه سيكون من الأسهل بكثير التعامل معه مقارنة بمحاولة مزامنة كل شيء من جانب العميل.
لقد فكرت في هذا الأمر بعمق أكبر بالأمس حيث تم طرح الموضوع (وهذا هو سبب نشري هنا). أعتقد أن الحل الخاص بالعميل فقط (أي تضمين جافاسكريبت) هو الحل الوحيد المنطقي حقًا هنا. بخلاف ذلك، فإننا نتحدث في الأساس عن عدد من التطبيقات الخاصة بالمنصة، ولكل منها مجموعة مشاكلها الخاصة.
أنت على حق في أن التزامن والحمل يمثلان مشكلتين. هناك مشاكل كبيرة في الحمل والتزامن مع ActivityPub حيث يمكن لمنشور ActivityPub واحد أن يعرضك للعديد من الطلبات الواردة والصادرة من وإلى Fediverse. في هذا السياق، قد يكون هذا أسهل قليلاً لأن العملاء البعيدين يتم التحكم فيهم. علاوة على ذلك، في هذه الحالة، يمثل التزامن والحمل مشكلتين فقط على جانب الخادم (أي جانب Discourse)، وعلى الرغم من أنهما مشكلتان، أعتقد أنه يمكن حلهما عبر المهام الخلفية والتخزين المؤقت والمزامنة. ولكن نعم، إنها مشاكل مهمة يجب مراعاتها.
Composer v2 على وشك الانتهاء، سيكون من الجنون الشروع في هذه المغامرة وعدم الاعتماد على Composer الجديد لدينا، ولكن هناك جبل من العمل نحتاجه مقدمًا لجعله قابلاً للاستخدام في تطبيق خفيف الوزن.
أعتقد أن الشيء الصحيح الذي يجب فعله هنا هو مراقبة هذا المجال لـ Composer الجديد لمدة 2-3 أشهر، ثم إعادة النظر في المسألة.
أعتقد أنه يمكن القيام بذلك بالتوازي. تحتاج إلى إجراء تغييرين على الخطاب.
يجب أن يكون زر “رد” مرئيًا للمستخدمين غير المسجلين.
وعندما ينقر المستخدمون غير المسجلين على هذا الزر، يجب عرض هذا:
بعد ذلك، تحتاج إلى معرفة كيفية استخدام إدراج التعليقات. من المحتمل أن تكون هذه تغييرات صغيرة في التعليمات البرمجية بدلاً من الكثير من العمل.
