إنه في الواقع 3.3، لذا أقوم بالتحضير بانتظار وصول طلبات السحب لجعل البرنامج النصي متوافقًا مع هذا الإصدار من phpBB، أو قد أجرب ذلك باستخدام البرنامج النصي الحالي باستخدام التعديل الذي اقترحته سابقًا للتحقق من الإصدار..
لذا أعتقد أنني سأحتاج إلى العمل مع xml_to_markdown.rb؟
كانت محاولتي لإجراء استيراد تجريبي بمنتدى phpBB 3.3.x فشلاً ذريعًا، ولكن سأتحدث عن ذلك لاحقًا.
لقد تعلمت الكثير أثناء محاولة تجربتها، وفكرت في مشاركة ما تعلمته لأنه قد يكون مفيدًا للاستيرادات الأخرى وعند تحديث البرنامج النصي للاستيراد لـ phpBB 3.3.
إذا كنت بحاجة إلى تعديل /script/import_scripts/phpbb3/database/database.rb لتجاوز فحص الإصدار، أو /script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb لإضافة BBcodes مخصصة، فإن الوقت المناسب للقيام بذلك هو بعد إدخال الاستيراد بهذا الأمر:
/var/discourse/launcher enter import
في تلك المرحلة، يمكنك استخدام nano لتعديل الملفات.
نظرًا لأن محاولتي لتشغيل الاستيراد على منتدى phpBB 3.3 الخاص بي فشلت، لا يمكنني التأكد من أن تغييرات BBcode المخصصة الخاصة بي ستكون فعالة، ولكن يبدو أن كل ما عليك فعله لـ phpBB 3.2+ هو تعديل الملف:
/script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb
كما هو مذكور أعلاه، وإضافة تعريف بالشكل:
def visit_<اسم BBcode المخصص الحساس لحالة الأحرف هنا>(xml_node, md_node)
# الكود للتعامل مع الأشياء يذهب هنا
end
مرة أخرى، لم أتمكن من اختبار ذلك بعد، ولكن أحد BBcodes المخصصة الشائعة جدًا في phpBB والتي لا تظهر في إصدار xml_to_markdown.rb الذي كان لدي هو هذا:
[YouTube]{Identifier}[/YouTube]
حيث يكون {Identifier} هو قيمة “v” من سلسلة استعلام عنوان URL الخاص بـ YouTube.
لذا فإن محاولتي المبتدئة في Ruby لإضافة هذا الكود إلى xml_to_markdown.rb هي:
def visit_YouTube(xml_node, md_node)
content = xml_node.content
url = "https://www.youtube.com/watch?v=" + content
md_node.text = "#{url}"
md_node.prefix_linebreaks = md_node.postfix_linebreaks = 2
md_node.prefix_linebreak_type = LINEBREAK_HTML
end
أخيرًا، عندما قمت بتشغيل برنامج الاستيراد النصي، وصلت فقط إلى خطوة تحميل قاعدة البيانات، وحصلت على هذا الخطأ:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
لست متأكدًا مما إذا كانت هذه مشكلة في محرك قاعدة البيانات - الأصل يستخدم InnoDB - أو ماذا، ولكني أشك في أنه سيتم معالجتها في إصدار phpBB 3.3 من البرنامج النصي.
حسنًا، لم أستطع ترك هذا الأمر.
بينما أفترض أنه من الممكن أن يكون الخطأ الذي تلقيته قد تم التعامل معه بواسطة البرنامج النصي للاستيراد، إلا أنه يبدو لي حقًا أنه مشكلة في بنية قاعدة البيانات لـ phpBB3، وحقيقة أن تنسيق قاعدة البيانات الخاصة بي هو UTF8. تلقيت هذا الخطأ أثناء تشغيل البرنامج النصي للاستيراد:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
عندما نظرت إلى السطر 1233035 من ملف phpbb_mysql.sql الخاص بي - أستخدم نسخة محلية من تفريغ البيانات - رأيت هذا:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
بالنظر إلى عمود config_name في الجدول phpbb_config، وجدت أنه تم تعيينه على VARCHAR(255).
بفضل هذا المنشور على Stackoverflow، اكتشفت أنه يمكنني استخدام “فهرس بادئة” لتقصير طول المفتاح. لقد اختبرته، وهو يعمل.
بالنسبة لقاعدة بيانات phpBB 3.3.8 الخاصة بي، تأثرت أربعة جداول بالفعل:
إذا أراد أي شخص آخر تجربته، فإليك الخطوات الخاصة بجدول phpbb_config، وسأقوم بتضمين الاستعلامات للجداول الأخرى في النهاية.
حساب أقصر قيمة لفهرس البادئة باستخدام هذا الاستعلام:
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config`;
في حالتي، أظهر أن 100٪ من الصفوف استخدمت أقل من 50 حرفًا، لذلك قمت بتحرير ملف تفريغ البيانات الخاص بي:
nano /var/discourse/shared/standalone/import/data/phpbb_mysql.sql
واستخدمت البحث Ctrl+W للسلسلة التالية:
ALTER TABLE `phpbb_config`
ثم قمت بتغيير هذا:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
إلى هذا:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`(50)),
ADD KEY `is_dynamic` (`is_dynamic`);
الـ (50) الموجود هناك هو طول فهرس البادئة.
في حالتي، اضطررت إلى تكرار العملية مع الجداول الثلاثة الأخرى باستخدام هذه الاستعلامات للحصول على طول مفتاح البادئة الأمثل:
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config_text`;
SELECT
ROUND(SUM(LENGTH(`migration_name`)<10)*100/COUNT(`migration_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`migration_name`)<20)*100/COUNT(`migration_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`migration_name`)<50)*100/COUNT(`migration_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`migration_name`)<100)*100/COUNT(`migration_name`),2) AS pct_length_100
FROM `phpbb_migrations`;
SELECT
ROUND(SUM(LENGTH(`provider`)<10)*100/COUNT(`provider`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`provider`)<20)*100/COUNT(`provider`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`provider`)<50)*100/COUNT(`provider`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`provider`)<100)*100/COUNT(`provider`),2) AS pct_length_100
FROM `phpbb_oauth_accounts`;
هذه هي سلاسل البحث للجداول الأخرى لتوفير بعض الوقت:
ALTER TABLE `phpbb_config_text`
ALTER TABLE `phpbb_migrations`
ALTER TABLE `phpbb_oauth_accounts`
لن أقول إنني وصلت إلى بر الأمان، لكن ما سبق حل خطأ قاعدة البيانات الأولي الخاص بي، والاستيراد قيد التشغيل:
#import_phpbb3.sh
The phpBB3 import is starting...
Loading existing groups...
Loading existing users...
Loading existing categories...
Loading existing posts...
Loading existing topics...
importing from phpBB 3.3.8
creating users
722 / 5014 ( 14.4%) [58 items/min]
تحديث:
انتهى البرنامج النصي للاستيراد في 9 ساعات و 28 دقيقة. الحمد لله على Screen. هذا البرنامج النصي رائع!
المعالجة اللاحقة قيد التقدم الآن.
هل يوجد سجل لمخرجات البرنامج النصي للاستيراد في مكان ما، أم كان يجب علي توجيهه إلى ملف؟
ما هي الإجراءات التي يجب استخدامها لاستيراد phpbb3 عند تشغيل discourse_dev في حاوية Docker ضمن WSL؟
لقد جربت كل من الإجراء 1. الاستيراد باستخدام حاوية Docker والإجراء 2. الاستيراد باستخدام بيئة التطوير. لم ينجح أي منهما، على الرغم من أنني تمكنت من تشغيل البرنامج النصي حتى الاكتمال بموجب الإجراء 1 ولكن لم تنتقل أي بيانات فعليًا إلى قاعدة بيانات المنتدى على الرغم من أن العديد من الاستعلامات بدت ناجحة أثناء تقدمها. هل يمكن أن تكون هناك قاعدة بيانات مختلفة يتم ملؤها بسبب تشغيل الاستيراد في حاويتها الخاصة منفصلة عن حاوية discourse_dev؟
في حالة الإجراء 2، من غير الممكن ببساطة تنفيذ البناء الذي يفشل مع “حدث خطأ أثناء تثبيت tiny_tds (2.1.5)، ولا يمكن لـ Bundler المتابعة.”
هل يجب أن أحاول إجراء “تثبيت قياسي” (غير Docker، غير تطوير) في WSL ثم إجراء الاستيراد المستند إلى Docker؟
هذا ما أوصي به. نادرًا ما أقوم بالترحيل في بيئة التطوير بعد الآن.
بالإضافة إلى ذلك، لا تحتاج إلى tiny_tds، إلا إذا كنت تستخدم mssql بدلاً من mysql/mariadb.
شكراً جزيلاً لك يا جاي. لقد كانت دروسك التعليمية دقيقة للغاية، وأنا أقدرها حقاً.
لقد قمت بتثبيت Discourse بنجاح على خادم افتراضي خاص جديد باستخدام عملية تثبيت Docker القياسية. ثم قمت بتشغيل عملية الاستيراد وفقًا لهذه التعليمات وانتهى البرنامج النصي دون مشاكل. خرجت من الحاوية ثم أصدرت أمر إيقاف الاستيراد وحصلت على الرسالة التالية:
''لديك أقل من 5 جيجابايت من المساحة الخالية على القرص حيث يوجد /var/lib/docker. ستحتاج إلى مساحة أكبر للمتابعة
نظام الملفات الحجم المستخدم المتاح النسبة المئوية المحملة على
/dev/vda1 24 جيجا 20 جيجا 2.7 جيجا 89٪ /
هل ترغب في محاولة استعادة المساحة عن طريق تنظيف صور وحاويات Docker في النظام؟ (ص/ن)‘’
لم تؤدِ استعادة المساحة إلى توفير أي مساحة إضافية. فكيف أتابع؟ هل يمكنني حذف جميع ملفات الصور التي قمت بتحميلها إلى /data بأمان؟ لست متأكدًا مما إذا كانت لا تزال مطلوبة.
شكرًا.
إذا بدا أن الاستيراد قد اكتمل، وكنت تتحدث عن الصور التي كان ينبغي استيرادها، فيجب أن يكون الأمر على ما يرام، ولكن من المحتمل ألا يكون لديك مساحة كافية لعمل نسخة احتياطية. أقترح ترقية القطرة لتوفير المزيد من المساحة. لا ينبغي أن يكون السعر اليومي مشكلة كبيرة.
شكراً لك على هذه النصيحة يا جاي.
في حال كانت هذه التفاصيل مفيدة للآخرين، فقد قمت بإزالة ملفات الصور (فقط) مما أتاح حوالي 3.4 جيجابايت ليصبح المجموع المتاح 6.1 جيجابايت، ثم نجحت Sidekiq في معالجة ما بعد المعالجة. تم زيادة مساحة القرص منذ ذلك الحين بمقدار 20 جيجابايت إضافية.
للتسجيل، كان هذا استيرادًا لمنتدى phpBB الإصدار 3.3.0 مع ما يزيد قليلاً عن 73,000 مشاركة في ما يزيد قليلاً عن 8,000 موضوع مع ما يزيد قليلاً عن 1300 مستخدم.
القضية الوحيدة التي وجدتها، حتى الآن، هي أن بعض أسماء المستخدمين غريبة ولكن هذا تمت مناقشته أعلاه وليس قاتلاً.
سيكون هناك فاصل زمني بين هذا الاستيراد وإغلاق منتدى phpBB المصدر. هل يمكنني فقط ترك حاوية Docker للاستيراد في مكانها ثم استخدامها على نسخة احتياطية تزايدية لترحيل المشاركات التي تمت بعد هذا الاستيراد؟
عندما قمت بترحيل phpBB 3.3.x الخاص بي، للقيام بالاستيراد النهائي، وضعت موقع phpBB في “وضع الصيانة”، واستخدمت rsync لتحديث المرفقات والصور الرمزية والوجوه المبتسمة، ثم قمت باستيراد تفريغ بيانات جديد، وكان عليّ إعادة بناء الاستيراد لتشغيل نهائي لبرنامج الاستيراد، لكنني خرجت من الاستيراد قبل ذلك.
@DonH هل قمت باستيراد كلمات مرور phpBB وجعلتها تعمل مع إضافة Migrate Passwords؟
لم أقم باستيراد كلمات مرور phpBB لعدة أسباب. أردت تجنب أي تعارضات محتملة مع الإضافات وأردت إجبار الأشخاص على ترقية كلمات مرورهم، وبدا أن هذه الهجرة طريقة جيدة (وذريعة جيدة) للقيام بذلك. يتم التعامل مع الأمان على مضيف phpBB بواسطة شركة الاستضافة، مع وجود الخادم الافتراضي الخاص الجديد، لا توجد رفاهية كهذه.
لتوضيح الأمر، هل قمت بإعادة استيراد قاعدة بياناتك بالكامل مرة أخيرة ولم تقم بتحديث تدريجي؟
فهمي، وخبرتي، هو أنه إذا قمت بتفريغ بيانات منتدى phpBB الخاص بك - من phpMyAdmin، على سبيل المثال - وقمت بتحميل الملف إلى /var/discourse/shared/standalone/import/data، وأعدت بناء الاستيراد، ثم أعدت تشغيل أمر الاستيراد، فلن يقوم البرنامج النصي للترحيل بلمس حسابات المستخدمين أو المشاركات أو غيرها التي تم استيرادها بالفعل، فقط إدخالات قاعدة البيانات التي لم يتم استيرادها سابقًا.
في الأساس، يقوم بتحديث تدريجي، ولكنه لا يلمس الإدخالات الموجودة، لذلك قد تفقد بعض البيانات؛ على سبيل المثال، إذا قام مستخدم بتحرير مشاركة تم استيرادها بالفعل أو تغيير عنوان بريده الإلكتروني.
إذا تركت إعداد الإضافة migratepassword_allow_insecure_passwords غير محدد، فلن تسمح إضافة migratepassword بكلمات المرور التي تم ترحيلها والتي تعتبر غير آمنة بواسطة Discourse، مع احترام جميع إعدادات التعقيد مثل الحد الأدنى للطول والأحرف الفريدة.
لست متأكدًا من نوع تعارضات الإضافات التي تشير إليها؟
@RGJ هل سيعمل المكون الإضافي migratepassword مع phpBB 3.3؟
أنا بصدد إجراء استيراد بمنتدى phpBB 3.3.8 الآن، وأقوم باستيراد كلمات المرور لتجربتها.
كيف يمكنك الترحيل من myBB؟
يمكنك البحث عن myBB والعلامة #migration::tag ربما ستجد howto
حسنا، شكرا على المعلومات!
شكراً لهذا التوضيح يا ريتشارد. لم أكن أشير إلى أي صراع محدد، فقط إلى احتمالية حدوث شيء غير متوقع في منطقة غير مألوفة. لقد قمت بالاستيراد عمداً قبل إضافة أي إضافات. في الغالب، أريد أن أجبر أعضائنا على ترقية كلمات المرور الخاصة بهم.
لقد تمت هذه الهجرة بنجاح حقًا، لذا الشكر لغيرهارد وكل من شارك في هذا النص البرمجي المتوازن. أتطلع إلى تخصيص لوحة الرسائل الجديدة الخاصة بنا.
نعم سيعمل، لقد أضفنا مؤخرًا دعم Argon2 في المكون الإضافي.
يدعم ريتشارد المكون الإضافي على استضافته. لم أسمع أبدًا أنه يسبب مشاكل. يقوم العديد من المستوردين باستيراد كلمات المرور ويعمل الأمر ببساطة. لقد عمل حتى مع نص استيراد كتبته لبعض المنتديات العشوائية الأخرى.