كيفية تبسيط عمليات الترحيل متعددة المواقع في WordPress باستخدام MU-Migration

نشرت: 2022-03-10
ملخص سريع ↬ تقديم أداة MU-Migration ، وهي أمر WP-CLI الذي يساعد المطورين على ترحيل المواقع إلى أو بين مثيلات متعددة المواقع. عمليات الترحيل متعددة المواقع لها تعقيدات فنية مختلفة ، ويمكن أن تساعد هذه الأداة في التخفيف منها.

يعد ترحيل موقع WordPress مستقل إلى بيئة شبكة موقع (أو "مواقع متعددة") مسعى شاقًا وصعبًا ، والعكس صحيح أيضًا. يعمل مستورد WordPress جيدًا بشكل معقول مع المواقع الأصغر والأبسط ، ولكنه يترك مجالًا للتحسين. يقوم بتصدير المحتوى ، ولكن ليس بيانات تكوين الموقع مثل تكوينات Widget و Customizer والمكونات الإضافية وإعدادات الموقع. يكافح المستورد أيضًا للتعامل مع كمية كبيرة من المحتوى. في هذه المقالة ، ستتعلم كيفية تبسيط هذا النوع من الترحيل باستخدام MU-Migration ، وهو مكون إضافي WP-CLI.

فهم تعدد المواقع

يتيح لك موقع WordPress متعدد المواقع تشغيل مواقع ويب متعددة في نفس تثبيت WordPress. غالبًا ما يشار إليها باسم "الشبكة متعددة المواقع". من المحتمل أن يكون WordPress.com أكبر مثال على شبكة متعددة المواقع ، حيث تقوم بتشغيل آلاف المواقع في نفس مثيل WordPress.

يمكن أن يكون موقع WordPress متعدد المواقع مناسبًا تمامًا للعديد من حالات الاستخدام ، وبعضها يشمل:

  • قد يكون لعميلك خصائص متعددة ، وقد يكون من المنطقي دمج جميع مواقعه في تثبيت WordPress فريد ، ومشاركة نطاق واحد ، ولكن ليس على سبيل الحصر.

  • بمجرد الانتهاء من إعداده ، ستكون عملية بسيطة ومباشرة لتدوير مواقع جديدة والاستفادة من السمات والمكونات الإضافية المتوفرة بالفعل في الشبكة

إن الفهم العميق لكيفية عمل المواقع المتعددة خارج نطاق هذه المقالة ، ولكن يمكنك التحقق من الروابط التالية:

  • "إنشاء شبكة ،" Codex ، WordPress.org

  • "مواقع WordPress المتعددة: الوظائف والأساليب العملية" ، كيفن ليري ، مجلة Smashing

المزيد بعد القفز! أكمل القراءة أدناه ↓

فهم التحديات

الاختلافات بين بنية موقع واحد و WordPress متعددة المواقع معقولة جدًا. مع المواقع المتعددة ، يحصل كل موقع فرعي على مجموعته الخاصة من جداول قاعدة البيانات ، باستثناء جدول المستخدم ( wp_user ) الذي يتم مشاركته عبر جميع المواقع. الطريقة التي يعمل بها هذا في WordPress هي أن كل مجموعة مواقع فرعية من الجداول تحتوي على معرف الموقع المضاف إلى اسم كل جدول ( wp_X_posts ، wp_X_postmeta ، wp_X_options ).

تقدم بنية قاعدة البيانات نفسها بالفعل بعض التعقيدات. على سبيل المثال ، كيف يمكنك ترحيل موقع فرعي من مواقع متعددة إلى تثبيت واحد؟ من الواضح أنه لا يمكنك فقط تصدير واستيراد قاعدة البيانات في التثبيت الفردي - أسماء الجداول مختلفة! قد تحتاج إلى إعادة تسمية الجداول في ملف .sql المُصدَّر أو استخدام استعلام ALTER TABLE SQL لإعادة تسمية الجداول بعد استيرادها. وينطبق الشيء نفسه على الطريقة المعاكسة: إذا كنت تقوم باستيراد موقع واحد إلى مواقع متعددة ، فسيتعين تحديث بادئات الجدول أيضًا. يبدو وكأنه الكثير من العمل ، أليس كذلك؟

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

