متى يجب ألا تستخدم WordPress Multisite (والبديل الأفضل لذلك)
يبدو WordPress Multisite كأنه الحل البديهي في المرة الأولى التي تنظر فيها إلى عشرة تثبيتات للعملاء وعشر دورات تحديث. لوحة تحكم (dashboard) واحدة، تسجيل دخول واحد، مكان واحد لإدارة كل شيء. الفكرة تبدو رائعة.
تظهر المشكلة لاحقًا، وعادةً في أسوأ وقت ممكن: تحديث لإضافة (plugin) يوقف جميع مواقع العملاء في وقت واحد، أو يطلب عميل نقل موقعه إلى مكان آخر وتدرك أن عملية الاستخراج ستستغرق عطلة نهاية الأسبوع بأكملها. يُحسّن نظام Multisite للشبكات التي تعمل ككيان واحد. لكن معظم أعمال العملاء هي عكس ذلك: مُلّاك منفصلون، احتياجات منفصلة، ومخارج منفصلة، وهذا يوضح when not to use wordpress multisite في مشاريعك.
إليك الحالات المحددة التي يكون فيها Multisite هو القرار الخاطئ، وما الذي يتعطل في كل حالة، وإعداد العزل كأولوية الذي يجنبك هذه المشاكل كأفضل wordpress multisite alternative for client sites.
1. عندما يحتاج كل عميل إلى مجموعة مختلفة من الإضافات والقوالب
يشارك نظام Multisite مجلد wp-content واحدًا عبر كل موقع فرعي. يتم تثبيت الإضافات (plugins) على مستوى الشبكة، ثم يتم تفعيلها للشبكة أو تمكينها لكل موقع، لكنها جميعًا تعيش في نفس الملفات ويتم تحميلها من نفس المكان. الإضافة التي يحتاجها أحد العملاء ويجب ألا تعمل أبدًا لدى عميل آخر، لا تزال موجودة في الكود البرمجي المشترك لكليهما، مما يمثل أحد أبرز wordpress multisite disadvantages.
هذا القيد يواجهك باستمرار في عمل العملاء، حيث الفكرة الأساسية هي أن العميل (أ) يحصل على إضافة حجوزات، والعميل (ب) يحصل على نظام عضويات، ولا ينبغي لأي منهما أن يرث أعباء الآخر أو مساحة هجومه.
البديل: عزل حقيقي لكل tenant. يمنح إصدار GrabWP Tenancy Pro كل tenant مجلد wp-content خاص به، لذلك تكون القوالب (themes) والإضافات (plugins) منفصلة بشكل حقيقي لكل عميل بدلاً من مشاركتها وتبديلها. مجموعة إضافات أحد العملاء لا تؤثر على عميل آخر.
2. عندما يُحتمل أن يغادر العميل
هذه هي المشكلة التي تكلف الكثير بصمت. في نظام Multisite، يكون موقع العميل الواحد متشابكًا في قاعدة بيانات الشبكة مع جداول مشتركة ومعرفات مدونات. سحب موقع فرعي واحد لتسليمه إلى عميل، أو لنقله إلى استضافته الخاصة، هو عمل يتطلب التصدير وإجراء جراحة متعددة الخطوات، وأدوات تصدير Multisite معروفة بكونها هشة.
إذا كان أي جزء من عملك يتضمن إنهاء موقع وتسليمه، فإن Multisite قد بنى قيدًا سيتعين عليك محاربته في كل مرة، مما يجعلك تتساءل should i use wordpress multisite حقًا لإدارة العملاء؟
البديل: تصدير نظيف لكل tenant. يقوم GrabWP Tenancy Pro بنسخ احتياطي لكل tenant كأرشيف مستقل، وتقوم إضافة GrabWP Restore المجانية بإعادة بناء هذا الـ tenant كموقع WordPress مستقل وكامل على أي استضافة. تقوم أداة Restore ببث استيراد قاعدة البيانات، وتعيد كتابة بادئات الجداول لتتطابق مع الوجهة، وتشغل بحثًا واستبدالًا للروابط على مستوى قاعدة البيانات بالكامل والذي يتعامل بشكل صحيح مع البيانات المتسلسلة، ثم يقوم بتحديث رابط الموقع تلقائيًا. يغادر العميل بتثبيت WordPress طبيعي وبدون أي اعتماد عليك.
3. عندما يجب ألا تصبح مشكلة عميل واحد مشكلة للجميع
تم تصميم Multisite ببنية ذات مصير مشترك. قاعدة بيانات واحدة، شجرة ملفات واحدة، نواة واحدة. التحديث السيء لإضافة، أو الجدول التالف، أو الموقع الفرعي المخترق لا يتم احتواؤه: فهو يقع داخل نفس قاعدة البيانات ونظام الملفات مثل أي عميل آخر. لا يوجد نطاق ضرر طبيعي حول موقع واحد.
بالنسبة لشبكة هواة، قد تكون هذه مقايضة مقبولة. لكن بالنسبة لمجموعة من العملاء يدفع كل منهم مقابل بقاء موقعه يعمل، فهذه مسؤولية تتحملها نيابة عنهم.
البديل: قواعد بيانات مخصصة ونقاط استعادة لكل tenant. يتيح GrabWP Tenancy Pro لكل tenant العمل على بادئة MySQL مشتركة، أو قاعدة بيانات MySQL مخصصة بالكامل، أو قاعدة بيانات SQLite خاصة به، بحيث يمكن فصل بيانات الـ tenant تمامًا مع عدم وجود جداول مشتركة. يعمل سير عمل الاستعادة المكون من 8 خطوات لكل tenant على التراجع عن موقع عميل واحد من النسخة الاحتياطية الخاصة به دون المساس بأي tenant آخر. يوم سيء لموقع واحد يظل يومًا سيئًا لموقع واحد.
4. عندما تجعل استضافتك Multisite مؤلمًا (أو تمنعه)
العديد من شركات استضافة WordPress المُدارة إما لا تدعم Multisite، أو تقيده، أو تفرض رسومًا إضافية عليه. حتى في الأماكن التي يعمل فيها، فإن نظام Multisite المستند إلى النطاقات الفرعية يستدعي إعداد DNS وشهادات SSL شاملة مما يحول مهمة تستغرق خمس دقائق إلى تذكرة دعم فني.
البديل: توجيه لا يحتاج إلى بهلوانيات DNS. يدعم GrabWP Tenancy النطاقات المخصصة بالكامل لكل tenant والتوجيه المستند إلى المسار، حيث يعيش الـ tenant في yoursite.com/site/client-a بدون أي تغييرات DNS لكل عميل على الإطلاق. تحصل على استضافة مواقع متعددة على استضافة عادية لموقع واحد.
5. عندما تريد فعليًا كفاءة التثبيت الواحد بدون الارتباط
السبب الحقيقي الذي يجعل الناس يلجأون إلى Multisite ليس ميزات الشبكة. بل لأنهم لا يريدون تحديث نواة WordPress عشر مرات. هذا هدف مشروع، لكن Multisite يربطه بقواعد بيانات مشتركة، وإضافات مشتركة، وعملية فصل مؤلمة لم تطلبها أبدًا.
البديل: افصل الاثنين. تمنحك الاستضافة المتعددة (multi-tenancy) ميزة إدارة التثبيت الواحد، تحديث النواة مرة واحدة، لوحة تحكم واحدة، واستنساخ tenant أساسي لكل عميل جديد، مع الحفاظ على عزل التثبيتات المنفصلة. تحصل على الكفاءة بدون الارتباط.
مقارنة سريعة بين Multisite والتثبيتات المنفصلة والاستضافة المتعددة
| WordPress Multisite | التثبيتات المنفصلة | GrabWP Tenancy | |
|---|---|---|---|
| تحديثات النواة | مرة واحدة | لكل تثبيت | مرة واحدة |
| عزل البيانات | قاعدة بيانات مشتركة (البادئة + معرف المدونة) | كامل | كامل مع إصدار Pro (قاعدة بيانات مخصصة) |
| الإضافات/القوالب لكل عميل | مجلد wp-content مشترك | كامل | كامل مع إصدار Pro (مجلد wp-content معزول) |
| فصل العميل | استخراج معقد | بسيط | بسيط (تصدير من Pro + أداة Restore مجانية) |
| نطاق الضرر عند الفشل | جميع المواقع | موقع واحد | موقع واحد |
| متطلبات الاستضافة | مقيدة غالبًا | قياسي | قياسي (توجيه النطاق أو المسار) |
إذن، متى يكون Multisite مناسبًا؟
لكي نكون منصفين: يعد Multisite خيارًا جيدًا عندما تتصرف الشبكة كشيء واحد حقًا. جامعة تدير العشرات من مواقع الأقسام على قالب ومجموعة إضافات مشتركة، شركة إعلامية تدير إصدارات إقليمية لنفس المطبوعة، شبكة إنترانت داخلية لمواقع متطابقة تقريبًا تحت إشراف فريق تقنية معلومات (IT) واحد. علامة تجارية مشتركة، بيئة عمل مشتركة، مالك إداري واحد، ومعدل تغيير منخفض. إذا كان هذا يصف حالتك، فإن Multisite يقوم بالضبط بما تم بناؤه من أجله.
لكن عمل العملاء لا يكون كذلك أبدًا تقريبًا. العملاء المختلفون يريدون إضافات (plugins) مختلفة، ويمتلكون بياناتهم الخاصة، وسيغادرون في النهاية. في اللحظة التي تنطبق فيها مقولة “هذه المواقع هي في الحقيقة أعمال منفصلة أصدف أنني أديرها معًا”، فإن بنية Multisite المشتركة تعمل ضدك.
الإعداد الذي يريده معظم المستقلين والوكالات فعليًا
لإدارة مواقع عملاء مستقلة متعددة، تحقق الاستضافة المتعددة (multi-tenancy) الحل الوسط الذي يفتقده كل من Multisite والتثبيتات المنفصلة: إدارة مركزية مثل Multisite، وعزل حقيقي مثل التثبيتات المنفصلة، ومخرج نظيف لأي عميل في أي وقت.
الإضافة الأساسية GrabWP Tenancy مجانية وتمنحك مجلدات رفع ملفات معزولة، وبادئات جداول، وتوجيهًا عبر النطاق أو المسار. تضيف خطة Pro قواعد بيانات مخصصة، ومجلد wp-content لكل tenant، وعمليات نسخ احتياطي واستعادة لكل tenant بدءًا من $9.99/month.
إذا كنت تريد التفصيل المعماري الكامل، اقرأ مقارنة بين WordPress Multisite والاستضافة المتعددة (Multi-Tenancy). وإذا كنت مستعدًا لنقل موقع من شبكة موجودة، فراجع كيفية عزل مواقع عملاء WordPress بدون Multisite.
مقالات ذات صلة
الأسئلة الشائعة
- هل يعتبر WordPress Multisite الخيار الصحيح في بعض الأحيان؟
- نعم، لشبكة من المواقع التي تتشارك فعليًا نفس مجموعة الإضافات (plugin) والقوالب (theme) وفريق إدارة واحد، مثل شبكة أقسام جامعة أو سلسلة من مواقع الفروع المتطابقة تقريبًا. لكن Multisite هو خيار خاطئ عندما يحتاج كل موقع إلى إضافات مختلفة، أو بيانات منفصلة، أو عملية تسليم نظيفة لمالك مختلف، وهذا هو المعتاد في عمل العملاء.
- ما هو الخطر الرئيسي لتشغيل مواقع العملاء على WordPress Multisite؟
- المصير المشترك. تتشارك جميع المواقع الفرعية قاعدة بيانات واحدة ومجلد wp-content واحد، لذلك يمكن لتحديث إضافة سيء، أو جدول تالف، أو مشكلة أمنية أن تؤثر على كل موقع في وقت واحد. لا يوجد نطاق ضرر منفصل لكل موقع، وهو عكس ما تريده تمامًا عندما يدفع عملاء مختلفون مقابل بقاء مواقعهم تعمل.
- كيف تحصل على إدارة مركزية بدون قاعدة البيانات المشتركة في Multisite؟
- الاستضافة المتعددة (multi-tenancy). تشغل إضافة GrabWP Tenancy كل عميل كـ tenant معزول من تثبيت WordPress واحد. تحتفظ بلوحة تحكم (dashboard) واحدة ونواة واحدة للتحديث، ولكن كل tenant لديه بادئة جداول ومجلد رفع ملفات خاص به، ومع إصدار Pro، يحصل على قاعدة بيانات مخصصة بالكامل ومجلد wp-content خاص به.
Editorial standards: Our content is written by WordPress experts with hands-on multi-tenancy experience. Articles are fact-checked and regularly updated to ensure accuracy.