نقل منتدى XenForo إلى Discourse

في المنتدى الذي قمت بنقله، تم تثبيت xengallery ذات مرة، لذلك اضطررت إلى تغيير ما يلي، لأن الجدول xfgallery لم يعد موجودًا.

  def get_xf_sql(type, id)
    case type
    when :gallery
      return "SELECT NULL WHERE 1=0;"
    when :attachment
      <<-SQL
        SELECT a.attachment_id, a.data_id, d.filename, d.file_hash, d.user_id
        FROM #{TABLE_PREFIX}attachment AS a
        INNER JOIN #{TABLE_PREFIX}attachment_data d ON a.data_id = d.data_id
        WHERE attachment_id = #{id}
        AND content_type = 'post'
      SQL
    end
  end

يمكنك محاولة تشغيل البرنامج النصي مرة أخرى ومعرفة ما إذا كان سينتهي.

هل نظامك على قسم واحد؟

خطوة تثبيت mysql-server أصبحت قديمة. يجب تثبيت mariadb-server.

sudo apt-get install mariadb-server mariadb-client libmariadb-dev-compat libmariadb-dev

تمكنت من اتباع بقية الخطوات واستيراد قاعدة بيانات XF، لذا يجب على شخص ما تحديث الدليل.

أنا الآن عالق في الخطوة التالية وأحتاج إلى المساعدة.

echo "gem 'mysql2'" >>Gemfile
bundle install --no-deployment

يؤدي تشغيل ما سبق إلى ظهور الخطأ التالي. لقد تحققت من Gemfile ويحتوي فقط على هذا السطر الواحد - gem ‘mysql2’

لا يتضمن ملف Gemfile هذا مصدرًا عالميًا صريحًا.
قد يؤدي عدم استخدام مصدر عالمي صريح إلى إنشاء ملف قفل مختلف اعتمادًا على الأحجار الكريمة التي قمت بتثبيتها محليًا قبل تشغيل bundler.
بدلاً من ذلك، قم بتعريف مصدر عالمي في ملف Gemfile الخاص بك على النحو التالي: source "https://rubygems.org".
تعذر العثور على gem 'mysql2' في الأحجار الكريمة المثبتة محليًا.
root@ip-172-566-459-13-app:/#

حسنًا، لقد تمكنت من الانتقال إلى الخطوة التالية. نشر شخص ما أعلاه أننا بحاجة إلى أن نكون في مجلد /var/www/discourse على الحاوية ثم إضافة الجيم.

الآن في الخطوة النهائية

RAILS_ENV=production bundle exec ruby script/import_scripts/xenforo.rb

أتلقى هذا الخطأ. ما الذي يمكن أن أفعله بشكل خاطئ؟

`/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:63:in “rescue in new_client”: لم نتمكن من العثور على قاعدة بياناتك: discourse.
يمكن العثور على تكوينات قاعدة البيانات المتاحة في config/database.yml. (ActiveRecord::NoDatabaseError) لحل هذه المشكلة:

• هل لم تقم بإنشاء قاعدة البيانات، أو هل قمت بحذفها؟ لإنشاء قاعدة البيانات، قم بتشغيل:
  bin/rails db:create
• هل تغير اسم قاعدة البيانات؟ تحقق من أن config/database.yml يحتوي على اسم قاعدة البيانات الصحيح.`

تم الحل: كنت أقوم بتشغيل بصفتي المستخدم الجذر، واضطررت إلى التبديل إلى المستخدم ‘discourse’. بدأ الاستيراد.

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

ملاحظة:
في نص الترحيل البرمجي، أرى أنه لا يتم استيراد رسائل البريد الإلكتروني المكررة. ما هي الطرق المختلفة التي يتم بها تحديد التكرار؟ لاحظت أن xyz@gmail.com تُعامل بنفس طريقة xyz+1@gmail.com و xy.z@gmail.com

هل هناك أي نمط آخر أيضًا.

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

في الوقت الحاضر، أقوم دائمًا بعمليات الترحيل محليًا. كم عدد المشاركات لديك؟

2.5 مليون مشاركة.
سأحاول الترحيل المحلي على جهاز ماك M1 للمقارنة.

هذا هو كل شيء تقريبًا. يتم إجراء فحص التفرد على النسخة المحولة إلى أحرف صغيرة والمُطَبَّعة لعنوان البريد الإلكتروني المُعطى.

نقوم بالتطبيع عن طريق إزالة جميع النقاط وتجاهل كل شيء بعد علامة + في اسم المستخدم.

سرعة وحدة المعالجة المركزية الفردية هي العامل المهم.

على أجهزتي، معدل 800-1000 مستخدم أو منشورات/دقيقة هو أمر شائع إلى حد ما.

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

قم بإيقاف تشغيل إعداد الموقع Normalize emails (كان الإيقاف هو الافتراضي حتى وقت قريب). ربما يجب إيقاف تشغيله في هذه الوظيفة هنا:

