نقل منتدى vBulletin 4 إلى Discourse

نعم، يتم تحويلها. سأراسلك بالبريد الإلكتروني غدًا!

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

مرحبًا، أنا أعمل على حاوية Docker (DigitalOcean) وأحاول استيراد mybb (أعلم أن هذا الدليل مخصص لـ Vbulletin، لكن أمر Gemfile مشابه). لقد علقت في عملية bundle install:

mybb1229×386 68 KB

مرحبًا،
لقد حاولنا استيراد vBulletin v3.8 إلى Discourse. يعمل هذا السكربت بشكل جيد مع قاعدة بيانات بحجم 300 ميجابايت، تحتوي على حوالي 40 ألف مستخدم و60 ألف منشور. لكن في نهاية عملية الاستيراد واجهنا مشكلة تتعلق بمجموعة الأحرف (charset).

• كانت بيانات vBulletin 3.8 مشفرة بمجموعة الأحرف: latin1
  ----> عند تشغيل سكربت الاستيراد، كان خادم MySQL 5.6 داخل حاوية Discourse مهيأً أيضًا بمجموعة الأحرف UTF-8.
• يقوم سكربت الاستيراد بإجبار عملية التحويل على تحويل البيانات إلى UTF-8.
  لذلك، في نهاية عملية الاستيراد، تظهر بيانات منتدى Discourse مع أخطاء في تشفير UTF-8. يبدو الأمر كما هو موضح في الصورة أدناه.

1. قبل الاستيراد، vB 3.8

2. بعد الاستيراد إلى Discourse
   

   

   image581×583 20.9 KB

لقد جربنا ما يلي:

• تحويل مجموعة الأحرف في vB 3.8 إلى UTF-8 قبل تشغيل سكربت الاستيراد.
• اختبار قاعدة بيانات vB 3.8 هذه على خادم MySQL جديد، حيث ظهرت النصوص بشكل طبيعي دون حدوث أخطاء في الترميز.
  لذا، هل يمكنكم تقديم أي نصيحة في هذه الحالة؟

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

إليك جزء من كيفية حلّ مشكلة مماثلة:

    ### ترميز WIN1252
    win_encoded = ''
    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nفشل Win1252 لـ \n\n#{raw}\n\n"
      win_encoded = ''
    end
    raw = win_encoded

لقد أنقذت حياتي.
بالنسبة للطريقة السهلة، جربت سكريبت التحويل في المنشور https://meta.discourse.org/t/importing-from-phpbb3/30810/540، وساعدتني في إصلاح مشكلة ترميز قاعدة البيانات بسرعة، والآن يعمل كل شيء بسلاسة.
شكرًا جزيلاً لك على النصيحة.

هل قام أي شخص بالهجرة باستخدام مستورد vBulletin 5؟ قد أستخدمه في المستقبل، وأود معرفة ما إذا كان قد تم استخدامه بنجاح دون أي أخطاء من قبل.

لقد قمت للتو باستيراد vBulletin5 وأضفت بعض الميزات (روابط دائمة، بعض التنسيق، وربما بعض الأمور الأخرى التي لا أتذكرها). أعتزم تقديم طلب دمج (PR)، لكنه لم يحدث بعد.

لديك نسخة احتياطية لقاعدة بيانات VB5 تحتوي على مرفقات. هل يمكنني استيرادها في Discourse أم أنني بحاجة إلى أن تكون جميع المرفقات كـ ملفات؟

أنا أيضًا مرتبك بشأن هذا. أين يجب أن أنسخ ملفات المرفقات بالضبط في مجلد Discourse؟

مرحباً مرة أخرى،
من فهمي، ستعمل المرفقات من قاعدة البيانات لأنها تُعالج بنفس الطريقة التي تُعالج بها الصور الرمزية (الأفاتار) الموجودة أيضاً في قاعدة البيانات.

تسير عملية الاستيراد بشكل جيد، لكنني واجهت خطأ عند 91% من المنشورات المستوردة

