عزل تعدد المستأجرين (Multi-Tenancy Isolation)

يدعم Ultimate Multisite الإصدار 1.2.0 العزل الخاص بقاعدة البيانات ونظام الملفات لكل موقع فرعي (subsite) للمستأجرين السياديين (sovereign tenants). هذا يحافظ على فصل بيانات المستأجرين مع الحفاظ على التوفير على مستوى الشبكة، والفواتير، والإدارة.

استراتيجية العزل (Isolation strategy)

استخدم العزل السيادي للعملاء الذين يحتاجون إلى فصل أقوى للبيانات، أو تخزين نظام ملفات مخصص، أو حدود مضيف منفصل.

يجب أن يتوفر لكل مستأجر سيادي ما يلي:

• قاعدة بيانات مستأجر مخصصة أو استراتيجية بادئة (prefix) لقاعدة البيانات معتمدة للمضيف.
• جذر نظام ملفات (filesystem root) مخصص للمستأجر.
• إدخال في سجل المستأجر يربط الموقع بقاعدة البيانات الخاصة به، ومسار الجذر، واسم المضيف (hostname)، ونموذج العزل.
• نتيجة تحقق من الترحيل (migration verification result) قبل اعتبار المستأجر جاهزًا للعمل فعليًا.

ربط مضيف قاعدة البيانات (Database host binding)

يُجري الإصدار 1.2.0 تغييرًا في سلوك الربط الافتراضي للمضيف على نفس الجهاز للتثبيتات السيادية. يتم توحيد القيم التي تشير إلى نفس الجهاز مثل localhost بحيث يمكن لـ Bedrock و FrankenPHP وتثبيتات WordPress المحتواة (containerized) منح والتحقق من الأذونات مقابل سلسلة المضيف التي يراها MySQL فعليًا.

عند إعداد مستأجر سيادي:

1. قم بتعيين مضيف قاعدة البيانات إلى القيمة المطلوبة بواسطة وقت تشغيل المستأجر (tenant runtime).
2. استخدم localhost للتثبيتات المحلية للمقبس (socket installs) عندما يتوقع المضيف اتصالات محلية.
3. استخدم 127.0.0.1 أو اسم مضيف خدمة فقط عندما يمنح خادم قاعدة البيانات الامتيازات لذلك المضيف.
4. قم بتشغيل التحقق من الترحيل بعد تغيير ربط المضيف (host binding).

إذا أظهر تقرير التحقق فشلاً في منح الأذونات، قارن بين منح المستخدم لقاعدة بيانات المستأجر وربط المضيف المُعد. فالمستخدم الذي مُنح له صلاحية لـ user@localhost يختلف عن [email protected] أو user@%.

جذر نظام الملفات (Filesystem root)

يجب أن يكون جذر المستأجر (tenant root) مستقراً عبر عمليات إعادة التشغيل والنشر. تجنب مسارات التثبيت المؤقتة. بالنسبة للتثبيتات على نمط Bedrock، تأكد من أن جذر المستأجر يشير إلى جذر الويب الخاص بـ WordPress المتوقع بواسطة تشغيل البداية للمستأجر (tenant bootstrap)، وليس فقط جذر المشروع.

ترتيب التوفير (Provisioning order)

بالنسبة للمستأجر السيادي الجديد، استخدم هذا الترتيب:

1. إنشاء إدخال سجل المستأجر (tenant registry entry).
2. إنشاء قاعدة بيانات المستخدم وقاعدة البيانات الخاصة بالمستأجر.
3. تهيئة مخطط المستأجر (bootstrap the tenant schema).
4. توفير مستخدمي المستأجر.
5. تكوين مسارات نظام ملفات المستأجر.
6. تشغيل التحقق من الترحيل (migration verification).
7. تغيير التوجيه أو DNS بعد اجتياز التحقق.

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

تدفق إدارة العملاء السياديين (Sovereign customer management flows)

تحتفظ Ultimate Multisite v2.13.0 بإجراءات إدارة العملاء على الموقع الرئيسي عندما يتم تمكين الوضع السيادي (sovereign mode). لا يزال بإمكان المستأجر العمل كتثبيت WordPress معزول، ولكن يجب أن ترسل الإجراءات التي تتطلب واجهة العميل وتعتمد على الفوترة عبر الشبكة أو العضوية أو بيانات الحساب المشترك العميل مرة أخرى إلى الموقع الرئيسي بدلاً من محاولة إكمال الإجراء داخل وقت تشغيل المستأجر.

ينطبق تدفق الموقع الرئيسي على ما يلي:

• عمليات الدفع وتغييرات الخطة (Checkout and plan changes).
• نظرة عامة على الحساب وإجراءات ملف تعريف العميل (Account overview and customer profile actions).
• تحديث عناوين الفواتير وشاشات إدارة المدفوعات (Billing address updates and payment-management screens).
• طرق عرض الفواتير وسجل الدفع (Invoice and payment-history views).
• إجراءات إدارة الموقع مثل إضافة مواقع أو حذف موقع (Site management actions such as adding sites or deleting a site).
• تبديل القوالب (Template switching).
• تعيين النطاق وتغييرات النطاق الأساسي (Domain mapping and primary-domain changes).

عندما يبدأ العميل أحد هذه الإجراءات من مستأجر سيادي (sovereign tenant)، يقوم Ultimate Multisite ببناء رابط الموقع الرئيسي المقابل ويحتفظ بالمستأجر المصدر كوجهة للعودة عندما يكون ذلك آمناً. يتيح هذا للعملاء إكمال الإجراء المُدار مقابل سجلات الشبكة، ثم العودة إلى سياق المستأجر دون تكرار حالة الفوترة أو العضوية في قاعدة بيانات المستأجر السيادي.

بالنسبة للمشغلين (operators)، القاعدة العملية هي: يجب إبقاء صفحات الفوترة، والحساب، والدفع (checkout)، والفاتورة، والقالب، وإدارة النطاق متاحة على الموقع الرئيسي للشبكات السيادية. يمكن لوحات تحكم المستأجر أن تربط بتلك الصفحات، لكن الموقع الرئيسي يظل هو المصدر الحقيقي للإجراء.