أفضل حل هو تصدير المستخدمين بشكل منفصل ، لكنه يقدم مشكلة أخرى: عندما يتم استيراد المستخدمين سيحصلون على معرفات مختلفة. لحل هذه المشكلة ، من الضروري تتبع معرفات المستخدم الجديد ، وإنشاء جدول تعيين واستخدام جدول التعيين لتحديث جميع المراجع لمعرفات المستخدمين في WordPress! مرة أخرى ، الكثير من العمل ، أليس كذلك؟

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

تعرف على MU-Migration

MU-Migration هو مكون إضافي لـ WP-CLI قمت بإنشائه أثناء العمل على العديد من عمليات ترحيل العملاء ثم تم فتحه لاحقًا بواسطة 10up. تم تصميمه لتبسيط عملية نقل المواقع من مواقع WordPress الفردية إلى مثيل متعدد المواقع (أو العكس). يقوم بشكل أساسي بتصدير كل شيء إلى حزمة ZIP والتي يمكن استخدامها بعد ذلك لاستيراد الموقع في تثبيت WordPress المطلوب.

إنه يعمل عن طريق تصدير محتوى الموقع واختيار السمة والمكونات الإضافية وتحميل المجلدات في حزمة مضغوطة يمكن استيرادها بسهولة إلى تثبيت WordPress آخر. عند استخدام MU-Migration ، لا داعي للقلق بشأن التفاصيل الفنية الأساسية للترحيل. سيهتم بكل ذلك ببساطة من أجلك حتى تتمكن من التركيز على ما هو مهم: تقديم ترحيل ناجح لعملائك.

تثبيت WP-CLI و MU-Migration

لاستخدام MU-Migration ، تحتاج أولاً إلى تثبيت WP-CLI ، أداة سطر أوامر WordPress الرسمية. يعد تثبيت WP-CLI أمرًا بسيطًا مثل تشغيل الأوامر أدناه على الخادم الخاص بك:

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

بعد تنفيذ هذه الخطوات ، ستتمكن من تنفيذ WP-CLI عن طريق كتابة wp فقط من أي تثبيت WordPress ، طالما أنك داخل دليل جذر WordPress.

على سبيل المثال ، في مجلد تثبيت WordPress الخاص بك ، حاول تشغيل الأمر التالي:

 $ wp theme status

إنه أمر بسيط وسيدرج جميع السمات المتاحة ، مع إبراز أي منها نشط حاليًا.

أخيرًا ، لتثبيت MU-Migration ، يمكنك الاستفادة من أمر package install . استخدم الأمر التالي لتنزيل MU-Migration وتثبيته كمكوِّن إضافي WP-CLI.

 $ wp package install 10up/mu-migration

تشغيل عملية ترحيل بسيطة

استخدام MU-Migration بسيط للغاية. بالنسبة للسيناريو الأول ، سننقل موقع WordPress واحدًا إلى تثبيت WordPress متعدد المواقع.

تصدير الموقع الفردي

سنبدأ بتصدير الموقع الفردي. للقيام بذلك ، نحتاج إلى استخدام الأمر export all :

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

سيقوم الأمر أعلاه بتصدير الموقع بالكامل إلى حزمة ZIP ، وتكون العلامات - --plugins --themes و --uploads اختيارية وستتضمن السمة الحالية ، وجميع المكونات الإضافية ، ومجلد التحميلات ، على التوالي ، في التصدير. اعتمادًا على حجم موقعك ، قد يستغرق الأمر بعض الوقت لإنهاء العملية ، ولكن بالنسبة لمعظم المواقع ، يجب ألا تستغرق عملية التصدير أكثر من دقيقتين.

بمجرد الانتهاء ، سيتم إنشاء ملف يسمى single-site.zip يحتوي على جميع بيانات الموقع ، والقوالب ، والمكونات الإضافية بالإضافة إلى دليل التحميلات. الخطوة التالية هي نقله إلى الخادم حيث توجد مواقع WordPress المتعددة. يمكنك استخدام عميل SFTP المفضل لديك أو حل أكثر قوة مثل rsync .

استيراد الموقع الفردي إلى مواقع متعددة

مع الملف الذي تم تصديره في خادمك متعدد المواقع ، كل ما عليك فعله هو استخدام أمر الاستيراد من دليل WordPress متعدد المواقع ؛ وغني عن القول ، يجب تثبيت كل من WP-CLI و MU-Migration على الخادم الوجهة أيضًا.

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

سيأخذ الأمر أعلاه ملف single-site.zip ، ويستخرجه ويستورد كل شيء إلى مواقع متعددة. سيتم إنشاء موقع فرعي جديد في شبكتك. المعلمة --new_url اختيارية ؛ سيطلب من MU-Migration إجراء بحث واستبدال من أجل استبدال جميع تكرارات عنوان URL الخاص بالموقع المُصدَّر بالموقع المحدد. تكون هذه المعلمة مفيدة عندما يتضمن الترحيل تغييرًا في عنوان URL أو إذا كنت تقوم بالاستيراد محليًا ، أو حتى في بيئة مرحلية.

عادةً ما تستغرق عملية الاستيراد وقتًا أطول وتعتمد على حجم الموقع الذي تستورده ، ولكن لا تخف ، ستبقيك MU-Migration على اطلاع دائم أثناء تشغيل الترحيل. عند انتهاء العملية ، ستعلمك MU-Migration بعنوان URL النهائي لموقعك المستورد. يوصى بشدة بمسح جميع طبقات ذاكرة التخزين المؤقت التي تعمل على الخادم الخاص بك ، وخاصة Memcache أو Redis.

إعادة تشغيل الهجرة

عند إجراء عمليات الترحيل ، من الشائع إلى حد ما إجراء تشغيل تجريبي أولاً بغرض اختبار الأشياء قبل تشغيل الترحيل النهائي ، وهو ما يعني عادةً إجراء عملية تصدير أخرى وإعادة الاستيراد في التثبيت متعدد المواقع الوجهة. ومع ذلك ، لاحظ أنه في مثال الترحيل الأول لدينا ، أنشأت MU-Migration موقعًا فرعيًا جديدًا داخل الشبكة لاستيراد موقع واحد فوقه. سيؤدي تشغيل نفس الأمر بالضبط مرة أخرى إلى إنشاء موقع فرعي آخر ، وهو ليس بالضبط ما نتوقعه.

لحسن الحظ ، من الممكن تحديد blog_id ، والذي يخبر MU-Migration بتجاوز الموقع الفرعي مع blog_id المحدد. على سبيل المثال ، لنفترض أن أمر الاستيراد السابق أنشأ موقعًا فرعيًا برقم 2 كمعرف وتريد إعادة تشغيل الترحيل. يمكنك القيام بما يلي:

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

إذا كنت لا تعرف blog_id ، فيمكنك الحصول عليه من خلال إعدادات مسؤول الشبكة أو عن طريق تشغيل $ wp site list .

استخراج موقع فرعي من تركيب متعدد المواقع

يدعم MU-Migration أيضًا استخراج المواقع الفرعية من التركيبات متعددة المواقع واستيرادها إما إلى مواقع متعددة أخرى أو في موقع واحد.

بالنسبة لهذين السيناريوهين ، سنقوم بتشغيل أمر التصدير من تثبيت متعدد المواقع وليس من موقع واحد ؛ هذا يعني أننا بحاجة إلى طريقة لتحديد الموقع الفرعي الذي نريد تصديره. للقيام بذلك ، نحتاج فقط إلى تمرير المعلمة --blog_id إلى أمر التصدير:

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

في هذا المثال ، نقوم بتصدير موقع فرعي بمعرف يساوي 3 ؛ سيؤدي هذا إلى إنشاء ملف مضغوط جاهز لاستيراده إلى مواقع متعددة أخرى أو في موقع واحد. أمر الاستيراد إلى موقع واحد والمواقع المتعددة هو نفسه تمامًا ، وسوف تكتشف MU-Migration ما إذا كانت تعمل على مواقع متعددة أم لا وستقوم بتعديل نفسها على ذلك تلقائيًا. في ملاحظة جانبية ، عند الاستيراد إلى مثيل متعدد المواقع آخر ، يمكنك أيضًا تحديد المعلمة --blog_id لتجاوز موقع فرعي موجود.

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

نصائح لتشغيل هجرات كبيرة

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

قم بإنشاء خطة الترحيل

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

تتضمن خطة الترحيل النموذجية أشياء مثل:

  • تأثير الترحيل على أي عمليات تحرير إنتاجية (على سبيل المثال ، تجميد المحتوى ، متطلبات الترحيل التفاضلية).

  • ما هي المدة المتوقعة لعملية الترحيل؟

  • كيف سيتم استعادة النسخ الاحتياطية؟ كيف سيتم التعامل مع الترحيل الفاشل؟

  • كيف ستؤثر عملية التصدير على أداء الموقع؟ لا تستطيع العديد من المواقع تحمل تكلفة تصدير قاعدة البيانات خلال أوقات الذروة.

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

