هذا كله نموذجي إلى حد ما.
أعتقد أن التغييرات التي تقترحها لن تؤدي على الأرجح إلى كسر أي استيرادات أخرى. غالبًا ما تكون هناك مجموعة من التغييرات مثل هذه ثم مجموعة من التغييرات الأخرى الخاصة بالاستيراد، ومعرفة أي منها هو أي منها واختبارها مرة أخرى مع تلك التغييرات فقط سيكون الكثير من العمل، لذلك لا يتم إنشاء طلب سحب (PR).
يسعدني أنك أنجزت ذلك!
شكراً كونستانزا، رابط مفيد جداً. 
شكراً على المعلومات يا جاي. سأقوم بإنشاء طلب سحب (PR) لاحقاً بعد الانتهاء من الترحيل إذا كان بإمكانه المساعدة في الحصول على أداة ترحيل phpBB3 أفضل.
النص البرمجي الحالي يتجاهل أيضاً علامات [size=XXX] التي واجهتها أثناء عمليات ترحيل أخرى.
في عملية الترحيل الحالية، قمت بإنشاء نص برمجي سريع في المستورد الخاص بي واستخدمت قيمة XXX لاستبدال هذه العلامات بـ \u003csmall\u003econtent\u003c/small\u003e و \u003cbig\u003econtent\u003c/big\u003e نظراً لأنها مدعومة من قبل Discourse.
لكن هذه كانت رغبة شخصية وقد يكون هناك حل أكثر ملاءمة (بشكل عام) وهو ببساطة التخلص من علامات [size] هذه، كما يفعل نص الترحيل البرمجي بالفعل مع علامات [color].
شكراً @Canapin على كل ملاحظاتك. طلب السحب (PR) مرحب به بالتأكيد!
أيضًا، لمحة صغيرة: نحن نعمل على حل يجب أن يجعل جميع عمليات الاستيراد - وليس فقط phpBB - أفضل وأسرع وأسهل في التخصيص والتخلص من تلك المشاكل المزعجة مع تحويل BBCode… 
أثناء استيراد مشاركاتي، واجهت مجموعة من هذه الأخطاء (ليس لكل المشاركات):
251491 / 251672 ( 99.9%) [14140 items/min] Exception while creating post 354629. Skipping.
undefined method `[]' for nil:NilClass
/var/www/discourse/script/import_scripts/phpbb3/importers/post_importer.rb:66:in `block in map_first_post'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.1/lib/active_support/core_ext/object/try.rb:15:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.4.1/lib/active_support/core_ext/object/try.rb:15:in `try'
/var/www/discourse/script/import_scripts/base.rb:576:in `create_post'
/var/www/discourse/script/import_scripts/base.rb:523:in `block in create_posts'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.3/lib/patches/db/mysql2/alias_method.rb:8:in `each'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-2.3.3/lib/patches/db/mysql2/alias_method.rb:8:in `each'
/var/www/discourse/script/import_scripts/base.rb:510:in `create_posts'
/var/www/discourse/script/import_scripts/phpbb3/importer.rb:192:in `block in import_posts'
/var/www/discourse/script/import_scripts/base.rb:874:in `block in batches'
/var/www/discourse/script/import_scripts/base.rb:873:in `loop'
/var/www/discourse/script/import_scripts/base.rb:873:in `batches'
/var/www/discourse/script/import_scripts/phpbb3/importer.rb:254:in `batches'
/var/www/discourse/script/import_scripts/phpbb3/importer.rb:188:in `import_posts'
/var/www/discourse/script/import_scripts/phpbb3/importer.rb:38:in `execute'
/var/www/discourse/script/import_scripts/base.rb:47:in `perform'
/var/www/discourse/script/import_scripts/phpbb3/importer.rb:22:in `perform'
script/import_scripts/phpbb3.rb:33:in `<module:PhpBB3>'
script/import_scripts/phpbb3.rb:14:in `<module:ImportScripts>'
script/import_scripts/phpbb3.rb:13:in `<main>'
لكنني لم أتمكن من معرفة سبب ذلك.
أي فكرة؟
كيف يمكنني التحقق مما إذا كانت هناك مشاركات مفقودة بالفعل؟ لم أتمكن من العثور على كيفية إخراج البيانات (محتوى المشاركة على سبيل المثال) المقابلة لـ “Exception while creating post 354629”
لا أتذكر أنني واجهت هذا الخطأ في اختبارات الاستيراد الأخرى التي أجريتها في الأيام السابقة، ولكن ربما لم أنتبه… هل يمكن أن يكون مرتبطًا بهذه المشكلة المعروفة؟
251490 / 251672 ( 99.9%) [14140 items/min] Parent post 337703 doesn't exist. Skipping 354628: vw-camper est malade !?
لقد قمت بتشغيل سكربت الاستيراد مرتين كما ينبغي، فيما يتعلق بهذه المشكلة تحديدًا.
تأكد من تعيين tag_mappings: {} في ملف settings.yml الخاص بك إذا لم تكن تستخدم هذه الميزة.
أشعر بالغباء! حتى أنني فكرت في ذلك، لكنني كنت متأكدًا جدًا من أنني لم أواجه هذا الخطأ من قبل لدرجة أنني لم أحاول… 
لقد حل المشكلة، شكرًا جزيلاً لك.
أفترض أنه لا يمكنك قول الكثير في هذا الوقت، ولكن هل هناك أي دليل حول كيفية عمل ذلك، ومتى ستكون نصوص الاستيراد القابلة للاستخدام متاحة باستخدام هذا الشيء الجديد؟
قد أقوم بترحيل phpBB آخر هذا العام، لذا قد يكون من المثير للاهتمام جدًا بالنسبة لي معرفة المزيد. 
مرحباً، أنا أختبر ترحيل phpbb 3.2 إلى discourse لمنتدى كبير الحجم (30 ألف موضوع / 600 ألف مشاركة) و تقريباً كل شيء يعمل بشكل جيد، باستثناء عدد قليل من المواضيع التي لم يتم استيرادها (“الموضوع الأصلي xx غير موجود”)، ولم يتم حلها بتشغيلات متعددة، ولكنها ليست مشكلة.
مشكلتي الرئيسية هي أن عمليات الاستيراد اللاحقة ببيانات جديدة (تم التحقق منها باستخدام sha256sum في ملف import/mysql/imported) لا تستورد مشاركات جديدة في Discourse. أواجه استثناءً مبكراً في العملية، لا أعرف ما إذا كان مرتبطاً:
فشل في تعيين المشاركة بالمعرف 6815
قيمة BIGINT UNSIGNED خارج النطاق في '(`phpbb_prod`.`o`.`poll_option_total` - (select count(distinct `phpbb_prod`.`v`.`vote_user_id`) from `phpbb_prod`.`phpbb3_poll_votes` `v` join `phpbb_prod`.`phpbb3_users` `u` join `phpbb_prod`.`phpbb3_topics` `t` where ((`phpbb_prod`.`u`.`user_id` = `phpbb_prod`.`v`.`vote_user_id`) and (`phpbb_prod`.`v`.`topic_id` = `phpbb_prod`.`t`.`topic_id`) and (`phpbb_prod`.`v`.`poll_option_id` = `phpbb_prod`.`o`.`poll_option_id`) and (`phpbb_prod`.`t`.`topic_id` = `phpbb_prod`
هل هذه مشكلة في الاستطلاعات المضمنة في المشاركات، من استعلام SQL المعروض؟
أتمنى لك يوماً سعيداً!
لا أستطيع قول الكثير بعد لأنه لا يزال قيد التطوير. الخطط يمكن أن تتغير… ولكن “هذا العام” هو تخمين جيد.
قيمة BIGINT UNSIGNED خارج النطاق
هممم، هل هناك هذا العدد الكبير من الأصوات المجهولة في هذا الاستطلاع؟
ستحتاج إلى تعديل هذا الاستعلام SQL:
شيء مثل هذا ربما؟ https://stackoverflow.com/a/11704174/451338
يرجى إعلامي عندما تجد حلاً أو تنشئ طلب سحب (PR) مع إصلاح. سأكون ممتنًا لذلك.
الاستطلاعات من بداية المنتدى، لم أكن مسؤولاً في ذلك الوقت، لكن أعتقد أن المستخدمين المجهولين لم يُسمح لهم أبدًا بنشر/الإجابة على الاستطلاعات.
مع
SET sql_mode = 'NO_UNSIGNED_SUBTRACTION';
أنا قادر على الاستعلام عن جميع أصوات الاستطلاعات، ولاثنين منها، لدي “أصوات مجهولة” سلبية. يبدو أن هذا المنتدى سمح بطريقة ما بالتصويت المجهول، في الواقع
شكراً @gerhard على النصيحة، سأتعمق أكثر…
أنا أبحث حاليًا في ترحيل منتدى phpBB إلى Discourse، المشكلة هي أن phpBB الخاص بنا يستخدم Postgres بدلاً من MySQL، لذا أود تكييف البرنامج النصي للعمل مع ذلك أيضًا.
هل يمكن لأي شخص تقديم بعض الإرشادات حول أفضل طريقة للقيام بذلك؟ حيث أنني أود أن يستفيد الجميع من هذا العمل، لذا أود أن يستخدم نهجًا مقبولًا من المصدر بدلاً من مجرد اختراقه بسرعة للعمل.
على حد علمي، يبدو أن الأمر يتعلق في الغالب بإضافة عبارات SQL المناسبة لمخطط PostgreSQL باستخدام محول قاعدة البيانات الصحيح، ومع ذلك، لست متأكدًا من كيفية تكييف التنسيق بأكمله لحاوية Docker لتدوير مثيل PostgreSQL بشكل صحيح، إذا لزم الأمر حسب نوع قاعدة البيانات المحدد في التكوين، لاستيراد تفريغ قاعدة البيانات إليه وتنفيذ العبارات مقابله.
يوجد نص برمجي لاستيراد دفعة لـ phpBB يعمل على PostgreSQL. هل رأيته؟ discourse/script/bulk_import/phpbb_postgresql.rb at main · discourse/discourse · GitHub
ومع ذلك، لا أعتقد أنه تم استخدامه مؤخرًا، لذلك من المحتمل أن يكون معطلاً وقد لا يعمل مع إصدارات phpBB الحالية لأن تنسيق تخزين Markdown قد تغير.
مهما كان المسار الذي تختاره، لا أقضي الكثير من الوقت في تلميع حلك إلا إذا كنت ترغب حقًا في ذلك. سيتم إيقاف نصوص الاستيراد الحالية في وقت ما هذا العام…
شكرًا، لم أكن على علم بذلك! وشكرًا على التنبيه بأن النصوص البرمجية سيتم إيقافها، لذا أعتقد أنه قد لا يكون من المفيد دمج مثل هذه الميزة الرئيسية لتلك إذا كان سيتم إيقافها قريبًا على أي حال؟ هل هناك بديل مخطط له لها؟
نعم، بالطبع سيكون هناك بديل.
شيء آخر مهم كنت أتساءل عنه، هل أحتاج إلى تعيين أي شيء آخر غير disable_edit_notifications للتأكد من عدم إرسال أي بريد إلكتروني للمستخدمين المستوردين بواسطة Discourse لأي شيء أقوم باستيراده؟ نظرًا لأن المثيل ليس عامًا حاليًا ونحن فقط نجرب الاستيراد وربما نحتاج إلى عدة محاولات حتى يكون جيدًا بما فيه الكفاية، أريد تجنب إرسال أي رسائل بريد إلكتروني.
أنت تبحث عن إعداد الموقع disable_emails…
بينما يتم دعم [b]النص[/b] ضمن الأسطر في Discourse، إلا أنه لا يتم تفسيره لمجموعات النصوص التي تحتوي على أسطر جديدة.
[b]على سبيل المثال، إذا كان لدي هذا النص في مشاركتي…
وواصلت سطري بعد سطر فارغ، سأغلق bbcode ولن يتم تحويل النص إلى نص عريض[/b]
نفس الشيء بالنسبة لـ [i] وربما علامات أخرى.
فشلت في العثور على حل نظيف لهذا في استيرادي. أي فكرة؟ 
هذا ليس الحل المثالي، ولكن لدي فكرة لخطة بديلة أو ثالثة على الأقل.
بعد الاستيراد، يمكنك إعادة تعيين [b] إلى <b> و [/b] إلى </b> نظرًا لأن <b> يعمل على مستوى الكتلة هنا
test
test
<b>test
test</b>
ولكن في منتدى كبير، سيستغرق الأمر وقتًا طويلاً: /
فكرة جيدة!
لم يتم استيراد المنتدى الخاص بي بعد، لذا لا يزال بإمكاني العمل على أداة الاستيراد.
ألن يكون استخدام <strong> و <em> أكثر منطقية، بغض النظر عن “خاصيتهما” الدلالية؟
هذه أخبار رائعة!
أعتقد أن هذا شيء جيد لمحاولة القيام به أولاً.