أنا أستكشف إمكانية إنشاء منتدى مشترك لموقعين منفصلين، مدونتي ومحفظة أعمالي. يتمثل المفهوم في وجود قاعدة بيانات منتدى واحدة تخدم كلا الموقعين، مما يسمح بمشاركة المستخدمين والمواضيع عبر المجتمعين. ومع ذلك، أود أن يتم تنسيق المنتدى بشكل مختلف اعتمادًا على الموقع الذي يزوره المستخدم، بحيث يشعر كل مجتمع بالتميز مع كونه جزءًا من مساحة مشتركة أكبر.
لدي خلفية في تطوير الويب، على الرغم من أنني لم أعمل على مشروع كبير كهذا منذ فترة. أنا على استعداد للتعمق مرة أخرى وتعلم ما هو مطلوب لجعل هذا يعمل، ولكني أقدر التوجيه حول ما إذا كان هذا ممكنًا مع Discourse.
على وجه التحديد، أتساءل:
هل يمكن لـ Discourse دعم سمات أو أنماط مميزة بناءً على النطاق أو عنوان URL المرجعي؟
هل من الممكن تكوين Discourse لعرض علامات تجارية مخصصة (شعارات، ألوان، إلخ) مع الحفاظ على قاعدة بيانات مستخدمين مشتركة ومجموعة مواضيع مشتركة؟
هل هناك إضافات أو ملحقات قد تجعل تنفيذ هذا أسهل؟
أي نصائح حول التحديات أو القيود التي يجب أن أضعها في اعتباري عند متابعة هذا النوع من الإعداد؟
لا يزال هذا المشروع في مرحلة المفهوم، وأخطط للبدء في البناء نحو نهاية العام. أريد التأكد من أن Discourse هو المنصة المناسبة لهذه الرؤية قبل الالتزام.
شكرًا مقدمًا على أي رؤى أو اقتراحات أو موارد يمكنك تقديمها!
لست متأكدًا بعد.
إذن النطاق أ يشير إلى المنتدى، والنطاق ب يشير إلى نفس المنتدى/منتدى مختلف بنفس قاعدة البيانات؟ إذا كان الأمر كذلك، فربما منتدى مختلف بنفس قاعدة البيانات؟ عندها يمكن أن يكون النمط مختلفًا.
بالبحث السريع هنا لست متأكدًا مما إذا كان يمكن القيام بذلك بسهولة.
ربما يكون المسار الأسهل هو استخدام تبديل مرتبط بالمجموعة الأساسية ووجود مجموعتين يقوم التبديل من المجموعة أ إلى المجموعة ب بتبديل السمات وربما استخدام شيء مثل Theme component الصفحة الرئيسية المخصصة للمجموعات؟ أو ربما استخدام فئات حديثة + مربعات مجموعات مثبتة مرتين (مستخدمة في سمة الهواء) مع تخصيصات بناءً على السمة / المجموعة الأساسية
بينما لا أعرف بنفسي. أتساءل عما إذا كان وجود تثبيتتين لـ discourse قد يخاطر بإتلاف قاعدة البيانات؟ على الرغم من أن البعض لديه مواقع تجريبية، ولكن أعتقد أن الموقع التجريبي يتم نسخه احتياطيًا من الموقع الرئيسي بشكل روتيني؟
إذًا، إذا فتح مستخدم الموقع أ، وانتقل إلى المنتدى من الموقع أ، فسيتم تطبيق السمة أ.\n\nثم يفتح نفس المستخدم الموقع ب، وينتقل إلى المنتدى من الموقع ب، ويرى السمة ب؟\n\nماذا لو كانت السمة أ مطبقة على المستخدم، وفتح الموقع ب، وقام بتحديث صفحة المنتدى؟ هل سيتم تطبيق السمة ب، أم ستبقى السمة أ؟
تخميني هو أنه يمكنك تشغيل محركات متعددة (تثبيتات Discourse) فوق نفس قاعدة البيانات (لذا تحتاج إلى قاعدة بيانات منفصلة). سأقوم بتشغيل جانب واحد فقط، على الرغم من ذلك. بخلاف ذلك، سيبدأ اثنان منهما في التنافس على الوظائف. بخلاف ذلك، أعتقد أن Discourse هو تطبيق عديم الحالة، لذلك لا ينبغي أن يهم عددها الذي تقوم بتشغيله.
الآن سؤال لجذر المشكلة بأكملها: لماذا؟ وهل هذا ليس ضد قواعد تحسين محركات البحث (SEO)؟ أعتقد أن جوجل لم يعجبه إذا وجد نفس المحتوى على مواقع متعددة.
في الواقع، قد لا تعمل بعض الأشياء كما هو متوقع - على سبيل المثال، تحديثات واجهة المستخدم في الوقت الفعلي (إذا قام شخص ما بتحديث مقال بحيث يتم إعادة عرضه بشكل سحري أثناء قراءتك). أعتقد أن الموقعين لن يخبرا بعضهما البعض، لذا ستحتاج إلى الاعتماد على المستخدم لتحديث متصفحه. قد يكون هناك المزيد. مثل إذا قمت بتغيير إعدادات الموقع على موقع واحد، أعتقد أن الموقع الآخر لن يلاحظ أيضًا وقد تحتاج إلى إعادة تشغيل الآخر.
بناءً على Scaling up and sidekiq يبدو لي أن هذا قابل للحل بالفعل. يبدو أن Sidekiq يتعامل مع الأمر، والباقي سيكون مسألة تكوين Redis بشكل صحيح.
هذا خارج الموضوع قليلاً، ولا أريد أن أحيد عن المحادثة، لكنني أود أن أضيف تقديري البسيط.
أعتقد أننا في عصر الإنترنت حيث يحتاج المرء إلى التفكير في تحسين محركات البحث (SEO) أو مستخدميه.
وليس لدي شك في أن من يختارون مستخدميهم سيستخدمون منصة Discourse المستضافة ذاتيًا.
كنت أبحث عن هذه الميزة لأن لدي مشاريع شخصية بنفس الجمهور والهدف. كانت “المواقع المتعددة مع تسجيل الدخول الأحادي (SSO)” هي الأقرب، لكنني لم أصل إلى نتيجة لأنها بطيئة وغير مريحة.
Discourse ليس عديم الحالة، وجميع المعلومات موجودة في قاعدة البيانات. لذلك إذا قمت بتشغيل مثيلات متعددة فوق قاعدة بيانات واحدة، فستبدو تلقائيًا متماثلة وستنعكس التغييرات في إحداها على الفور في الأخرى.
سيكون هذا “مجرد” مسألة تبديل السمات. ربما الاستفادة من منطق معاينة السمة الحالي وجعل المكون الإضافي ينظر فقط إلى اسم المضيف بدلاً من معلمة عنوان URL.
قد يكون استضافة نفس المنتدى تحت عنوانين URL هو الجزء الأصعب هنا، خاصة فيما يتعلق بتحسين محركات البحث (SEO). سيؤدي ذلك إلى الوقوع في كل أنواع المحتوى المكرر ومشاكل عنوان URL الأساسي.
هل يمكنك توضيح ذلك؟ سيكون من المثير للاهتمام معرفة المزيد عن كيفية عمل ذلك. أعتقد أن جملتيك متعارضتان؟ أعتقد أن عكس كل شيء هو ما طلبه OP بالفعل. ولكن كيف يمكن أن يحدث ذلك إذا لم يتم إخطار المثيل الآخر بالتغيير الذي تم إجراؤه بواسطة المثيل الأول؟ إنه مخزن في قاعدة البيانات، نعم، ولكن لا يوجد إخطار.
إذن، مجرد قاعدة بيانات = عديمة الحالة (stateless). في كل مرة تقوم فيها بطلب، فإنها تسأل قاعدة البيانات مرة أخرى - لا توجد حالة في الذاكرة. أم أنها موجودة؟
بخلاف ذلك، أنا حقًا أحب فكرة المكون الإضافي. أتفق على أن هذه ستكون الطريقة الصحيحة للذهاب، وما زلت أعتقد أن تحسين محركات البحث (SEO) ليس شيئًا تختاره ولكن يجب عليك القيام به بطريقة ما للحصول على جمهور. سيكون التكرار طريقة لقطعه بالفعل. حتى من وجهة نظر المستخدم، قد يكون الأمر مريبًا إذا رأيت شيئًا كتبته على موقع ما وربما تم ربطه بموقع آخر لم يكن لدي أي فكرة عنه، فسأكون مضطربًا حقًا. يعد تكرار المحتوى عادةً طريقة تستخدمها المواقع ذات الجودة المنخفضة. لهذا السبب تحصل على خفض في ترتيب محركات البحث (SEO). ولكن سيكون هذا موضوعًا لفئة Community.
أعتقد أننا في حالة ارتباك في التعريفات هنا. كود Discourse من جانب الخادم (نوعًا ما*) عديم الحالة ولكن مثيل Discourse بأكمله (عميل الويب، كود جانب الخادم، Redis، الملفات المخزنة مؤقتًا، قاعدة البيانات) ليس كذلك.
الجانب الآخر من تلك العملة هو - نظرًا لأن كود جانب الخادم عديم الحالة - لا يمكن لهذا الإعداد تحقيق ما يريده OP، حيث لا يوجد مكان لتخزين المعلومات التي يجب تقديم عنوان URL والسمة. الإعداد الذي تصفه هو في الواقع ما يحدث في إعداد موازنة التحميل حيث توجد حاويات ويب متعددة وقاعدة بيانات / مثيل Redis واحد. إنه موقع واحد.
* أقول “نوعًا ما” لأن هناك الكثير من طبقات التخزين المؤقت في أماكن مختلفة
حسناً. هل عنوان URL للموقع الرئيسي مخزن في قاعدة البيانات أيضاً؟ لذا فهو ليس مسألة تكوين مثيل محلي؟ في هذه الحالة سيكون واضحاً أن كلا المثيلين سيحاولان تقديم نفس الشيء.
وأنت على حق في أن إعداد الخادمين لا يزال لا يساعد Discourse على اختيار السمة الصحيحة على الإطلاق.
مشكلة أخرى يمكن أن تكون رسائل البريد الإلكتروني؟ من أي نطاق ستأتي رسائل البريد الإلكتروني للإشعارات؟ مشكلة أخرى - الإضافات الاجتماعية (فيسبوك وما إلى ذلك) أو تسجيل الدخول عبر جوجل سيعيد التوجيه إلى موقع خاطئ (أو ربما يرفض تسجيل الدخول).