على الرغم من إهمالها مرات عديدة ، يمكن لخطة الترحيل المناسبة أن تتجنب مجموعة متنوعة من المشكلات المتعلقة بالهجرة. لا تدع الظروف غير المتوقعة تتسبب في فشل الترحيل ، فخطط للمستقبل! لمزيد من المناقشة المتعمقة حول التخطيط للترحيل ، أشجعك على مراجعة قسم الترحيل لأفضل ممارسات 10up.

استخدم Rsync لنسخ التحميلات تدريجيًا

يمكن أن يكون مجلد التحميلات للمواقع الكبيرة كبيرًا للغاية ، وضغطه في ملف ZIP للاستخراج لاحقًا ليس دائمًا الحل الأفضل والأسرع. هناك عدة طرق أخرى لنسخ مجلد التحميلات إلى الخادم الوجهة. تعتبر rsync أداة شائعة الاستخدام للترحيل مثل المؤسسات ، والتي يمكنها نقل الملفات بين الخوادم بشكل أسرع من استخدام حل SFTP القياسي ، وكإضافة ، يمكنها إيقاف عمليات النقل مؤقتًا واستعادتها. إنه يحتفظ بمسارات ما تم نقله بالفعل ، مما يعني أنه يمكننا مزامنة ملفاتنا تدريجيًا. على سبيل المثال ، يمكنك البدء في مزامنة الملفات قبل يومين من الترحيل الفعلي لتوفر لك بعض الوقت. وبعد ذلك ، في يوم الترحيل ، كل ما عليك فعله هو مزامنة الملفات للتأكد من نقل كل ما تمت إضافته منذ آخر مزامنة إلى الخادم الوجهة.

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

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

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

قم بإجراء التشغيل الجاف أولاً

قم دائمًا بالجري الجاف أولاً. من الناحية المثالية ، يجب أن يحدث التشغيل الجاف على الخادم الفعلي أو في بيئة مرحلية مع مكدس خادم مماثل.

ضع في اعتبارك استخدام --mysql-single-transaction

يدعم أمر الاستيراد أيضًا علامة --mysql-single-transaction التي ستلتف تصدير SQL في معاملة واحدة لارتكاب جميع التغييرات من الاستيراد دفعة واحدة ، مما يمنع الكتابة من إرباك خادم قاعدة البيانات ، خاصة في بيئات MySQL المجمعة.

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

باستخدام rsync ، يمكننا بسهولة نقل الملف المُصدر الذي تم إنشاؤه:

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

ثم نقوم بتشغيل أمر الاستيراد على الخادم الوجهة:

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

نحتاج الآن إلى معرفة blog_id الفرعي المنشأ حديثًا ؛ يمكننا الحصول على هذه المعلومات من خلال تشغيل:

قائمة مواقع $ wp
blog_id عنوان url التحديث الاخير مسجل
1 https://multisite.com/ 2017-09-09 20:59:31 2016-11-23 21:59:34
2 https://siglesite.com/ 2017-06-21 18:30:09 2017-04-25 13:07:46

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

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

سيقوم الأمر أعلاه بنسخ مجلد التحميلات بالكامل إلى المكان الصحيح على تثبيت متعدد المواقع ، والذي يوجد أسفل مجلد المواقع وداخل مجلد حيث يكون اسمه هو معرف الموقع فقط (في هذه الحالة ، 2). في هذه المرحلة ، يمكننا الآن تحرير ملف المضيف لتوجيه مجال الموقع الفردي إلى خادم متعدد المواقع ؛ ثم يمكننا إجراء بعض الاختبارات للتأكد من أن الترحيل يعمل على النحو المتوقع.

بالنسبة إلى الترحيل النهائي ، سيكون كل شيء كما هو ، باستثناء أننا --blog_id=2 إلى أمر الاستيراد:

 $ wp mu-migration import all site.zip --blog_id=2

وكميزة ، ستتم مزامنة التحميلات بشكل أسرع نظرًا لأن rsync لن يقوم إلا بنقل الملفات التي تم تغييرها أو إضافتها منذ آخر مزامنة.

خاتمة

يعد الترحيل من أو إلى مواقع متعددة أمرًا صعبًا ، كما أن الأداة المقدمة في هذه المقالة تبسط عملية الترحيل بأكملها عن طريق تقليل المحاولة إلى أمرين من أوامر CLI. تم استخدام MU-Migration بنشاط في الإنتاج لأكثر من عام وهو مشروع مفتوح المصدر بالكامل. تم تطوير البرنامج المساعد على Github وطلبات السحب مرحب بها!