importing posts...
  1425149 / 1564573 ( 91.1%)  [1040 items/min]  Traceback (most recent call last):
        14: from script/import_scripts/vbulletin5.rb:726:in `<main>'
        13: from /home/canapin/discourse/script/import_scripts/base.rb:47:in `perform'
        12: from script/import_scripts/vbulletin5.rb:49:in `execute'
        11: from script/import_scripts/vbulletin5.rb:300:in `import_posts'
        10: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `batches'
         9: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `loop'
         8: from /home/canapin/discourse/script/import_scripts/base.rb:863:in `block in batches'
         7: from script/import_scripts/vbulletin5.rb:320:in `block in import_posts'
         6: from /home/canapin/discourse/script/import_scripts/base.rb:508:in `create_posts'
         5: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
         4: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
         3: from /home/canapin/discourse/script/import_scripts/base.rb:509:in `block in create_posts'
         2: from script/import_scripts/vbulletin5.rb:321:in `block (2 levels) in import_posts'
         1: from script/import_scripts/vbulletin5.rb:450:in `preprocess_post_raw'
script/import_scripts/vbulletin5.rb:450:in `gsub': invalid byte sequence in UTF-8 (ArgumentError)

كيف يمكنني تحديد المنشور بشكل صحيح لرؤية محتوى كما هو في قاعدة بيانات vbulletin؟

اقترح شخص ما استخدام rescue لحل هذه المشكلات، لذا قد تحتاج إلى العودة وإيجاد ذلك (لا أتذكر ما إذا كان في هذا الموضوع أو موضوع آخر). يمكنك إضافة put داخل rescue لطباعة id و/أو النص الذي تسبب في المشكلة.

لديك مشكلة في الترميز.

استخدمت هذا في استيراد مشابه (أعتقد أنك ستضعه في preprocess_post_raw)

    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
      win_encoded = ''
    end

مرحبًا،
لقد عدلت برنامج الاستيراد وأضفت سكريبتك على النحو التالي:

  def preprocess_post_raw(raw)
    return "" if raw.blank?
    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
      win_encoded = ''
    end
    # decode HTML entities
    raw = @htmlentities.decode(raw)

    # fix whitespaces
    raw = raw.gsub(/(\\r)?\\n/, "\n")
      .gsub("\\t", "\t")

تحدث تسلسل بايت غير صالح في UTF-8 في هذا الجزء: raw = raw.gsub(/(\\r)?\\n/, "\n") .gsub("\\t", "\t").

ثم重新启动ت برنامج الاستيراد. على الرغم من أنه يتجاوز البيانات التي يتم استيرادها بالفعل، فقد استغرق حوالي 6 ساعات للوصول إلى المنشور الذي يولد خطأ، ولم تتم إضافة المعلومات المتوقعة لعرض محتوى المنشور. هل لديك أي فكرة عن السبب؟

تعديل:

هذا على الأرجح هو محتوى المنشور الخام الذي يؤدي إلى الخطأ:

I wonder if Billy is enjoying the parade.

Qwertyuiopasdfghjklzxcvbnm��

سأحاول تعديل سكريبت برنامج الاستيراد لجعله يتخطى (بشكل حقيقي) المنشورات السابقة البالغ عددها 1.4 مليون. حظًا سعيدًا لي.

لقد قمت بتعديل العديد من أدوات الاستيراد الأخرى لتشمل إعداد import_after للسماح باستيراد البيانات الحديثة فقط. يمكنك الاطلاع على بعض الأدوات الأخرى لمعرفة كيفية تنفيذ ذلك.

مرحباً،
تمكنت من استيراد معظم منشوراتي! أصلحت بضعة عشرات يدوياً وأعدت تشغيل عملية الاستيراد في كل مرة واجهت فيها خطأ UTF-8 جديد…

الآن، أحتاج إلى استيراد المرفقات (المخزنة في قاعدة بيانات VBulletin)، لكن العملية لا تعمل:
عند بدء العملية، يزداد استهلاك الذاكرة العشوائية (RAM) بشكل كبير خلال 10 أو 20 ثانية، ثم يحدث هذا الخطأ:

importing attachments...
Failed to create upload: Cannot allocate memory - grep
Fail

ذاكرة الذاكرة العشوائية الخاصة بي:

image505×113 3.89 KB

أستخدم إصدار تطوير من Discourse على نظام فرعي Ubuntu 18 ضمن Windows 10، ولدي 16 جيجابايت من الذاكرة العشوائية.

تشغل المرفقات 7 جيجابايت من أصل 13 جيجابايت في قاعدة بيانات vBulletin.
لاحظ أنني أستخدم مُستورد vbulletin5.

المشكلة ناتجة عن هذا الاستعلام:

    SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
      FROM #{DB_PREFIX}attach a
      LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
      LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid

عند تنفيذ هذا الاستعلام في MySQL، تمتلئ الذاكرة العشوائية المتبقية خلال ثوانٍ.

(تعديل مشاركتي لإزالة المعلومات والأسئلة غير الضرورية حيث أنني أكتشف الأمور وأوفر حلاً بديلاً)

الحل البديل:

أضفت حدًا (limit) وإزاحة (offset) إلى استعلام SQL الخاص بالمستورد. قمت باستيراد المرفقات عن طريق اختيار 20000 منها في كل مرة:

    uploads = mysql_query <<-SQL
    SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
      FROM #{DB_PREFIX}attach a
      LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
      LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid
      LIMIT 20000 OFFSET 0
    SQL

أضفت أيضاً أمر exit في نهاية حلقة uploads.each do |upload| لمنع سكريبت الاستيراد من الاستمرار في القيام بأشياء أخرى بعد استيراد 20000 مرفق.

عند استيراد 10000 مرفق، قمت بتعديل السكريبت (شكرًا لـ nano +353 ./scripts/import_scripts/vbulletin5.rb لفتح الملف في السطر الصحيح) لزيادة قيمة OFFSET في استعلام SQL بمقدار 10000، ثم أعدت تشغيل المستورد مرة أخرى… وهكذا فعلت لجميع مرفقاتي الـ 65000.

أثناء استيراد المرفقات، واجهت العديد من الأخطاء والتحذيرات بما في ذلك:

• W, [2020-08-20T12:05:37.402860 #31042] WARN -- : Bad date/time value "0000:00:00 00:00:00": mon out of range
• Post for 490451 not found (أظن أنها مرفقات قديمة مفككة؟)
• بعض أخطاء بيانات EXIF على ما يبدو
• Fail هذا الأمر أربكني وأوقف سكريبت الاستيراد. تفحصت أول “Fail” حصلت عليه ووجدت أن المرفق في النشرة كان تالفًا إلى حد ما (بدون اسم ملف)، لذا قمت بتعليق أمر exit للسماح للمستورد بالاستمرار في عمله عند “فشله”، آملاً ألا يتسبب ذلك في أي ضرر.

       puts "Fail"
       #exit

كما واجهت خطأً مزعجًا أكثر قاطع عملية الاستيراد:

1: from /usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:53:in `save!'
/usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:80:in `raise_validation_error':
Validation failed: Body is limited to 32000 characters; you entered 32323. (ActiveRecord::RecordInvalid)

لحسن الحظ، كان هذا خطأ نادرًا، وتجاوزت هذا المرفق ببساطة حتى واجهت الخطأ المماثل التالي. حدث ذلك ربما اثنتي عشرة مرة فقط من بين 65000 مرفق. لقد أعدت تشغيل سكريبت الاستيراد ببساطة مع إزاحة مختلفة في استعلام SQL.

مرحباً،
لاحظت أن الحقل المخصص import_pass مفقود لدى حوالي 400 مستخدم من أصل 27000 مستخدم متبقي لي (لقد قمت بتنظيف 154000 مستخدم غير نشط).

هل لديك أي فكرة عن السبب؟

تم ترحيل المنتدى من phpBB إلى vBulletin في مايو. هل يمكن أن يكون لذلك علاقة بالأمر؟

لن أحاول “إصلاح” هذه المشكلة واستيراد كلمات المرور لهؤلاء الـ 400 مستخدم (إلا إذا كانت هناك طريقة سهلة للقيام بذلك…؟)، وهذه ليست مشكلة كبيرة، لذا فأنا مجرد فضولي أكثر من أي شيء آخر.

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

وصف أكثر تفصيلاً للمشكلة:

من فهمي، لا يتم “طهي” المنشورات المستوردة عندما ينشئ Discourse المنشور المقابل (رغم أن حقل cooked يُنشأ بطريقة ما)، ولهذا السبب فإن استيراد المنشورات أسرع بكثير من طهي منشورات Discourse الموجودة مسبقاً.

مشكلتي هي أن الصور المستوردة لديها نسبة عرض/ارتفاع خاطئة.

مثال على نص Discourse الخام المتعلق بصورة مستوردة:

![SH-MUniFrame.JPG|600x800](upload://6Li1nnjbA8zDz6YJ3FqeYHV5zXK.jpeg)

محتوى حقل “cooked”:
<img src="https://d11a6trkgmumsb.cloudfront.net/original/3X/0/3/0379f53ed8221730ccb31807238e9c46e9fe1d37.jpeg" alt="SH-MUniFrame.JPG" data-base62-sha1="6Li1nnjbA8zDz6YJ3FqeYHV5zXK" width="517" height="500" class="d-lazyload">

كيفية ظهور الصورة في: المنشور

image517×501 102 KB

حجم الصورة الأصلية من قاعدة بيانات vBulletin هو:

select width, height from filedata where filedataid = 76237
+-------+--------+
| width | height |
+-------+--------+
|   600 |    800 |
+-------+--------+

فهمي هو أن سمة الارتفاع محكومة بإعدادات Discourse التي تحدد ارتفاعاً أقصى قدره 500 بكسل، ومن هنا تأتي نفس القيمة في سمة ارتفاع <img>. أما سمة العرض في <img> فقد تم تعديلها بشكل ما من 600 إلى 517، رغم أنني لا أستطيع فهم كيفية ذلك ولماذا.

المشكلة نفسها تنطبق على الصور الأقدم التي تحتوي على 0 في كلا حقلي العرض والارتفاع للمرفقات في vBulletin. هذه الصور أيضاً تعاني من مشكلة نسبة الارتفاع/العرض الخاطئة. لا أعرف ما إذا كانت هذه القيم تُستخدم فعلياً أثناء الاستيراد.

يتم حل المشكلة بإعادة طهي (إعادة بناء HTML) المنشور. ستتم بعد ذلك إعادة ضبط حجم الصورة بشكل صحيح وإضافة عارض الصور. لكن لدي 1.6 مليون منشور وأفضل تجنب إعادة طهيها جميعاً.

حل سريع قد يكون استخدام هذا CSS في موقع Discourse الخاص بي:

.cooked img:not(.emoji) {
    height: auto;
    width: auto;
}

لكن هذا يعني أن لن يتمكن أي شخص من اختيار حجم عشوائي عند رفع صورة، وقد تكون هناك آثار جانبية غير معروفة لدي.

هل لديك أي فكرة حول كيفية الحصول على نسبة عرض/ارتفاع صحيحة للصور في المرفقات المستوردة؟

أظن أن السبب هو أنك لم تتركهم ينضجون بعد الاستيراد. لا أستطيع تخيل طريقة لحل المشكلة دون إعادة خبز المنشورات. ربما تفضل إعادة خبز المنشورات التالفة فقط بدلاً من جميعها؟

هل يُفترض أن يتم طهيها تلقائيًا مع مرور الوقت بعد الاستيراد؟ بدءًا من آخر منشور تم إنشاؤه أم أول منشور؟

لكن هذا ليس مشكلة كبيرة، وإذا لم يتم طهيها تلقائيًا، فسأبدأ على الأرجح في إعادة طهي جميع المنشورات وأكون صبورًا، رغم أنني أعترف أنني قرأت هذا المنشور قبل بضعة أيام وأثار قلقي قليلًا: My journey into a massive posts rebake job. لدي أيضًا أسئلة حوله، لكنني سأطرحها في الموضوع المناسب.

نعم، يبدو أن هذا الكود مني. آسف على ذلك.

يجب أن يتبع هذا النمط:

   batches(BATCH_SIZE) do |offset|
       (كود SQL)
        LIMIT #{BATCH_SIZE}
        OFFSET #{offset}
        (كود آخر)
    end

ارفع إعداد موقع الحد الأقصى لطول المشاركة قبل الاستيراد.