يمكنك وضعه في نسختك المخصصة من البرنامج النصي لـ xenforo مع SiteSetting.normalize_emails=false. لست متأكدًا مما حدث لهؤلاء المستخدمين الذين لديهم رسائل بريد إلكتروني مكررة؛ هناك شيئان واضحان للقيام بهما، إعطاؤهم عنوان بريد إلكتروني وهمي أو تخطي استيرادهم. يبدو أنه يعطيهم عناوين وهمية؟ (وهناك فرصة جيدة جدًا لأنهم في الواقع مستخدمون وهميون على أي حال). إذا تخطاهم، فإن تشغيل البرنامج النصي مرة أخرى سيقوم باستيرادهم.

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

لقد مررت عبر رسائل البريد الإلكتروني التي تم تخطيها ويبدو أنه يقوم بعمل جيد في تجاهل تلك الحسابات. سأقوم بدمجها قبل الاستيراد النهائي. بالكاد 20 حالة من هذا القبيل.

لاحظ أنه عندما تقوم بالاستيراد النهائي، فإنه سيستورد فقط المستخدمين والمشاركات التي لم يتم استيرادها بالفعل، لذلك لن يستغرق الأمر وقتًا طويلاً.

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

هل هذه النسخ الاحتياطية والاستعادة على موقع Xenforo، أم لديك موقع Discourse مباشر ستقوم باستيراد بيانات Xenforo إليه؟

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

إذا كان لديك بالفعل بيانات على موقع Discourse الخاص بك تريد الاحتفاظ بها، فإن الأمور تكون أكثر تعقيدًا نظرًا لأنك ستحتاج إلى تجميد هذا الموقع، ثم الحصول على بيانات Xenforo والمتابعة كما هو موضح أعلاه.

سيكون تثبيتًا جديدًا لـ Discourse، مما يجعل الأمر سهلاً.

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

ما شرحته يزيل نقطة قلق كبيرة من تفكيري تمامًا، حيث كنت أعتقد أنني سأضطر إلى التعامل مع عمليات الاستيراد المجمعة أيضًا.

هل عاد الاستيراد باستعلام، هل يخرج البرنامج النصي للاستيراد أي سجلات؟ لقد توقف الاستيراد التجريبي الخاص بي عند 98.2٪ لبضع ساعات.

شيء آخر أدركته، إذا قمت بإعادة تشغيل الترحيل، فسيستغرق الأمر حوالي 30 ثانية لتجاوز دفعة من 1000 منشور. لذا فإن السرعة الفعالة هي الآن 2000 عنصر في الدقيقة. ليس تحسنًا كبيرًا مقارنة بـ 1000 منشور في الدقيقة للاستيراد الأول، حيث سيستغرق الأمر يومًا واحدًا حتى في آخر استيراد في يوم التبديل. 23 ساعة منها ستكون مجرد تخطي العناصر التي تم استيرادها بالفعل.

فقط ما تراه.

يجب عليك على الأرجح إيقافه وتشغيله مرة أخرى.

نعم، سيتخطى جميع البيانات التي تم استيرادها بالفعل. وهو يفعل ذلك أسرع بكثير من 2000 مشاركة/دقيقة. أشك في أنك سترى ذلك عندما تعيد تشغيله الآن.

هذا ما فعلته، لقد أعدت التشغيل ثم قمت بالنشر أعلاه. إنها 2000 مشاركة/دقيقة. للتأكد، جربتها مرة أخرى.

تمكنت من استيراد الصور الرمزية والمرفقات. نسخت هذه المجلدات.

/internal_data/attachments
/data/avatars

للإجابة على سؤالي، يتم الانتهاء من الصور الرمزية والمرفقات بمجرد استيرادها. إذا قام المستخدم بتغيير صورته الرمزية بعد استيراد معرفه، فلن يتم استيرادها/تحديثها لأن هذه المشاركة أو المستخدم سيتم تخطيها في التشغيل الثاني.

الآن أحتاج فقط إلى معرفة كيفية استيراد المحادثات (يمكن تخطيها أيضًا ولكن من الجيد الحصول عليها) وإعادة التوجيه الدائمة.

@Fajfi - شكرًا لك على مساهمتك في برنامج الاستيراد النصي. لقد عمل بشكل لا تشوبه شائبة مع الصور الرمزية والمرفقات. لا يزال قيد التشغيل ولم يصل إلى جزء الإعجابات بعد.

تم إصلاح استيراد المحادثات. تمكنت من استيراد أكثر من نصف مليون رسالة من XF2.3 إلى discourse. لقد رفعت طلب سحب (PR) في حال كان هناك شخص مهتم.

----تعديل----

تم رفع طلب سحب آخر مع إصلاح لاستيراد الإعجابات. من المدهش أنه لم يقم أحد بالترحيل من XF2.1+ إلى discourse حتى الآن. تمت إعادة تسمية الإعجابات إلى ردود فعل في عام 2019 عندما تم إصدار XF2.1.