كيفية نقل موقع عميل واحد خارج شبكة WordPress Multisite

إذا كنت تدير وكالات أو استضافة على WordPress Multisite، فإن هذه اللحظة لا مفر منها: عميل يتجاوز حجم الشبكة ويريد تطبيق move site off wordpress multisite، أو يرغب في نقل موقعه إلى استضافته الخاصة، أو تحتاج ببساطة إلى عزله لأغراض الفوترة والدعم. نظرياً، يبدو إجراء extract single site from multisite وكأنه عملية تصدير تستغرق خمس دقائق. لكن عملياً، إنها واحدة من أكثر المهام فوضوية في WordPress. يوضح هذا الدليل سير العمل الدقيق لتتمكن من split subsite from multisite network واستخراجه بشكل نظيف، ثم إعادة بنائه كموقع مستقل يمكن للعميل امتلاكه. يمثل هذا الدليل مرجعاً شاملاً لنجاح أي عملية wordpress multisite to single site migration.

1. لماذا تعتبر عملية استخراج موقع فرعي واحد مؤلمة للغاية

الموقع الفرعي في Multisite ليس موقعاً قائماً بذاته. بل هو مجموعة من الجداول ذات البادئات (مثل wp_5_posts و wp_5_options وما إلى ذلك) والتي تشارك جداول عامة للمستخدمين (users) وبيانات المستخدمين الوصفية (usermeta) وإعدادات الشبكة. تمنحك شاشة Tools > Export المدمجة ملف XML يحتوي فقط على المقالات والصفحات والوسائط. لكنها تترك وراءها:

• المستخدمين وأدوارهم، والتي تعيش في الجداول العامة المشتركة
• إعدادات الإضافات (plugins) والقوالب (themes) المخزنة في جدول options الخاص بالموقع الفرعي
• الجداول المخصصة التي تم إنشاؤها بواسطة إضافات النماذج أو التجارة الإلكترونية أو العضويات
• البيانات المتسلسلة (Serialized data) التي يكون فيها مسار أو عنوان URL للموقع الفرعي القديم مضمناً بداخلها

إذا قمت بإعادة البناء من ملف XML هذا وحده، فستقضي أياماً في إعادة إنشاء الحسابات، وإعادة تكوين الإضافات، والبحث عن الروابط المعطلة. الهدف بدلاً من ذلك هو الحصول على نسخة كاملة متطابقة لكل بايت (byte-for-byte) لبيانات هذا الموقع الفرعي فقط، ثم إجراء استعادة نظيفة (clean restore) في تثبيت لم يكن أبداً Multisite.

2. اختر البنية المستهدفة

قرر أين سيعيش الموقع المستخرج قبل أن تقوم بالتصدير. هناك نتيجتان جيدتان:

• تثبيت مستقل لموقع واحد (single-site). تثبيت WordPress عادي على استضافة العميل الخاصة أو استضافتك. هذا هو الخيار المستقل تماماً وهو الخيار الذي يريده العملاء عادةً عندما يغادرون.
• مستأجر (tenant) معزول في GrabWP. إذا كنت ترغب في الاحتفاظ بالفوائد التشغيلية لقاعدة تعليمات برمجية واحدة (codebase) ولكن مع فصل حقيقي، فقم بإعادة توطين الموقع كمستأجر باستخدام إضافة GrabWP Tenancy المجانية. يحصل كل مستأجر على مجلد رفع معزول (isolated uploads)، وبادئة جدول (table prefix) خاصة به، وتوجيه قائم على المسار أو النطاق، على سبيل المثال yoursite.com/site/client-a بدون أي تغييرات في DNS.

في كلتا الحالتين، الهدف هو سياق موقع واحد (single-site)، وليس شبكة Multisite أخرى. هذا الأمر مهم لخطوة الاستعادة أدناه.

3. تصدير بيانات الموقع الفرعي

الطريقة النظيفة لالتقاط كل شيء هي إجراء نسخ احتياطي لكل مستأجر (per-tenant backup) من GrabWP Tenancy Pro. تُنتج ميزة النسخ الاحتياطي الخاصة به أرشيف التصدير الذي تقرؤه أداة الاستعادة: حزمة كاملة من قاعدة بيانات الموقع ومجلد wp-content الخاص به، وليس مجرد تفريغ XML.

1. في بيئة المصدر، قم بتشغيل النسخ الاحتياطي (backup) الخاص بالمستأجر للموقع الفرعي الذي تقوم بنقله.
2. يعمل النسخ الاحتياطي المكون من 7 خطوات مع شريط تقدم AJAX حتى تتمكن من مشاهدته وهو يكتمل.
3. قم بتنزيل ملف ZIP الناتج عن التصدير. هذا الأرشيف هو العنصر الوحيد الذي ستحمله إلى الموطن الجديد.

هذا الأمر مهم لأن أداة GrabWP Restore تقبل فقط ملفات ZIP التي تم إنتاجها بواسطة ميزة النسخ الاحتياطي في GrabWP Tenancy Pro. إنها ليست أداة استيراد عامة لنسخ احتياطية عشوائية، وهذا القيد هو ما يجعل عملية الاستعادة قابلة للتوقع.

4. أعد بناءه بشكل نظيف مع GrabWP Restore

قم بإعداد تثبيت WordPress جديد لموقع واحد (single-site) في الوجهة المستهدفة، ثم قم بتثبيت إضافة GrabWP Restore المجانية.

1. انتقل إلى Tools > GrabWP Restore (للمسؤولين فقط).
2. قم برفع ملف تصدير ZIP من الخطوة 3.
3. أكد إقرار النسخ الاحتياطي الصريح الذي تطلبه الإضافة قبل أن تستمر في العمل.
4. قم بتشغيل عملية الاستعادة المكونة من 8 خطوات وشاهد تقدم AJAX.

خلف الكواليس، تقوم أداة الاستعادة (Restore) بالعمل الشاق الذي تُخطئ فيه عمليات النقل اليدوية: استيراد متدفق (streaming) لملفات SQL يتعامل مع قواعد البيانات الكبيرة دون استنفاد الذاكرة، وإعادة كتابة تلقائية لـ table prefix بحيث تتطابق الجداول الواردة مع الوجهة المستهدفة، وتوافق ترتيب النصوص (collation compatibility) مع MySQL 5.7 و 8.0 حتى لا يتعطل الاستيراد بسبب عدم تطابق مجموعات الأحرف (charset).

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

5. التحقق من عناوين URL والبيانات المتسلسلة (serialized data)

هذا هو المكان الذي تنهار فيه عمليات النقل الساذجة. تتم كتابة عنوان URL أو المسار للموقع الفرعي القديم في مئات الصفوف، بما في ذلك المصفوفات المتسلسلة (serialized arrays) التي تؤدي عملية بحث واستبدال بسيطة إلى إتلافها. تتعامل أداة GrabWP Restore مع هذا نيابةً عنك:

• التحديث التلقائي لعنوان URL للموقع يقوم بتعيين عناوين URL الخاصة بالصفحة الرئيسية والموقع إلى الوجهة الجديدة.
• البحث والاستبدال لعناوين URL على مستوى قاعدة البيانات بالكامل يعيد كتابة العنوان القديم في كل مكان، بما في ذلك البيانات المتسلسلة والمشفرة بواسطة القالب، بحيث تستمر تخطيطات منشئ الصفحات، وخيارات الودجات (widgets)، وإعدادات الإضافات في العمل بشكل صحيح.

بعد انتهاء عملية الاستعادة، قم بإجراء فحص سريع للنتيجة:

1. قم بتسجيل الدخول وتأكد من انتقال حساب المسؤول (admin) والأدوار الخاصة بك.
2. افتح صفحة تم إنشاؤها باستخدام منشئ الصفحات الخاص بك وتأكد من عرض الصور والوحدات (modules).
3. ابحث في الواجهة الأمامية (front end) عن أي إشارات متبقية لمسار /subsite القديم.
4. تأكد من عمل الملفات المرفوعة (uploads)، حيث تقوم أداة الاستعادة بإجراء استعادة آمنة للملفات والتي تعيد تسمية أي مجلدات موجودة لـ plugins و themes و uploads إلى .old قبل كتابة المجلدات الجديدة، لذلك لا يتم الكتابة فوق أي شيء بصمت.

6. تسليم الموقع أو إعادة توطينه كمستأجر معزول

في هذه المرحلة، لديك مساران واضحان:

• تسليمه للعميل. التثبيت المستقل أصبح ملكاً للعميل بالكامل. قم بنقل بيانات اعتماد الاستضافة وبذلك تكون قد انتهيت. لا توجد جداول مشتركة، ولا يوجد أي اعتماد على الشبكة.
• إعادة التوطين كمستأجر معزول. احتفظ به على البنية التحتية التي تديرها، ولكن كمستأجر (tenant) مستقل. مع GrabWP Tenancy Pro، يمكن لكل مستأجر استخدام MySQL prefix مشتركة، أو قاعدة بيانات MySQL مخصصة، أو SQLite، ويحصل على مجلد wp-content معزول خاص به. هذا هو الفصل الحقيقي للدعم والفوترة، دون ارتباط الجداول المشتركة الذي جعل عملية الاستخراج مؤلمة في المقام الأول.

7. تجنب هذا الألم في المرة القادمة

السبب الذي يجعل هذه المهمة صعبة هو البنية المعمارية: تقوم Multisite بربط كل موقع فرعي بجداول عامة مشتركة. إذا كنت تتوقع مجيء العملاء وذهابهم، فابدأ معهم في بنية عزل للبيانات حيث يكون كل موقع مستقلاً بالفعل. تشغيل العملاء كمستأجرين في GrabWP يعني أن كل واحد منهم لديه بالفعل مجلد رفع معزول (isolated uploads)، و prefix خاص به، وتوجيه (routing) مستقل، لذلك فإن عبارة “إخراج العميل” تصبح “تشغيل نسخة احتياطية واحدة واستعادة واحدة” بدلاً من وظيفة فك تشابك تستغرق عدة أيام.

ابدأ الآن

يعمل سير عمل الاستخراج أعلاه على أدوات مجانية بالإضافة إلى جزء واحد مدفوع: GrabWP Restore و GrabWP Tenancy مجانيان، بينما تعد ميزة النسخ الاحتياطي لكل مستأجر التي تُنتج أرشيف التصدير القابل للاستعادة جزءاً من GrabWP Pro بسعر $9.99/month. إذا كنت لا تزال تزن ما إذا كانت Multisite تناسب وكالتك على الإطلاق، فاقرأ مقال متى يجب عدم استخدام WordPress Multisite بعد ذلك.

مقالات ذات صلة

• تسليم موقع WordPress مكتمل لعميلك دون احتكار
• متى يجب ألا تستخدم WordPress Multisite (والبديل الأفضل لذلك)
• كيفية عزل مواقع عملاء WordPress بدون Multisite