لقد جربنا ونواجه هذه المشكلات: لقد استورد جميع المشاركات، ولكن عناوين المواضيع لن تظهر والصور الخارجية لن يتم عرضها. منتدى SMF2 الحالي هو: https://forum.mundofotografico.com.br نحن نحاول الترحيل إلى Discourse هنا: https://discourse.fotografos.online - لم تأتِ جميع المواضيع والأوصاف المناسبة، والصور لا يتم تحميلها… يرجى المساعدة! @marcozambi @miligraf @FireAllianceNX @pfaffman
أنا فقط أبدأ عملية ترحيل SMF وأقوم حاليًا باستيراد المشاركات إلى نسخة اختبار بحوالي 1000/ساعة، لذا كل شيء على ما يرام حتى الآن باستثناء البرنامج النصي لأداء MySQL حيث لم يعجب MySQL بأمر ‘ALTER USER’ لسبب ما. لقد قمت يدويًا بتنفيذ ‘CREATE USER’ وكان كل شيء على ما يرام بعد ذلك.
قرأت التعليق حول المستخدمين المحذوفين ولكني لا أستطيع بسهولة إنشاء مستخدمين جدد/رسائل بريد إلكتروني وهمية لتغطية جميع المستخدمين المحذوفين (لقد كان منتدى يعمل لأكثر من 20 عامًا وربما لدي الآن عدد مستخدمين محذوفين أكثر من المستخدمين الفعليين). أشك في أن لدي 4-5000 مستخدم محذوف. لن يكون الجميع قد نشروا ولكن الكثير منهم سيكونون قد فعلوا ذلك، لذا ربما لدي مئات عديدة من المستخدمين “المفقودين”.
يتم استيراد المشاركات على أنها تنتمي إلى “system” وهو أمر غير مثالي حقًا. تساءلت عما إذا كان ما يلي سيعمل.
- قبل الاستيراد، قم بإنشاء مستخدم وهمي، على سبيل المثال، ‘Deleted User’.
- اكتشف رقم المستخدم لـ ‘Deleted User’
- قم بتعديل السطر “user_id: user_id_from_imported_user_id(message[:id_member]) || -1،” في smf2.rb واستبدل ‘-1’ برقم المستخدم لـ ‘Deleted User’ (أعتقد أن مستخدم النظام هو -1؟)
هل سينجح ذلك؟ أيضًا، هل هناك أماكن أخرى في smf2.rb حيث سأحتاج إلى إجراء تغيير مماثل؟
مرحباً، هل تقصد بـ “محذوفين” أنهم محذوفون بالفعل من قاعدة بيانات SMF، أم أنهم لا يزالون في قاعدة البيانات بأسمائهم وكلمات مرورهم وعناوين بريدهم الإلكتروني ومميزون كمعلقين؟ كيف تظهر مشاركات هؤلاء المستخدمين “المحذوفين” حاليًا في SMF؟
أنا في منتصف عملية ترحيل ضخمة من Drupal إلى Discourse، وأيضًا من منتدى قديم جدًا به عدد لا يحصى من المستخدمين المعلقين. أردت بالتأكيد الاحتفاظ بنفس أسماء المستخدمين المعلقين وعناوين بريدهم الإلكتروني المرتبطة بهم في Discourse، لذلك اضطررت إلى إضافة تلك الوظيفة إلى برنامج استيراد Drupal لـ Discourse. بشكل أساسي، يقوم البرنامج باستيراد جميع المستخدمين كمستخدمين نشطين عاديين، وإذا كانت لديهم أي مشاركات مرئية للجمهور، فسيتم استيرادها أيضًا تمامًا كما في المنتدى الأصلي. ثم في نهاية العملية تمامًا، أضفت وظيفة قمت بنسخها من برنامج استيراد آخر للذهاب عبر قاعدة بيانات Drupal وإذا تم تمييز المستخدم على أنه معلق، فسيتم أيضًا تعليق حساب Discourse. يمكنك رؤية الكود الخاص بذلك في سجل مشاركاتي هنا.
إعجاب واحد (1)
مرحباً. يتم حذف المستخدمين فعلياً، أي أنه لم يعد هناك سجل لهم في جدول smf_member. لا يمتلك SMF وظيفة لتعليق المستخدمين. يمكنك حظر المستخدمين، ولكن هذا لا يبدو صحيحاً لحساب توفي فيه المستخدم أو فقد اهتمامه بالهواية/المنتدى. إنه ليس صحيحاً حقاً من منظور حماية البيانات أيضاً.
تحتوي مشاركات SMF على حقلين مخزنين لكل سجل… رقم عضو المستخدم، والذي يتم تعيينه إلى صفر للمستخدمين المحذوفين، واسم الناشر، والذي يحتوي على اسم المستخدم للناشر. لذلك يمكنك رؤية المستخدم الذي نشر الرسالة ولكن لم تعد هناك تفاصيل (بريد إلكتروني، اسم كامل، إلخ) متاحة للمستخدم. مشاركاتهم تحمل علامة “ضيف” عند عرضها.
أعتقد أنه يمكنني إنشاء حساب مستخدم جديد لكل مستخدم نشر رسالة بمعرف عضو صفر وتعيين عنوان بريد إلكتروني وهمي للحساب، ثم وضع علامة على المستخدم كمعلق بعد ذلك. يمكنني وضع علامة على الحسابات كمعلقة بناءً على تنسيق عنوان البريد الإلكتروني الوهمي إذا استخدمت شيئاً فريداً ولكن يمكن التعرف عليه. هذا يبدو غريباً بعض الشيء في بعض الحالات… إنشاء حسابات لأشخاص أعرف أنهم توفوا منذ 10-15 عاماً!
لدي وقت للتفكير في هذا على الرغم من ذلك… نجحت عملية الترحيل جزئياً ولكن يجب علي الآن معرفة سبب عدم إرفاق المرفقات، وعدم تعديل الروابط داخل المنتدى، ولماذا لا تعمل كلمات مرور المستخدمين الذين تم ترحيلهم. قد تكون هناك مشاكل أخرى أيضاً، لكنني سأعمل على إصلاح تلك المشاكل أولاً ثم أرى ما يظهر.
هل تقصد Postgres؟ لست متأكدًا مما يدور حوله هذا.
ما سأفعله هو أنه إذا كان معرف المستخدم 0، فاستخدم اسم المستخدم للمعّرف. بعد ذلك، إذا فشل find_username_by_import_id في العثور على المستخدم، فقم بإنشاء المستخدم، مع تعيين عنوان البريد الإلكتروني إلى fake_email (إنها وظيفة في base.rb تنشئ عنوان بريد إلكتروني وهمي) واسم المستخدم باسم المستخدم الذي لديك. بعد ذلك، إذا كنت طموحًا، يمكنك في نهاية البرنامج النصي تعليق جميع المستخدمين الذين لديهم @email.invalid في عنوان بريدهم الإلكتروني. لن يكونوا نشطين، لذلك لا أعتقد أن الأمر سيحدث فرقًا كبيرًا إذا لم تقم بتعليقهم.
طريقة أخرى ستكون إجراء استعلام يقوم بطريقة ما بإنشاء قائمة بجميع المستخدمين المحذوفين ثم إنشائهم قبل أن تبدأ في نشر المنشورات، ولكن هذا يبدو أصعب.
إذا كنت ترغب في إنشاء مستخدم deleted user وجعل كل هذه المنشورات مملوكة لهذا المستخدم بدلاً من system، يمكنك القيام بذلك واستبدال -1 برقم المستخدم لـ deleted user. يمكنك إنشائه كمستخدم عادي أو القيام بشيء رائع وجعله يمتلك معرف مستخدم -2 أو شيء من هذا القبيل.
في بعض الأنظمة، يكون هذا بسبب أن المرفقات تكون أحيانًا في نص المنشور والبعض الآخر يكون سجل المرفق في قاعدة البيانات.
هل قمت بتثبيت إضافة دعم تجزئات كلمات المرور المهاجرة بعد تشغيل الاستيراد (يمكن أن تتداخل مع تشغيل عمليات الاستيراد في بعض الظروف على الأقل). هل يقوم SMF2 بتجزئة كلمات المرور بنفس الطريقة التي يقوم بها smf؟
عذرًا، الاسم الخطأ للبرنامج النصي. إنه البرنامج النصي MySQL المشار إليه في المنشور الأول
– file: ~/smf2/script_for_mysql_tuning.sql
ALTER USER ‘user’@‘%’ IDENTIFIED WITH mysql_native_password BY ‘pass’;
شكرًا على الاقتراحات بخصوص المستخدمين وخاصة البريد الإلكتروني المزيف. مهمتي الأولى هي تعلم ما يكفي من Ruby لأتمكن من إجراء تغييرات على برنامج الاستيراد!
مرفقات SMF2 هي سجلات في قاعدة البيانات. بعد التعمق قليلاً، يبدو أنه تم استيراد بعضها، ولكن بضع مئات فقط من عشرات الآلاف. سأستمر في البحث لمعرفة ما إذا كان بإمكاني معرفة السبب.
آه، هذا على الأرجح ما أفتقده! أنا متأكد من أن SMF2 يستخدم نفس التجزئة (MD5 المملح على ما أذكر) مثل SMF1، لذا ستصلح الإضافة المشكلة على الأرجح. أحتاج إلى إجراء المزيد من عمليات الاستيراد قبل أن أقلق كثيرًا بشأن تسجيل دخول المستخدمين.
يتبادر إلى الذهن سؤال آخر. هل هناك طريقة لإعادة تعيين النظام للسماح لي بإجراء استيراد آخر. كان يجب أن آخذ نسخة احتياطية قبل أن أبدأ ولكن نسيت 
أوه. تقصد مجرد إعداد MySQL. فهمت.
إذا كنت تعرف بعض اللغات الأخرى، فيمكنك على الأرجح المضي قدمًا.
لقد كتبت العديد من المستوردات قبل أن أفعل أي شيء مثل تعلم Ruby. 
إليك طريقة واحدة لإسقاط قاعدة بيانات Discourse جديدة وإنشائها.
sv stop unicorn;DISABLE_DATABASE_ENVIRONMENT_CHECK=1 IMPORT=1 rake db:drop db:create db:migrate; sv start unicorn
إذا كان بإمكانك تذكر إجراء نسخة احتياطية، فقد يكون ذلك أسرع قليلاً. ربما.
خدعة أخرى، بمجرد الانتهاء من المستخدمين، هي إيقاف البرنامج النصي بعد استيراد المستخدمين وإجراء نسخة احتياطية حينها. سيسمح لك ذلك بتصحيح الأخطاء بعد استيراد المستخدمين دون الحاجة إلى استيراد جميع المستخدمين مرة أخرى.
أعرف القليل. كتبت برنامجي الأول في عام 1976 بلغة الآلة الثنائية على Intel 4004. أبدأ في فهم smf2.rb ببعض المساعدة من DuckDuckGo لفهم بعض هياكل الكود الجديدة بالنسبة لي.
شكراً على طريقة قاعدة البيانات للإسقاط/الإنشاء. حان الوقت للبدء من جديد ومعرفة ما إذا كان بإمكاني إجراء بعض التغييرات التدريجية على المستورد لبياناتي.
إعجاب واحد (1)
لقد تمكنت من تعديل المستورد لإنشاء حسابات وهمية بعنوان بريد إلكتروني مزيف للمستخدمين المحذوفين، وتملك الحسابات الوهمية منشوراتهم الصحيحة، لذا فهذه بداية جيدة.
أحاول فهم المرفقات تاليًا لأنني لا أرى أيًا منها في أي من المنشورات التي قمت باستيرادها حتى الآن (ويجب أن يكون هناك بعضها).
إذا قمت بإنشاء رسالة بشكل طبيعي عبر صفحة Discourse على الويب، أحصل على سجل في جدول المنشورات (id=4346)، وسجلين في جدول التحميلات (ids=403 و 404)، وأربعة سجلات في upload_references (403/Draft/4، 403/Post/4346، 404/Draft/4، 404/Post/4346). أرى أيضًا 403 في حقل image_upload_id للمنشور 4346 و HTML يشير إلى التحميلين في حقل posts/cooked.
بالنسبة للمنشورات المستوردة، أحصل على سجل جدول منشورات لكل رسالة SMF مستوردة وسجل في جدول التحميلات لكل مرفق مرتبط برسالة SMF مستوردة. تشير سجلات جدول التحميلات إلى ملفات القرص التي تحتوي على الصور الصحيحة، لذا فإن هذا الجزء يعمل بشكل جيد. ومع ذلك، لا أحصل على أي سجلات upload_references للصور المحملة أو أي من معرفات التحميل في حقل image_upload_id في جدول المنشورات.
أفترض أنني بحاجة إلى محاولة إنشاء سجلات upload_references وملء حقلي posts-image_upload_id و cooked، ولكني أردت التحقق أولاً مما إذا كانت هناك أي طريقة أخرى لربط التحميلات بالمنشورات يستخدمها (أو يحاول استخدامها) المستورد؟
يبدو أنك بحاجة إلى إضافة مرجع إلى المضيف/التحميل في raw. هناك بعض الوظائف التي ستنشئ لك رابطًا. لا أتذكر اسمها. أعتقد أنها في نموذج التحميلات، ولكن قد يكون من الأسهل العثور عليها في بعض نصوص الاستيراد الأخرى إذا كنت لا تعرف ما هو النموذج.
كنت أحرز تقدمًا في تعديل برنامج الاستيراد ليناسب تقلبات منتداي، لكنني توقفت فجأة قبل يومين. بعد آخر تحديث لـ Discourse beta، لم يعد بإمكاني بناء حاوية الاستيراد. أحصل على…
> FAILED
> --------------------
> Pups::ExecError: cd /var/www/discourse & apt-get update & DEBIAN_FRONTEND=noninteractive apt-get install -y libmariadb-dev failed with return #<Process::Status: pid 439 exit 100>
> Location of failure: /usr/local/lib/ruby/gems/3.1.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
> exec failed with the params {"cd"=>"$home", "cmd"=>["echo \"gem 'mysql2'\" >> Gemfile", "apt-get update & DEBIAN_FRONTEND=noninteractive apt-get install -y libmariadb-dev", "su discourse -c 'bundle config unset deployment'", "su discourse -c 'bundle install --no-deployment --path vendor/bundle --jobs 4 --without test development'"]}
> bootstrap failed with exit code 100
> ** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
لقد رأيت المنشورات حول انتهاء صلاحية مفتاح yarn وقمت بإصلاح ذلك. كان هذا يمنع تثبيت حزمة libmariadb-dev ولكنني قمت بتثبيت يدوي للحزمة وقد نجح ذلك بشكل صحيح. لا يزال إعادة بناء الاستيراد لا يعمل مع تمكين قالب استيراد mysql حتى بعد تثبيت حزمة MariaDB يدويًا.
لقد قمت ببناء خادم جديد وبدأت بتثبيت جديد لـ Discourse لتجنب أي مشاكل محتملة مع الخادم/التثبيت السابق. ومع ذلك، يعطي الخادم الجديد نفس الخطأ القديم.
ليس لدي أي أفكار حول ما يجب تجربته بعد ذلك، لذا سأرحب بأي اقتراحات!
انظر Apt-get update fails inside container yarn repo not signed - #5 by pfaffman. ستحتاج إلى تعديل قالب mysql.
إعجاب واحد (1)
شكراً لك على توجيهي في الاتجاه الصحيح. أرى الآن ما فعلته بشكل خاطئ!
إعجاب واحد (1)
نحن نبدأ بالترحيل التجريبي لمنتدى SMF 2 (v2.0.15 على وجه الدقة) وإحدى المشكلات الأولى التي ظهرت هي مشكلة عندما تحتوي الفئات على علامة العطف (&) في أسمائها:
عناوين المواضيع التي تحتوي على نفس الشيء تبدو جيدة:
حتى الآن، يبدو أن علامة العطف (&) هي الحرف الإشكالي الوحيد، وعلى سبيل المثال، فإن الحروف الألمانية المتحولة (umlauts) جيدة:
من المحتمل أننا نواجه أيضًا مشكلات تم الإبلاغ عنها هنا في الموضوع (المستخدمون المحذوفون، المرفقات، الروابط داخل المنتدى)، لكن الاستيراد لا يزال قيد التشغيل، لذا سأقوم بالتحديث بمجرد اكتماله.
في هذا الصدد، أتساءل عما إذا كانت سرعة الاستيراد بطيئة حقًا. نحن نستورد حاليًا بمعدل 1750 عنصرًا/دقيقة (في البداية كانت أقرب إلى 2000 عنصر/دقيقة) على جهاز AMD Ryzen 5 3600 بذاكرة وصول عشوائي (RAM) بسعة 64 جيجابايت (Hetzner، Ubuntu 22.04)، مما يجعل عملية الترحيل بأكملها تستغرق حوالي 3 أيام.
هذه سرعة جيدة جدًا.
أتخيل أن أي مشاكل تم الإبلاغ عنها لا تزال قائمة، على الرغم من أن عددًا مدهشًا من الأشياء فريد من نوعه للمنتدى. إذا كنت ترغب في إصلاح بعض الأشياء ولديك ميزانية، فسأكون سعيدًا بالمساعدة.
إعجاب واحد (1)
شكرًا لك! سأعود إليك بمجرد أن تصبح الأمور أكثر واقعية.
في الوقت الحالي، نحن (منظمة صغيرة غير ربحية تركز على ألعاب لعب الأدوار على الطاولة والهوايات ذات الصلة) في مرحلة التقييم - هناك إجماع على أننا نريد برنامجًا جديدًا، و Discourse هو الخيار المفضل حتى الآن. ولكن سيتعين علينا جمع جميع المهام (الترحيل، والمظهر الجديد، والمكونات الإضافية/مكونات المظهر الجديدة إذا لزم الأمر) ومعرفة ما إذا كان بإمكاننا ملاءمة كل شيء في ميزانيتنا.
إعجاب واحد (1)
هل هناك سبب خاص لهذه الخطوة؟
على حد علمي من إعادة قراءة دقيقة للمنشور الأصلي، لم يتم تغيير/تعديل ملف smf2.rb؟
وإذا كان smf2.rb موجودًا على المضيف في (على سبيل المثال) /var/discourse/smf2 وقمت بإعداد تحميل وحدة التخزين الخاصة بك في الخطوة 2 وفقًا لذلك، فسيتم تحميله داخل الضيف على /shared/smf2 على أي حال.
أنا لا أفهم ضرورة نسخه كخطوة منفصلة. ولكن فهم هذا قد يكون مفتاحًا لمعرفة سبب عدم العثور على 95٪ من المرفقات بشكل صحيح بواسطة البرنامج النصي…
إعجاب واحد (1)
يبدو أنك على حق بشأن (عدم الحاجة) إلى نسخه. ربما قام المؤلف بتغييره وتم نقل تغييراته لاحقًا إلى النواة.
إذا كنت تحصل على 5٪ وليس 0٪ من المرفقات، فإنه يبدو أن هناك خطأ ما في البرنامج النصي.
في بعض الأنظمة، هناك طريقتان لإرفاق الملفات، إحداهما عن طريق ذكرها في الملف (بحيث تكون في النص الخام للمنشور ويتم التعامل معها بهذه الطريقة) والأخرى عن طريق إرفاقها بالمنشور في بعض البيانات الوصفية/الجدول. تخميني هو أن لديك 95٪ في قاعدة بياناتك تم إجراؤها بطريقة واحدة والبرنامج النصي يقوم بالطريقة الأخرى.
لكن يبدو أنه قد يحاول كلا الطريقتين؟ ستحتاج إلى العثور على منشور يجب أن يحتوي على مرفق، والبحث في قاعدة البيانات ونظام الملفات لمعرفة كيفية تخزينه، ثم النظر في الكود لمعرفة سبب عدم حصوله عليه.
إعجاب واحد (1)
[اقتباس=“pfaffman, post:101, topic:90314”]
يبدو أنك على حق بشأن (عدم الحاجة) إلى نسخه. ربما قام المؤلف بتغييره وتم نقل تغييراته لاحقًا إلى النواة.
[/اقتباس]
شكرًا @pfaffman هذا مطمئن! لقد اعتقدت تقريبًا أن هذا هو الحال، ولكن نظرًا لأنني أواجه مثل هذه المشاكل مع هذا الاستيراد، فقد كنت أشكك في معرفتي ومهاراتي على كل المستويات!
[اقتباس=“pfaffman, post:101, topic:90314”]
ولكن يبدو أنه يحاول كلا الطريقين؟ ستحتاج إلى العثور على مشاركة تحتوي على مرفق، والبحث في قاعدة البيانات ونظام الملفات لمعرفة كيفية تخزينها ثم النظر في الكود لمعرفة سبب عدم حصوله عليها.
[/اقتباس]
شكرًا على النصائح، كل شيء محل تقدير @pfaffman - هذه محاولة ثانية مؤجلة طويلاً لنفس المنتدى الذي كنت أعمل عليه العام الماضي. إنها وظيفة مجانية ولكن ربما أشركك مرة أخرى إذا كان لديك وقت.
إنه منتدي SMF2 قديم جدًا يحتوي على مرفقات بالشكلين:
-
`
-
`
لا أزال أحاول معرفة ما إذا كان هناك نمط للأخطاء.
تخميني (بدون النظر إلى الكود!) هو أن أحد هذه هو ما يفعله البرنامج النصي والآخر ليس كذلك (ربما يكون أحدهما هو الطريقة القديمة، لذا تستخدم المنشورات الجديدة الطريقة الأخرى، لكنها لم تعد لإصلاح تلك التي تستخدم الطريقة الأخرى).
لذا انظر إلى convert_message_body والحقول في جدول المرفقات. ربما تحولوا من MD5 إلى SHA1 أو العكس لسبب ما.
كما قلت، قد يكون أن أحد هذه الإصدارات يحتوي على مرجع للتحميل بدلاً من ربطه في الجدول، لذا ستقوم بعمل gsub للبحث عن هذا النمط، وبعد ذلك إذا تطابق، ستحصل على المفتاح، وتبحث عنه في الجدول، ثم تقوم بـ create_upload بهذا الملف. .
آمل أن يكون هذا كافياً لتبدأ، ولكن يرجى الاتصال بي إذا كنت ترغب في المزيد من المساعدة مما يمكنني تقديمه هنا.