لتبسيط مجموعة تقنياتنا، أتساءل عما إذا كان يجب علينا استضافة موقع إلكتروني ومنتدى بشكل منفصل، بل إعادة تكوين Discourse ليكون كلاً من موقعنا الإلكتروني ومنتدىنا معًا.
أرى أن هذا هو النهج الذي يتبعه Pavilion الذي يديره @angus باستخدام Discourse.
لكن احتياجات موقعنا الإلكتروني أكثر تعقيدًا! هذا هو موقعنا الإلكتروني الحالي.
سأكون مهتمًا بمعرفة ما إذا كانت هناك مواقع إلكترونية أخرى تعتمد فقط على Discourse يمكنني استكشافها. أو إذا كانت لديك أي أفكار حول كيفية تحقيق ذلك.
حسناً، من الممكن استخدام نشر الصفحات للمحتوى غير الخاص بالمنشورات.
ثم استخدم إضافة قائمة فرعية في الرأس للحصول على قائمة علوية تحتوي على قوائم فرعية، أو إضافة أخرى للحصول ببساطة على قائمة بدون قوائم فرعية.
يعتمد الأمر كله على متطلباتك.
نعم! أعتقد أن هذه بداية ممتازة.
أحد متطلباتنا يتمحور حول القدرة على تضمين عناصر مثل نموذج الاشتراك في النشرة البريدية ونموذج التبرعات.
أنا أيضًا لا أعرف بالضبط مدى قوة التخصيص في تنسيق الصفحات للنشر. أتساءل عما إذا كانت هناك أمثلة على صفحات تتمتع بتنسيق أكثر تميزًا، تتضمن عناصر مثل كتل المحتوى ذات الخلفيات المختلفة.
تختزل المسألة في ثلاثة عناصر:
يمكنك خدمة ملايين مشاهدات الصفحات من خادم VPS بسعر 5 دولارات يعمل بنظام WordPress مع وجود تقنيات التخزين المؤقت وشبكة توصيل المحتوى (CDN) المناسبة. في المقابل، ستكون تكلفة مثيل من Discourse أعلى بكثير، بل وأعلى بشكل كبير.
إذا كان معظم الزيارات والنشاط يحدث داخل Discourse ولا يوجد خطر من طفرات في حركة المرور على الصفحات الثابتة، فقد يكون استضافتها جميعًا داخل Discourse خيارًا منطقيًا. أما في الحالات الأخرى، فلا يزال نظام إدارة المحتوى (CMS) المناسب هو الخيار الأفضل.
تم تقسيم 15 منشورًا إلى موضوع جديد: شهادة SSL لا تعمل على موقع Discourse الرئيسي
يُعد Discourse نظامًا خلفيًا مبنيًا على Rails وقابلًا للتوسع، لذا يمكنك فعل أي شيء يمكن لتطبيق Rails فعله كما أعتقد، لكن هل تبحث عن حل سحري؟
في حين أنه يمكن بالتأكيد القيام بذلك، وقد يكون منطقيًا لمنظمتك، فإننا في Discourse نستخدم برمجيات مختلفة لموقعنا الإلكتروني الرئيسي.
موقعنا الإلكتروني الرئيسي هو HTML ثابت تم إنشاؤه بواسطة https://jekyllrb.com/، ومدونتنا هي مثيل بسيط لـ WordPress.
يعتمد ذلك حقًا على كيفية هيكلة الهندسة في منظمتك وما هي الاحتياجات والأولويات التي لديك.
شكرًا لك يا رافائيل.
أنا متحمس للخروج من ووردبريس. كنت أفكر في الاعتماد على حل يعتمد فقط على ديسكورس، لكنني الآن أعتقد أنني سأستخدم جيكيل للمحتوى الثابت/المعلوماتي الموجود حاليًا في www.literatecomputing.com، وأنتقل فقط الأجزاء المتعلقة بكسب المال إلى ديسكورس وإلى إضافة discourse-subscriptions الواعدة. أعمل بحماس على إضافة ديسكورس ستكون واجهة أمامية لأدواتي التي تقوم بالتثبيت والترقيات وصيانة أخرى.
كطعام للتفكير، إليك موقعان إلكترونيان تم إنشاؤهما بالكامل باستخدام Discourse (الموقع الأول يستخدم إضافة Docuss، والتي أصبحت الآن غير مدعومة، بينما يستخدم الموقع الثاني إضافة DiscPage):
شكرًا لك على هذا الإطار لاتخاذ القرار!
يجب أن أكون صادقًا وأقول إنني لست متأكدًا من معنى هذا، لذا سأترك الأمر الآن لفريقنا التقني. 
@باومان هل يمكنك التوضيح أكثر؟ ما هي نقاط الألم التي تواجهها؟ لا يزال لدي اعتبار لنظم إدارة المحتوى، ووردبريس ضمن الخيارات.
سأكون مهتمًا جدًا بالبقاء على تواصل بشأن هذا!
نعم، هذا بالضبط ما كنت أحتاجه. شكرًا لك!
ولكن للعدالة، تعلمت php قبل أن يُطلق عليها هذا الاسم، ولم أواكب التطورات الحديثة التي أصبحت عليها اللغة، و احتياجاتي محددة جدًا (أحتاج إلى تحصيل الأموال، وتنفيذ إجراءات لإنشاء قطرة على Digital Ocean وتثبيت Discourse عليها).
لكن في المرات القليلة الماضية، قبلت مبلغًا بين 500 و1000 دولار لتنفيذ تعديلات على Discourse أو ووردبريس كنتُ متأكدًا أنها ستكون أموالًا سريعة وسهلة، فندمتُ. وفي آخر مرة، قضيتُ وقتًا طويلاً وأعدتُ المال للشخص. بالطبع، لو كانوا يقومون بأعمال سهلة، لربما لم يكونوا قد وظفوني. كما أن لدي عميلًا آخر لديه موقع ووردبريس يحتوي على آلاف الإضافات القديمة وغير القابلة للترقية. إنه كارثة، وقد تم اختراقه في مرحلة ما وأصبح يحتوي على روابط إباحية. من السهل تجنب ذلك.
من ناحية أخرى، استخدمتُ Gravity Forms بدلاً من WooCommerce خلال العام الماضي أو نحو ذلك، وكنتُ راضيًا جدًا عن استخدامه لتحصيل أموال الناس، سواء للمدفوعات لمرة واحدة أو الاشتراكات (رغم أنه غير متكامل مع Discourse). (لكنني لا أستطيع جعله يشغّل تثبيت Discourse في الوقت الذي أريده بالضبط!)
إذا كنتُ تقوم بأعمال “قياسية” وتلتزم بالإضافات المدعومة جيدًا، فمن المرجح أنك لن تندم (لكنني أنصح باستخدام discourse-subscriptions لإدارة، حسنًا، اشتراكات Discourse). ربع المواقع على الإنترنت يستخدم ووردبريس، وهناك سبب وجيه لذلك.
تحديث: يبدو أننا سنستخدم نظامين منفصلين لموقعنا الإلكتروني مقارنةً بمنتدى Discourse الخاص بنا. كان العامل الحاسم هو أن الأشخاص الذين يحتاجون إلى تحديث محتوى موقعنا هم في الغالب من غير التقنيين، لذا فإنهم يستفيدون بشكل كبير من استخدام نظام إدارة محتوى سهل الاستخدام للغاية. نحن نستخدم Weebly لتمكين الناس من تحديث المحتوى بسهولة، ولكن الأهم من ذلك، أننا ندفع مقابل منصة تتولى إدارة نظام التبرعات ونظام إدارة جهات الاتصال، والتي تأتي مع فريق تقني مخصص يمكننا ببساطة إرسال بريد إلكتروني إليه لإجراء تغييرات أكثر شمولاً مثل تغيير مظهر الموقع، أو الهيكل، أو تضمين العناصر، وما إلى ذلك. سيقومون بإدارة موقع Weebly لكنهم لن يديروا Discourse.
الآن بعد أن قررنا استخدام موقعين مختلفين، نحتاج إلى معرفة كيفية جعلهما متناسقين. سأوجه شكرًا خاصًا هنا إلى @angus، حيث تدعم شركته مجتمع PianoGroove، وقد قدمت أفضل تكامل رأيته حتى الآن (وقد رأيت الكثير!)
لقطة شاشة لموقع مجتمع PianoGroove
@angus أشكرك بصدق على العمل الرائع الذي تقوم به لعملائك وعلى كرمك في جعل الإضافات والمواضيع التي تنشئها مفتوحة المصدر. لا يزال أمامنا طريق طويل لنجعل موقعنا الإلكتروني وDiscourse يعملان لصالحنا، لكنني أجد مرارًا وتكرارًا أن العمل الذي تقوم به Pavilion هو بالضبط ما تحتاجه منظماتنا المفتوحة المصدر، الشعبية، والمجتمعية.
شكرًا لك @debryc 
أود أن أضيف أن الأمر لا يتعلق بي فقط، بل بجميع أعضاء Pavilion الذين يواصلون عملنا. إن تعاوننا هو جهد جماعي.
كما أود أن أضيف أننا قمنا للتو بفتح مصدر إضافة صفحات الهبوط الخاصة بنا، والتي تتيح صفحات مستقلة تمامًا مدعومة من مثيل Discourse؛ وهي طريقة أخرى لتلبية الحاجة التي نوقشت في هذا الموضوع. تفصل هذه الإضافة واجهة صفحات الواجهة الأمامية عن عميل Discourse (أي أنها لا تقوم بتحميل تطبيق Discourse)، مع السماح بالتكامل السهل عبر واجهة خلفية مشتركة (أي خادم Discourse).
نحن بالفعل نبدأ في استخدام هذه الإضافة مع بعض عملائنا لتلبية احتياجات مماثلة لتلك التي نوقشت هنا. كما ننظر في تطوير حزم مفتوحة المصدر عامة وسهلة الاستخدام للصفحات بناءً على حالات الاستخدام الشائعة لنظام إدارة محتوى مرتبط بمجتمع، يمكن استخدامها مع هذه الإضافة.
إليك قائمة حالات الاستخدام الحالية التي لدينا في الاعتبار لتلقي هذا المعاملة:
المدونة (أعمل حاليًا على هذه الحالة). قم بكتابة المحتوى في Discourse ثم عرضه في صفحة مدونة مستقلة تمامًا، يمكنك تخصيصها مثل مدونة حقيقية (أي مثل WordPress أو Ghost).
صفحات المنتجات أو الخدمات أو الميزات (مثل صفحاتنا). عرض المنتجات أو الخدمات أو الميزات التي قد تتضمن محتوى أو بيانات (فئات، وسوم، مواضيع، مستخدمين، إلخ) من مثيل Discourse الخاص بك.
صفحات “الفريق” (مثل صفحاتنا). صفحة لفريقك، تستخدم عضوية (وببيانات المستخدمين) من مجموعة مستخدمين في Discourse.
صفحات الفعاليات، لعرض وعرض بيانات الفعاليات من مثيل Discourse الخاص بك في صفحة هبوط للفعاليات ذات تصميم خاص. يمكن أن تكون “بيانات الفعاليات” هنا مزيجًا من بيانات إضافة تقويم Discourse، والفئات، والمواضيع، والمستخدمين (مثل الحضور المسبق)، والمواقع (باستخدام إضافة المواقع الخاصة بنا).
نحن مهتمون بحالات استخدام عامة أخرى يعتقد الناس أنها ستستفيد من هذا المعاملة. أود أن أشير الآن إلى أن هناك بعض حالات الاستخدام التي أخذناها في الاعتبار بالفعل والتي من غير المرجح أن تتلقى هذا المعاملة في هذه المرحلة:
المتجر. بينما قد تكون هناك صفحة تدمج عناصر من متجر، فإن المتاجر عبر الإنترنت تتطلب مجموعة واسعة من الوظائف التي ستحتاج دائمًا إلى حل مخصص مثل WooCommerce أو Shopify.
قاعدة المعرفة. هذه الحاجة مُلبَّاة بالفعل جيدًا بواسطة حلول مثل إضافة مستكشف المعرفة. قد تعرض صفحة هبوط مجموعة فرعية من قاعدة المعرفة، لكن تكرار وظائف شيء مثل إضافة مستكشف المعرفة (أو مجرد قوائم المواضيع في Discourse) بالكامل سيكون ضد المصلحة.
نحن أيضًا مهتمون بالتعاون مع أي شخص يريد تطوير مثل هذه الصفحات، سواء كمشروع تطوير في حد ذاته (مثل تحسين مهاراته)، أو لمجتمعه، أو حتى للبيع. نحن نخطط لإطلاق حزم مفتوحة المصدر مجانية خاصة بنا لكل حالة استخدام في الأجل المتوسط (4 إلى 6 أشهر).
إضافة صفحات الهبوط وصفحات Pavilion الخاصة ستكون دائمًا مفتوحة المصدر ومجانية بنسبة 100%. ومع ذلك، فإن هذا هيكل عام يمكن لأي شخص لديه معرفة بـ HTML و CSS استخدامه لتطوير “حزمة صفحات” إذا رغب في ذلك. سأضيف قريبًا “دليل المطور” إلى وثائق المعرفة لتلك الإضافة.
تدعم إضافة صفحات الهبوط بالفعل استضافة الصفحات في مستودعات خاصة بنفس الطريقة التي يعمل بها نظام سمة Discourse (في الواقع، في الخلفية فهي مبنية على نظام سمة Discourse وتمتد منه). هذا يعني أنه من الممكن بالفعل بيع الوصول إلى حزمة صفحات هبوط إذا أردت. قد يجعل ذلك الأمر يستحق العناء لمطوري آخرين لبناء مثل هذه الحزم.
لن يعالج هذا النهج جميع احتياجات إدارة المحتوى المرتبطة بمنتدى، لكنه يمكن أن يخدم مجموعة فرعية منها بشكل جيد جدًا، خاصة تلك التي نراها بانتظام مع المجتمعات الصغيرة والمستقلة، حيث سيؤدي إلى إزالة الحاجة إلى مثيلات منفصلة، وحاسمًا، الحاجة إلى مشاركة البيانات بين تلك المثيلات عبر بروتوكولات المصادقة (أي مشاركة بيانات المستخدم عند تسجيل الدخول)، أو الويب هوكس، أو طرق مشاركة البيانات الأخرى.
يمكن أن يقلل هذا من التكاليف والإدارة، خاصة للمجتمعات الصغيرة التي تسعى لإدارة محتوى محدود أو مستهدف، أو صفحات ثابتة، إلى جانب المنتدى الخاص بها. لن يكون أبدًا بديلاً مباشرًا لـ WordPress أو أنظمة إدارة المحتوى الأخرى، لكننا نأمل أن يجعله بعض حالات الاستخدام أسهل بشكل كبير.
نعم! وشكرًا لك!
لقد كنت أدير مجتمعًا قائمًا على Discourse لمدة 2.5 شهر فقط. ما واجهته هو الحاجة إلى أدوات معينة تتطلب تضمين سكريبت.
مثال على التقويم: توجد أدوات للتقويم أو الفعاليات يمكنني تضمينها في صفحة. ومع ذلك، هناك حاجة إلى سكريبت في عنصر ويجب تفعيله للصفحة.
بشكل عام لـ SAS: في كثير من الأحيان، ليست الـ iframe هي الحل المثالي. لا أريد أن يضطر أعضائي إلى الانتقال إلى موقع آخر للاشتراك، على سبيل المثال، لكن خدمة الاشتراك الخاصة بي ConvertBox تحتاج إلى سكريبت في وعنصر
بينما أسعى لتعزيز عروض مجتمعي، فإن الشيء الواضح جدًا هو أنه حتى “أحل” مشكلة إضافة التضمينات القائمة على السكريبتات بسهولة، أشعر أنني عالق إما مع ما تدعمه OneBox أو باستخدام الـ iFrames. في الواقع، يمكنني أن أحلم بالتقاعد عن موقع WordPress الخاص بي إذا كانت هناك وظائف محسنة للصفحات توفر التحكم في التضمين والتفعيل بهذه الطريقة.
لم أستطع كتابة الكود، لكنني أستطيع أن أتخيل نفسي أساهم ماليًا لدعم هذا النوع من التطوير لكي يستفيد منه المجتمع. شكرًا!
في الواقع، يمكن تضمين العناصر (Embeds) في واجهة مستخدم Discourse (مثلًا فوق قائمة المواضيع) باستخدام سمة معينة، وفي إضافة صفحات الهبوط. أما في الحالة الثانية، فقد أنشأت مثالًا باستخدام نسخة مصغرة من لعبة الديناصور. يمكنك لعبها هنا: Pavilion (متاح فقط على سطح المكتب).
لم يتطلب الأمر أي برمجة في هذه الحالة. كل ما فعلته هو رفع هذه الأصول إلى شبكة توزيع المحتوى (CDN) الخاصة بنا (سحب وإفلات المجلد إلى مساحة DigitalOcean)، ثم إنشاء صفحة بمسار “dinosaur” ونسخ ولصق كود HTML هذا (كلاهما تم عبر واجهة المستخدم الإدارية).
<div class="landing page dinosaur">
<div class="container">
<h1>لعبة الديناصور!</h1>
<canvas id="game" height="200" width="800"></canvas>
<p class="controls">اضغط على مفتاح المسافة للبدء</p>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/helpers.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/game-object.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/cactus.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/dinosaur.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/background.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/score.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/game.js"></script>
<script>
new Game({
el: document.getElementById("game")
});
window.onkeydown = function(e) {
return e.keyCode !== 32;
};
</script>
</div>
</div>
تطبق إضافة صفحات الهبوط إعدادات سياسة محتوى المتصفح (CSP) وإعدادات مشاركة الموارد عبر النطاقات (CORS) الخاصة بـ Discourse، والتي قمت بالفعل بإعدادها للتعامل مع السكريبتات من شبكة توزيع المحتوى الخاصة بنا (عبر إعدادات الموقع ذات الصلة).
سأقوم بنشر موضوع كامل في قاعدة المعرفة بعنوان “كيفية استضافة وتضمين الأصول” لتلك الإضافة لتغطية هذه الحالة الاستخدامية الأسبوع القادم.
