توقف عن المعاناة مع تعارضات إضافات WordPress Multisite: امنح كل عميل حزمة إضافات خاصة به

غالبًا ما يتم الترويج لـ WordPress Multisite على أنه الطريقة المثلى لتشغيل العديد من مواقع العملاء من تثبيت واحد. ولكن بالنسبة للإضافات، فإنه يقوم بهدوء بعكس ما تتوقعه الوكالات. يشارك Multisite مجلد wp-content واحدًا وقاعدة بيانات واحدة عبر كل موقع فرعي. تعيش ملفات الإضافات في مكان واحد للشبكة بأكملها. تلك الطبقة المشتركة الواحدة هي المكان الذي تبدأ فيه wordpress multisite plugin conflicts، ولا يوجد أي مقدار من التبديل على مستوى كل موقع يمكن أن يزيل هذه المشكلة.

لماذا تتسبب إدارة إضافات Multisite في التعارضات

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

هذا التمييز مهم أكثر مما يبدو. عبارة “مفعلة لكل موقع” لا تعني “معزولة”. إنها تعني أن نفس الكود المادي موجود لجميع المستأجرين (tenants) ويتم تشغيله ببساطة للبعض منهم. لا يمكنك منح موقعين فرعيين مجموعتين مختلفتين تمامًا ومعزولتين من الإضافات. إذا كان العميل أ يحتاج إلى الإصدار 4 من إضافة وكان العميل ب يحتاج إلى الإصدار 6، فلن يجد Multisite مكانًا لوضع كليهما. يفوز إصدار واحد، ويفوز للجميع. هذه هي المشكلة الأساسية مع wordpress multisite shared wp-content.

سيناريوهات حقيقية حيث تتسبب هذه المشكلة في أضرار

تحول الطبقة المشتركة المشاكل المحلية الصغيرة إلى مشاكل على مستوى الشبكة:

• إضافات غير متوافقة. يريد العميل أ إضافة حجوزات تستخدم نفس الفلاتر التي تستخدمها إضافة العضوية الخاصة بالعميل ب. في التثبيتات المنفصلة، لا توجد مشكلة. في Multisite، يتم تحميل كلا الإضافتين في نفس مساحة العملية، والخطأ الفادح الذي تطرحه إحداهما يظهر في جميع أنحاء الشبكة.
• تثبيت الإصدارات. يرفض عميل يشغل حزمة أقدم ومستقرة ترقية إضافة لأنها تعطل مسار العمل المخصص الخاص به. يحتاج عميل آخر إلى أحدث إصدار لإصلاح أمني. في قاعدة برمجية مشتركة، لا يمكنك تلبية كلا الطلبين.
• السطح الأمني. كل ملف إضافة موجود على الشبكة هو كود يمكن استغلاله، حتى على المواقع التي لم تقم بتفعيله مطلقًا. الإضافة الضعيفة الموجودة غير نشطة في wp-content المشترك لا تزال تُرسل مع كل موقع فرعي. السطح الهجومي هو اتحاد إضافات الجميع، وليس إضافات كل عميل على حدة.

يعود كل من هذه الأمور إلى نفس السبب الجذري: طبقة إضافات وقوالب مشتركة واحدة.

كيف يجب أن يبدو العزل لكل عميل في الواقع

العزل الحقيقي يعني أن إضافة العميل يتم تحميل الكود الخاص بها فقط لهذا العميل. إذا قام العميل أ بتثبيت أو تحديث أو كسر إضافة، فلن يتغير شيء بالنسبة للعميل ب. بشكل ملموس، يتطلب ذلك لـ isolate wordpress plugins per client:

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

لا يمكن لعلامة التفعيل لكل موقع في Multisite تقديم أي من هذا، لأن الملفات لا تتوقف أبدًا عن كونها مشتركة. إذا كنت تبحث عن per site plugins wordpress multisite، فإن Multisite القياسي لا يوفره حقًا.

كيف يقدم مجلد wp-content لكل مستأجر حزمًا منفصلة

