تقسيم موقع إلى جزأين

لدي موقع، lists.tssi.com. وهو يدعم حاليًا مجتمعين مستقلين تمامًا من Discourse (تم ترحيلهما من Mailman)، يتم التعامل معهما باستخدام المجموعات والفئات. لنطلق عليهما x و y.

أريد تقسيمهما بحيث يصبح المجموعتان مستقلتين تمامًا. (نعم، هذا يعني المزيد من العمل بالنسبة لي، لكنني موافق على ذلك.) السبب الرئيسي للقيام بذلك هو أنني أريد فتح كلا المجتمعين للقراءة من قبل غير الأعضاء، لكنني أعتقد أن هذا سيكون أسهل إذا كانا مستقلين تمامًا. لا أعتقد أن الأشخاص في مجتمع X يريدون قراءة الكثير عما يحدث في مجتمع Y، على الرغم من أنهما متشابهان. (كلاهما موقعان موجهان نحو الرياضات الجامعية.)

إحدى الطرق للقيام بذلك هي تعريف المواقع كـ x.tssi.com و y.tssi.com وطريقة أخرى هي تعريف المواقع كـ x.lists.tssi.com و y.lists.tssi.com.

في كلتا الحالتين، سيعمل lists.tssi.com كبوابة للمجتمعين، مع واجهة أمامية مشتركة في Nginx.

على حد علمي، يجب أن تعمل كلتا الطريقتين في حاوية واحدة، مع استنساخ قاعدة البيانات بحيث تكون مستقلة تمامًا. (لقد قمت بإعداد خادم الاختبار الخاص بي باستخدام طريقة x.tssi.com و y.tssi.com، لذلك أنا متأكد من أن هذا يعمل، أنا أقل تأكدًا من نهج x.lists.tssi.com و y.lists.tssi.com، على الرغم من أنني أعتقد أن هذا قد يكون أسهل لمستخدمي لفهمه وسيدعم بشكل أفضل المجتمعات الإضافية التي قد تتم إضافتها.)

بمجرد تقسيمهما، سيتم حذف المستخدمين الذين هم جزء من مجتمع واحد من قاعدة بيانات المجتمع الآخر أو تعيينهم كغير نشطين. قد أقوم أيضًا بحذف جميع منشورات وفئات الموقع الأخرى.

أي توصيات بشأن الطريقة التي يجب اتباعها؟ أي مشاكل يجب أن أكون على علم بها؟

إعجاب واحد (1)

لماذا لا يتم الاحتفاظ بموقع مركزي به مستخدمون ولكن بدون محتوى يخدم Discourse Connect (تسجيل الدخول الموحد) للموقعين الفرعيين؟

ربما تحتفظ بالموقع المركزي مع جميع المستخدمين لديك، وتأخذ نسختين أخريين كاملتين كـ x و y، وتحذف المحتوى الذي لا تريده من كليهما لإنشاء التقسيم، وتجعلهما يشيران إلى الموقع “الرئيسي” لتسجيل الدخول.

سيؤدي ذلك أيضًا إلى القضاء على ارتباك تسجيل الدخول للمستخدمين الذين قد يكونون في كلتا القائمتين.

إعجاب واحد (1)

ما هي فوائد بيئة تسجيل الدخول الموحد (SSO) مثل هذه؟ وما هي عيوبها؟

لا أعتقد أن هناك أي مستخدمين في كلتا القائمتين بخلافي. لقد كانت مواقع Mailman منفصلة لسنوات عديدة، ولا يزال معظم المستخدمين يعتمدون بشكل أساسي على البريد الإلكتروني.

حتى الحاجة إلى وجود عناوين بريد إلكتروني منفصلة للنشر عبر البريد الإلكتروني لكل فئة داخل هذا المجتمع مربكة للبعض منهم، لكنني لا أرى طريقة لتجنب ذلك. أنا أشجعهم على استخدام واجهة الويب، ولكن ربما 5٪ يفعلون ذلك، بعد 3 أشهر من التغيير.

هدفي هو توسيع المشاركة من خلال جعل كلا المجتمعين قابلين للبحث والقراءة على الويب. يبدو لي أن إبقائهما منفصلين قد يكون أفضل لجذب أولئك الذين يرغبون في مناقشة الفريق X ولكن ليس الفريق Y.

لست في عجلة من أمري، فالصيف هو الوقت البطيء لقائمة موجهة نحو رياضات الكلية، وستبدأ الأمور في الازدياد في أغسطس عندما تبدأ تدريبات كرة القدم الخريفية. لذلك لدي وقت للتفكير في النهج الأفضل للمجتمعات.

قررت استخدام lists.tssi.com للموقع البوابة و x.tssi.com و y.tssi.com للمجتمعات المنفصلة بدلاً من x.lists.tssi.com و y.lists.tssi.com. لم أتمكن من جعل الخيار الأخير يعمل، ربما بسبب مشكلة في إعداد nginx، حيث استمر في إعادة توجيه الطلبات لـ x.lists.tssi.com أو y.lists.tssi.com إلى lists.tssi.com بدلاً من خادم Discourse.

لكن يمكنني جعل الخيار الآخر يعمل، والحل العامل أفضل من الحل غير العامل. :slight_smile: