تقييم ما قبل الترحيل لمنتدى Drupal 7 كبير

هجرة
1

مرحباً بالجميع، أنا أمتلك وأدير ما أعتقد أنه أحد أكبر المنتديات القائمة على Drupal على الإنترنت، حيث يصل عدد المشاركات إلى مليوني مشاركة. Drupal 7 يحتضر، و Drupal 8/9 يتحول إلى إطار عمل لمبرمجي الويب أكثر من كونه نظام إدارة محتوى جاهز للاستخدام. الإصدارات الجديدة من Drupal ببساطة لا توفر الوحدات النمطية الخارجية التي أحتاجها لكي يستمر منتدىي في وظائفه الأساسية، وبفضل متعة PHP والعديد من غرائب Drupal الأخرى، سيكون الترقية بنفس صعوبة الانتقال إلى منصة مختلفة تمامًا. لذلك سأضطر إلى تحمل العبء والانتقال إلى شيء آخر. أنا متأكد من أنه سيتعين عليّ اختيار Discourse نظرًا للجانب الفريد لأسلوب مجتمع منتدى الخاص بي: أنا المشرف الوحيد، وهذه ليست وظيفتي بدوام كامل. لذلك على مر السنين، استخدمت أطر عمل Rules و Flag المرنة في Drupal لإنشاء نظام مجزأ لإشراف المجتمع على البريد العشوائي والمشاركات المسيئة، مع إزالة المشاركات تلقائيًا و/أو إغلاق حسابات المستخدمين عند عتبات معينة بناءً على مدى حداثة المستخدم وعدد المستخدمين الذين قاموا بالإبلاغ عنها، مع الأخذ في الاعتبار أيضًا حداثة ونشاط الإبلاغ الأخير للمستخدمين الذين يبلغون عنها. بعبارة أخرى، إنه تقريبًا نفس ما تم تنفيذه في Discourse. يسعدني حقًا أن أرى أن Discourse قد أدرك قيمة الإشراف المجتمعي ونفذ نظامًا شاملاً ومدروسًا بهذه الطريقة جاهزًا للاستخدام. كان Drupal 7 ولا يزال نظام إدارة المحتوى الوحيد المرن بما يكفي للسماح بهذا النوع من الوظائف المخصصة دون أن تكون مطورًا ذا خبرة، وهو ما لست كذلك. لذلك يبدو أنني سأنتقل إلى Discourse. ومع ذلك لدي بعض المخاوف.

  1. نظام الإشراف المجتمعي: يقوم منتدانا حاليًا بتقييم تثبيت تجريبي لـ Discourse. أنا معجب بمدى شمولية النظام وتصميمه المدروس. لكن المجتمع لاحظ بعض الغرائب:
    • لا أحب حقًا كيف يخفي المشاركات التي تمت إزالتها تلقائيًا خلف “عرض المحتوى المتجاهل”. إذا كانت المشاركة سيئة بما يكفي لإزالتها من قبل المجتمع، فهي إما مسيئة للغاية أو بريد عشوائي بحت، ولا أريد أن يكون لدى الزوار أو المستخدمين خيار عرضها. هذا يمثل مشكلة خاصة في حالة المواضيع التي هي بريد عشوائي أو لها عنوان مسيء. ألن ترى زواحف محركات البحث المحتوى المخفي للبريد العشوائي؟ هل من الممكن تكوين مقدار الوقت دون تدخل المستخدم قبل أن يتم حذف مشاركة البريد العشوائي المخفية تلقائيًا بالكامل من العرض العام؟ وماذا عن المواضيع والمشاركات التي تم الإبلاغ عنها من قبل المجتمع على أنها غير مناسبة؟
    • قرأت هنا أن “ملاحظة: جميع القيم المذكورة أعلاه هي الإعدادات الافتراضية. يمكن للمسؤولين تغييرها في إعدادات الموقع” فيما يتعلق بالعتبات التي تؤدي إلى إزالة المشاركات و/أو إسكات المستخدمين، لكنني لا أرى تلك الإعدادات التفصيلية في نسختي التجريبية من Discourse. كل ما يمكنني العثور عليه هو “حساسية إخفاء المشاركة” و “حساسية إسكات المستخدم الجديد”، لكنني لا أفهم ما ترتبط به هذه الحساسية بالفعل من حيث المصطلحات الملموسة.
    • أود إزالة سبب “خارج الموضوع” للإبلاغ عن مشاركة. مجتمع منتدى الخاص بنا متساهل للغاية في هذا الصدد ولديه ثقافة منتدى حيث المشاركات الخارجة عن الموضوع شائعة جدًا ومقبولة. تحديث: يبدو أن هذا قد ينجح.
  2. ترحيل الرسائل الخاصة: يحتوي المنتدى الحالي على ما يقرب من مليون سلسلة رسائل خاصة باستخدام وحدة privatemsg الخاصة بـ Drupal 7، ولا يتعامل معها البرنامج النصي لترحيل Drupal → Discourse. يبدو هذا نقصًا كبيرًا، لأنه على الرغم من كونه وحدة نمطية خارجية (بالطريقة المعتادة لـ Drupal) إلا أنها في الأساس وظيفة المراسلة الخاصة الافتراضية التي يستخدمها مسؤولو Drupal 7.
  3. تحويل تنسيق المشاركات: للأسف، يستخدم المنتدى الحالي مزيجًا من مشاركات HTML الخالصة وتنسيق Textile. أفهم أن البرنامج النصي للترحيل يمكنه التعامل مع HTML الخالص (يرجى تصحيحي إذا كنت مخطئًا) ولكن ليس Textile. إذا أمكن، أود تحويل مشاركات Textile إلى HTML أو Markdown، أيهما أسهل. قيل لي أن Pandoc يمكن ربطه بالبرنامج النصي للترحيل، ولكنه سيزيد أيضًا بشكل كبير من وقت الترحيل. لقد بحثت عن وحدات Drupal لتحويل تنسيق المشاركات الحالية، لكنني وجدت فقط هذا، والذي لا يدعم المعالجة الدفعية لكمية هائلة من المشاركات، ولا يدعم نموذج “التعليقات” الخاص بـ Drupal، والذي يشكل الغالبية العظمى من “المشاركات” التي تحتاج إلى تحويل. لذلك فكرت في مجرد القيام بنوع من البحث/الاستبدال دون اتصال بالإنترنت على ملف تفريغ قاعدة البيانات باستخدام sed ، على غرار ما هو موصوف هنا. نرحب بالاقتراحات أو الحلول. أنا مستخدم Linux ذو خبرة وعملت بشكل متقطع مع التعبيرات العادية، لكنني ما زلت لست جيدًا فيها. تحرير: هذا خيار مثير للاهتمام للبحث/الاستبدال بمجرد وصول البيانات الأولية إلى Discourse.
  4. الإعلانات: يسعدني حقًا أن أرى أن المكون الإضافي للإعلانات لـ Discourse قد نضج كثيرًا منذ آخر مرة نظرت إليه. أفهم أن الإعلانات الداخلية ستسمح لي بوضع لافتات صور في أماكن محددة برابط مستهدف عند النقر عليها، وأنه إذا تم تعيين إعلانات متعددة لنفس المكان، فسيتم اختيارها عشوائيًا، صحيح؟ ومع ذلك، ليس لدي فكرة عن كيفية التعامل مع نموذج الهاتف المحمول. في منتدى الحالي، لدي لافتة أفقية علوية واحدة وثلاث لافتات عمودية في الشريط الجانبي الأيسر، ولن يكون أي منها ممكنًا لمستخدمي الهاتف المحمول في واجهة Discourse المتجاوبة. تحرير: قد أحتاج إلى تعديل المكون الإضافي للإعلانات لتلبية احتياجاتي، عرض مدفوع هنا.
  5. الروابط الدائمة: يحتوي مخطط عناوين URL الخاص بـ Drupal على مكونين رئيسيين: /node/XXXXXXX ، وروابط إلى تعليقات محددة داخل تلك العقد /comment/YYYYYYY#comment-YYYYYYY (YYYYYYY هو نفسه في كلا الحالتين). هل سيحافظ البرنامج النصي لترحيل Drupal 7 → Discourse تلقائيًا على هذه الروابط بحيث تظل الروابط في المشاركات إلى سلاسل أو مشاركات أخرى تعمل وتحافظ على تحسين محركات البحث؟ ماذا عن ملف sitemap.xml لمحركات البحث؟
  6. المعالجة الدفعية: أثناء الترحيل، هل سيعمل على دفعات؟ ماذا يحدث إذا واجه خطأ، بعد إصلاحه، هل سيستمر من حيث توقف أم سيتطلب البدء من البداية؟
  7. مستخدمو أجهزة Apple القديمة: بالطبع أفهم مخاطر استخدام المتصفحات القديمة. بالنسبة لأجهزة Windows وأجهزة Android القديمة، هناك دائمًا طريقة لتثبيت متصفح حديث متوافق مع Discourse. لكنني قلق بشأن أحد مستخدميّ الذي يدعي أن لديه جهاز Mac موديل 2015 لا يتلقى أي تحديثات وليس لديه طريقة لتثبيت أي شيء بخلاف الإصدار القديم من Safari الذي يعرض له إشعارات إهمال مع Discourse. أنا حقًا لا أعرف الكثير عن أجهزة Apple بخلاف حقيقة أنها مقيدة بشكل أكبر. هل من الصعب حقًا تثبيت متصفحات حديثة أخرى عليها؟
  8. تخزين الصور / التحميلات: يحب مستخدمي وأنا سهولة تحميل الصور في Discourse، لكنني قلق بعض الشيء بشأن مساحة التخزين والتكاليف. أفضل خيار على المدى الطويل سيكون على الأرجح ربط وحدة تخزين شبكة بـ VPS إذا لزم الأمر. إذا قمت بإعداد Discourse مبدئيًا بموقع التحميلات الافتراضي، فهل سيسبب مشاكل نقله إلى وحدة تخزين مختلفة لاحقًا؟
  9. النسخ الاحتياطي:
    • أتمنى لو كان هناك نظام للنسخ الاحتياطي التفاضلي، أو الأفضل من ذلك، النسخ الاحتياطي المكرر. أنا حاليًا أستخدم Duplicity مع Amazon S3 لمنتدى Drupal الخاص بي، والتكاليف منخفضة بشكل لا يصدق لتاريخ طويل من المراجعات. هل يعرف أي شخص على الفور متى بعد إنشاء أرشيف S3 يمكن لقاعدة أن تنتقل إلى Glacier؟
    • هل تسمح واجهة النسخ الاحتياطي لـ Discourse بحذف الأرشيفات في Amazon S3؟ أعرف أن هذا متطرف بعض الشيء، لكنني أرغب في تعطيل هذه الوظيفة، لأنني قمت بإعداد حاويات S3 الخاصة بي بأذونات PUT و GET و LIST فقط لمنع المتسلل على النظام المخترق من حذف النسخ الاحتياطية عن بُعد. ثم تطبق قاعدة دورة حياة S3 وتحذف الخوادم الأرشيفات القديمة بعد فترة زمنية معينة.
  10. المكون الإضافي Stop Forum Spam: لا أريد استخدام Akismet، لكنني حصلت دائمًا على نتائج جيدة مع StopForumSpam.com لمنع إنشاء الكثير من حسابات البريد العشوائي. هل يعرف أي شخص ما إذا كان المكون الإضافي لـ Discourse يحتوي على عتبات قابلة للتكوين لعدد الزيارات التي يجب أن يحصل عليها اسم مستخدم أو IP أو عنوان بريد إلكتروني في قاعدة البيانات ليتم رفضه؟ تحرير: لا، لا يفعل. تم طلبه هنا. أيضًا، للأسف، لا يتدخل لمنع إنشاء الحسابات فعليًا إذا كان لديهم عدد كافٍ من الزيارات في قاعدة بيانات SFS كما يفعل في Drupal.

آسف على المنشور الطويل. شكرًا مقدمًا للجميع على رؤاهم، وشكرًا جزيلاً لمشروع Discourse بأكمله على هذا المنتج الممتاز.

2

لقد صادفت للتو هذا:

تطبيق مجموعة من التحويلات المستندة إلى التعبيرات العادية، مثل استبدال علامات BBCode بـ Markdown

تم آخر تحديث له في عام 2016، ولست متأكدًا مما إذا كان لا يزال خيارًا ذا صلة.

هل هذا لا يزال ذا صلة؟ في نص استيراد Drupal، أرى شيئًا مثل:

 create_posts(results, total: total_count, offset: offset) do |row|
        topic_mapping = topic_lookup_from_imported_post_id("nid:#{row['nid']}")

 def create_permalinks
    puts '', 'creating permalinks...'

    Topic.listable_topics.find_each do |topic|
      begin
        tcf = topic.custom_fields
        if tcf && tcf['import_id']
          node_id = tcf['import_id'][/nid:(\d+)/, 1]
          slug = "/topic/#{node_id}"
          Permalink.create(url: slug, topic_id: topic.id)
        end
إعجاب واحد (1)
3

عادةً ما يقوم البرنامج النصي بسحب 1000 مشاركة في المرة الواحدة.

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

سأحتاج إلى إلقاء نظرة فاحصة لمعرفة ما إذا كانت المشاركات مدرجة في الروابط الدائمة. عادةً لا تكون كذلك، ولكن يمكن القيام بذلك.

ستحتاج إلى جميع تحميلاتك على S3، لذا سيتضمن النسخ الاحتياطي الخاص بك تفريغ قاعدة البيانات فقط. لا يمكنك فعل أي شيء لتحسين ذلك حقًا. يمكنك إما السماح لـ Discourse بالاحتفاظ بعدد معين أو إخباره بعدم القيام بذلك (أو فقط تعيين عدد النسخ الاحتياطية إلى رقم كبير) والسماح لقواعدك بالتعامل معها.

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

أوه، هذه نقطة جيدة جدًا. الآن بعد أن فكرت في الأمر، سأُحاسب على كل حال مقابل تخزين التحميلات على S3، سواء ذهبت التحميلات مباشرة (وفقط) إلى S3، أو سواء كانت داخل ملفات tar متعددة من النسخ الاحتياطي لـ Discourse.

وماذا عن استخدام حاوية بدون أذونات حذف للنسخ الاحتياطية لـ Discourse؟

5

ولكن إذا كانت على S3 فلديك نسخة واحدة فقط.

أشك في أن الأمر سينجح إذا لم يكن لدى Discourse الإذن بالحذف، على الرغم من أنني لا أعرف.

6

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

7

نعم، يمكنك تفعيل نظام الإصدارات حتى لا يتم حذف الملفات عند تمييزها على أنها محذوفة. إذا كنت لا تهتم بالمساحة التي تدفع مقابلها، يمكنك فعل ذلك. عندما يحذف Discourse ملفًا لأنه لم يعد مستخدمًا، فإنه ينقله إلى مجلد “tombstone” لفترة قبل حذفه. أوصي بأن تثق في Discourse لإدارة الملفات. لا أعرف ما إذا كان منع الوصول إلى الحذف سيؤدي إلى كسر أي شيء.

يمكنك وضع النسخ الاحتياطية في “bucket” منفصل بأذونات مختلفة (ولكن بنفس بيانات الاعتماد) إذا أردت.

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

سؤال لـ @pfaffman أو أي شخص آخر يقوم بتحميلات على S3 – أعرف أنه يعتمد على مليون عامل، ولكن هل لديك على الأقل معلومات قصصية عن رسوم النطاق الترددي وطلبات S3 لمنتدى متوسط ​​إلى كبير مع تحميلاته على S3؟ شكراً جزيلاً!

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

تحديث صغير هنا: ما أعتقد أنني سأفعله هو الاحتفاظ بتحميلاتي محليًا؛ يجب أن يكون لدي مساحة تخزين محلية كافية في الوقت الحالي وخيار توسيعها بوحدات تخزين إضافية إذا لزم الأمر. أنا فقط لا أريد التعامل مع تعقيد وتكلفة شبكة توصيل المحتوى (CDN) والرسوم غير المتوقعة لتخزين الكائنات وفوق كل ذلك تكاليف النقل لخدمة صور موقع الويب المباشر. ثم سأقوم بعمل نسخ احتياطية تلقائية من S3 إلى Backblaze B2 بما في ذلك التحميلات وخيار s3 disable cleanup. تسعير Backblaze رخيص جدًا بحيث لا ينبغي أن تكون مشكلة الاحتفاظ ببضعة أسابيع من النسخ الاحتياطية اليومية حتى مع التحميلات المتكررة. اتضح أن Backblaze B2 لديه خياران بسيطان للحاويات وهما ما أحتاجه بالضبط: 1) قواعد دورة حياة تلقائية لحذف الملفات بعد X يومًا، و 2) منع حذف أو تعديل الملفات لمدة N يومًا (لمنع الاحتمال الصغير لاختراق الخادم واستخدام المخترق للاعتمادات المخزنة لحذف النسخ الاحتياطية عن بُعد). لقد اختبرت هذا ويبدو أنه يعمل بشكل جيد؛ حاولت حذف أرشيف نسخ احتياطي من واجهة مستخدم Discourse كان محظورًا من الحذف بواسطة Backblaze، ولم يفعل شيئًا ببساطة.

فقط للتوضيح لي وللآخرين: هل من الممكن عمل نسخة احتياطية تلقائية للتحميلات على التخزين المحلي إلى S3 إذا تم تمكين خيار backup with uploads (افتراضي)، أليس كذلك؟

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

نعم. افتراضيًا، يتم تضمين التحميلات المحلية في ملف النسخ الاحتياطي.

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