In order to simplify our technology stack, I’m wondering if we shouldn’t be hosting a website and a forum separately, but rather reconfiguring Discourse to be both our website and our forum together.
I see this is how Pavilion by @angus uses Discourse.
Our website needs are more complicated, though! This is our current website.
I’d be curious to know if there are other Discourse only websites out there that I can explore. Or if you have any ideas for how this could be done.
well, it is possible to use publish pages for your non-posting content
Then use a header sub-menu plugin to give you a top menu with sub-menus or another plug-in to just give you a menu with no subs.
It all depends what your requirements are.
Yes! I think those are a great start.
One of our requirements would be around being able to embed things like our newsletter sign-up form and our donations form.
I also don’t know just how powerful custom styling is for page publishing. I’m wondering if there are examples out there of pages that do have much more stylized pages with things like content blocks with different backgrounds.
The question boils down to three things:
You can serve millions of pageviews from a $5 VPS running WordPress with the right caching and CDN in place. The equivalent Discourse instance would be much, much costlier.
If the majority of traffic and activity occurs within Discourse and there’s no risk of traffic surges to static pages, then hosting it all within Discourse might make sense. In other cases a proper CMS is still king.
15 posts were split to a new topic: SSL cert not working on main Discourse site
Discourse is Rails back-end and extenable so you can do anything a Rails app can do i thought, but are you looking for a silver bullet?
While it can certainly be done, and it may make sense for your organization, we at Discourse use different software for our main website.
Our main website is static HTML generated by https://jekyllrb.com/ and our blog is a simple WordPress instance.
It really depends on how your organization engineering is structured and what needs and priorities you have.
Thanks for that, Rafael.
I’m anxious to get WordPress out of my life. I was thinking that I"d go with a Discourse-only solution, but I’m now thinking that I’ll go with jekyll for the static/info stuff currently at www.literatecomputing.com and migrate just the money-getting parts to Discourse and the up-and-coming discourse-subscriptions plugin. I’m feverishly working on a Discourse plugin that will be a front end for my tools that do installations, upgrades, and other maintenance.
كطعام للتفكير، إليك موقعان إلكترونيان تم إنشاؤهما بالكامل باستخدام Discourse (الموقع الأول يستخدم إضافة Docuss، والتي أصبحت الآن غير مدعومة، بينما يستخدم الموقع الثاني إضافة DiscPage):
Thank you for this framework for making the decision!
I have to be honest and say I’m not sure what this means so I’ll now turn this over to our tech folx. 
@pfaffman Could you say more about this? What are the pain points that you have? I’m still considering CMSs and WordPress is up there.
I would be very interested in staying connected on this!
Yes, this is exactly what I needed. Thank you!
To be fair, I learned php before it was called that, and didn’t keep up with the more modern language that it is now, and my needs are very specific (I need to take money, and do stuff to make a Digital Ocean droplet get created and Discourse get installed on it).
But the last couple times I accepted $500-1000 to do some kind of Discourse/WordPress tweak that I was sure was going to be fast, easy money, I was sorry. And the most recent, I spent a bunch of time and gave back someone’s money. Of course, if they were doing easy stuff, they’d likely not have hired me. I’ve also got another client with a WordPress site with a zillion out of date and un-upgradable plugins. It’s a dumpster fire and somewhere along the way got hacked and has a bunch of porn links in it. Easy enough to avoid.
OTOH, I’ve been using Gravity Forms rather than WooCommerce for the past year or so and have been quite happy using that to take people’s money, both for one-time and subscription stuff (though not integrated with Discourse). (But I can’t get it to fire off the Discourse install exactly when I want it to!)
If you’re doing “standard” stuff and stick to well-supported plugins, you probably won’t be sorry (but I’d use discourse-subscriptions to handle, well, Discourse subscriptions). A quarter of the sites on the internet use WordPress and there’s a good reason for that.
تحديث: يبدو أننا سنستخدم نظامين منفصلين لموقعنا الإلكتروني مقارنةً بمنتدى 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، والتي قمت بالفعل بإعدادها للتعامل مع السكريبتات من شبكة توزيع المحتوى الخاصة بنا (عبر إعدادات الموقع ذات الصلة).
سأقوم بنشر موضوع كامل في قاعدة المعرفة بعنوان “كيفية استضافة وتضمين الأصول” لتلك الإضافة لتغطية هذه الحالة الاستخدامية الأسبوع القادم.
