السياق: أقوم باستيراد منتدى vBulletin إلى Discourse.
أود إعداد أشياء مثل شبكة توصيل المحتوى (CDN)، والنسخ الاحتياطية عن بُعد، وما إلى ذلك قبل السماح للمستخدمين الحاليين بالوصول إلى محتوى المنتدى.
أفضل عدم تعيين المنتدى في وضع القراءة فقط، لأن ذلك سيُشعر المستخدمين بالإحباط بعد رؤية المحتوى مرة أخرى (مُحدَّث!) بعد بضعة أشهر، لكن دون أن يتمكنوا من التفاعل معه. في هذا السياق، إذا كان المحتوى متاحًا، فيجب أن يكون قابلاً للتفاعل أيضًا.
لذا، أحتاج ببساطة إلى جعل Discourse متاحًا للموظفين، مع عرض صفحة “صيانة” للمستخدمين الآخرين، حتى لو كان بإمكانهم نظريًا تسجيل الدخول، مع الحفاظ على قدرة موقعي الإلكتروني على التواصل مع خدمات مثل شبكة توصيل المحتوى (CDN) حتى أتمكن من إعدادها بشكل صحيح.
بحسب علمي، أسهل طريقة هي جعل الموقع يتطلب تسجيل الدخول، وتفعيل خيار «يجب الموافقة على المستخدمين»، وتوجيه بروتوكول SMTP إلى شيء مثل Mailhog. لا أتذكر ما إذا كان أداة الاستيراد توافق على المستخدمين تلقائيًا؛ وإذا كان الأمر كذلك، فيمكنك تنفيذ ما يلي في وحدة تحكم Rails:
approved_users = AdminUserIndexQuery.new(query: 'approved', stats: false).find_users_query
approved_users.each do |u|
u.approved = false
u.save!
end
ثم قم بإيقاف الموافقة عندما تكون جاهزًا.
بهذه الطريقة لن ترسل أي رسائل علنية أثناء عملية الهجرة، ويمكنك رؤية جميع الرسائل التي ولّدها Discourse في حال حدوث أي مشكلة.
ما لم تختار هجرة كلمات المرور، فسيعيد المستخدمون تعيين بيانات اعتمادهم على أي حال.
لكن سأخفي أزرار تسجيل الدخول مؤقتًا، وسأستبدل الجملة بعبارة مثل “قيد الإنشاء. ترقبوا المزيد!”
المستخدمون الذين سيحاولون تسجيل الدخول من /login لن يتمكنوا من ذلك على أي حال، لأن استيراد كلمات المرور لم ينجح وتم تعطيل البريد الإلكتروني للمستخدمين غير الموظفين، لذا لن يتمكنوا من تسجيل الدخول باستخدام البريد الإلكتروني أو إعادة تعيين كلمة المرور أيضًا.
أعتقد أن هذا الحل يمكن أن يحقق ما أحتاجه، أليس كذلك؟