هذه هي الفجوة التي تم بناء GrabWP Tenancy Pro لسدها. بدلاً من wp-content مشترك واحد، يمنح Pro كل مستأجر فصلاً كاملاً لـ wp-content: مجلد قوالب وإضافات معزول خاص به تحت مجلد المحتوى الخاص به. ينتهي الأمر بكل عميل بحزمة إضافات وقوالب منفصلة حقًا، وليس قاعدة برمجية مشتركة يتم تشغيلها وإيقافها.

نظرًا لأن الملفات منفصلة ماديًا، فإن سيناريوهات التعارض المذكورة أعلاه تتوقف ببساطة عن الحدوث. يمكن للعميل أ تشغيل الإصدار 4 من الإضافة بينما يشغل العميل ب الإصدار 6. يتم تحميل إضافة غير متوافقة فقط للمستأجر الذي قام بتثبيتها. لا تعد الإضافة الضعيفة الموجودة في مجلد مستأجر واحد جزءًا من السطح الهجومي لأي مستأجر آخر. يقوم Pro أيضًا بدمج هذا مع قاعدة بيانات MySQL أو SQLite مخصصة لكل مستأجر ونسخ احتياطي واستعادة لكل مستأجر، لذا فإن عزل البيانات يطابق عزل الكود.

يقوم GrabWP Tenancy plugin المجاني بالفعل بعزل التحميلات، وبادئات الجداول، وتوجيه النطاق أو المسار، ويمنحك لوحة تحكم واحدة لإنشاء المستأجرين وإدارتهم. مجلد wp-content الكامل لكل مستأجر، والذي يعني إضافات وقوالب معزولة، هو ميزة Pro. القاعدة المجانية تعزل التحميلات والبادئات، وليس ملفات الإضافات والقوالب، لذا استخدم Pro تحديدًا عندما تكون طبقة الإضافات هي المكان الذي تعيش فيه تعارضاتك.

إدارة العديد من الحزم المعزولة من لوحة تحكم واحدة

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

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

نقل عميل معرض للتعارضات إلى حزمة خاصة به

إليك سير عمل ملموس لذلك العميل الواحد الذي تستمر إضافاته في كسر شبكتك:

1. قم بتثبيت إضافة GrabWP Tenancy المجانية على تثبيت WordPress الخاص بك وتأكد من عمل عزل التحميلات والبادئات.
2. قم بالترقية إلى Tenancy Pro لفتح wp-content الكامل لكل مستأجر، ثم قم بإنشاء مستأجر للعميل صاحب المشكلة.
3. خذ نسخة احتياطية لكل مستأجر أولاً باستخدام النسخ الاحتياطي الموجه الجاهز للاستعادة في Pro، حتى يكون لديك نقطة تراجع نظيفة.
4. انقل إضافات العميل وقوالبه إلى مجلد الإضافات والقوالب المعزول الخاص بذلك المستأجر، بالإصدارات الدقيقة التي يحتاجون إليها.
5. قم بتثبيت إصداراتهم بشكل مستقل، دون القلق بشأن ما يشغله أي مستأجر آخر.
6. تحقق من صفحة الإضافات من أن حالة الإضافة والقالب الحية للمستأجر تتطابق مع ما قصدته.
7. استخدم قائمة انتظار التوجيهات من الموقع الرئيسي لتفعيل الإضافات الصحيحة وتبديل القالب، ثم تأكد من أن بقية المستأجرين لديك لم يتأثروا.

العميل الذي كان يهدد الشبكة بأكملها يعيش الآن في صندوق مغلق لا تزال تتحكم فيه مركزيًا.

المفاضلات ومتى يكون ذلك مهمًا

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

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

ابدأ بإضافة GrabWP Tenancy المجانية لعزل التحميلات، والبادئات، والتوجيه من لوحة تحكم واحدة. عندما تكون طبقة الإضافة والقالب هي المكان الذي تعيش فيه تعارضاتك، قم بالترقية إلى GrabWP Tenancy Pro مقابل 9.99 دولارًا شهريًا للحصول على wp-content كامل لكل مستأجر، بحيث يحصل كل عميل على حزمة إضافات وقوالب منفصلة حقًا والتي لا تزال تديرها مركزيًا.

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

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