لماذا Multisite بدلاً من N نسخة WordPress منفصلة
وكالة تدير خمسة عشر موقع WordPress على خمس عشرة تثبيتاً منفصلاً تواجه مشكلة توسع: خمس عشرة لوحة تحكم للمراقبة، وخمس عشرة دورة تحديث للتنسيق، وخمس عشرة إعداد خادم ويب للصيانة. إذا نشر إضافة حرجة تصحيحاً أمنياً، يجب تطبيقه خمس عشرة مرة — واحدة تلو الأخرى.
يحل WordPress Multisite هذه المشكلة من جذورها. تثبيت WordPress واحد يشغّل شبكة من المواقع (network). يمتلك كل عميل نطاقه الفرعي الخاص (client1.example.com، client2.example.com)، ومحتواه الخاص، ومستخدميه الخاصين، وإعدادات القالب الخاصة به. لكن ملفات WordPress الأساسية والإضافات والقوالب تتشارك وتُدار مركزياً من قِبل المدير الأعلى للشبكة.
على خادم VPS مخصص، يكتسب هذا النموذج معناه الكامل: تحدّ عزل الشبكة من سطح الهجوم، وتحتفظ بالتحكم الكامل في PHP وMariaDB وNginx.
ما تكسبه فعلياً
- تحديث واحد لـ WordPress core والإضافات وقوالب الشبكة — مطبّق في وقت واحد على جميع المواقع.
- نقطة إدارة واحدة: يشرف المدير الأعلى على جميع المواقع من
/wp-admin/network/. - تخزين وسائط مشتركة اختياري لكل موقع — شارك الموارد أو اعزلها وفق عقود عملائك.
- توفير موارد الخادم: عملية PHP-FPM واحدة، ونسخة كاش كائن واحدة، واتصال MariaDB واحد للضبط.
- إعداد أسرع للعملاء الجدد: إنشاء موقع فرعي يعني فقط ملء نموذج في الشبكة، وليس توفير خادم.
- نسخ احتياطية مركزية: تغطي عملية تفريغ MariaDB واحدة جميع المواقع، ويمكن جدولتها بقاعدة cron واحدة.
المتطلبات الأساسية: موارد VPS الموصى بها لـ 5 إلى 15 موقعاً نشطاً
تعتمد الموارد المطلوبة على حركة المرور وتعقيد المواقع — وليس على عدد التثبيتات. لشبكة من 5 إلى 15 موقع WordPress نشطاً (مواقع عرض أو مدونات بحركة مرور معتدلة، بدون WooCommerce مكثف)، التوصية التحريرية المستندة إلى وثائق WordPress وNginx/MariaDB هي:
- المعالج: 2 vCPU كحد أدنى؛ 4 vCPU بمجرد دمج تخزين الصفحات مؤقتاً مع حركة المرور المتزامنة.
- الذاكرة العشوائية (RAM): 4 غيغابايت كحد أدنى؛ 8 غيغابايت موصى به عند تفعيل كاش كائن Redis مع PHP-FPM.
- التخزين: SSD NVMe، 40 غيغابايت كحد أدنى لملفات WordPress والوسائط وسجلات MariaDB؛ يُعدَّل حسب حجم وسائط العملاء.
- PHP: PHP 8.2 أو 8.3 (بلغ PHP 8.1 نهاية الدعم النشط مع نهاية عام 2024).
- MariaDB: 10.6 LTS أو 10.11 LTS.
- خادم الويب: Nginx مع كتل server لكل نطاق فرعي وـ DNS wildcard.
إذا تجاوزت محفظتك 15 موقعاً أو تضمنت متاجر WooCommerce، ففكر في تقسيم شبكة Multisite إلى قسمين أو البدء بـ 8 غيغابايت / 4 vCPU.
تفعيل WordPress Multisite وإعداد Nginx للنطاقات الفرعية
إعداد DNS Wildcard
قبل إجراء أي تعديلات على WordPress، أضف سجل DNS wildcard على نطاقك الرئيسي:
*.example.com A <IP_خادم_VPS>يوجّه هذا السجل جميع النطاقات الفرعية إلى خادم VPS الخاص بك. بدونه، ستظل المواقع الفرعية في الشبكة غير متاحة من المتصفح، حتى لو أنشأها WordPress بشكل صحيح.
السماح بوضع الشبكة في wp-config.php
حرّر
wp-config.phpفي جذر تثبيت WordPress وأضف السطر التالي قبل/* That's all, stop editing! */:define( 'WP_ALLOW_MULTISITE', true );هذا الثابت هو الشرط الموثق في الوثائق الرسمية لـ WordPress لتفعيل معالج تثبيت الشبكة.
إنشاء الشبكة من لوحة التحكم
سجّل دخولك إلى
/wp-admin/، وانتقل إلى الأدوات ← تثبيت الشبكة. اختر النطاقات الفرعية (يلزم وجود DNS wildcard). أدخل عنوان الشبكة وعنوان البريد الإلكتروني للمسؤول، ثم انقر على تثبيت.سيزودك WordPress بكتلتَي كود لإدراجهما في
wp-config.phpوفي.htaccess (Apache) أو في ملف إعداد Nginx. انسخهما بدقة.تكييف إعداد Nginx للنطاقات الفرعية الـ wildcard
على Nginx، كتلة
.htaccessالتي يوفرها WordPress لا تُقرأ. استبدلها بكتلةserverمخصصة. إليك الإعداد الأدنى لشبكة نطاقات فرعية:server { listen 80; server_name example.com *.example.com; root /var/www/wordpress; index index.php; # Multisite subdomain rewrite if (!-e $request_filename) { rewrite /wp-admin$ $scheme://$host/wp-admin/ permanent; rewrite ^(/[^/]+)?(/wp-.*) $2 last; rewrite ^(/[^/]+)?(/.*\.php) $2 last; } location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { fastcgi_pass unix:/run/php/php8.3-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }أعد تحميل Nginx:
systemctl reload nginx. ثم انتقل إلى HTTPS بإنشاء شهادة wildcard مع Certbot باستخدام تحدي DNS-01 — شهادة SAN*.example.comتغطي جميع المواقع الفرعية في الشبكة.إتمام إعداد WordPress Multisite في wp-config.php
أضف الثوابت التي يوفرها المعالج إلى
wp-config.php(عدّل القيم وفق تثبيتك):define( 'MULTISITE', true ); define( 'SUBDOMAIN_INSTALL', true ); define( 'DOMAIN_CURRENT_SITE', 'example.com' ); define( 'PATH_CURRENT_SITE', '/' ); define( 'SITE_ID_CURRENT_SITE', 1 ); define( 'BLOG_ID_CURRENT_SITE', 1 );سجّل خروجك ثم عد للدخول. تعرض لوحة التحكم الآن قائمة الشبكة في شريط الإدارة. من الشبكة ← المواقع ← إضافة جديد، أنشئ موقعك الفرعي الأول للعميل:
client1.example.com.تفعيل إضافات الشبكة وتعيين القوالب
في الشبكة ← الإضافات، فعّل الإضافات لكل الشبكة (تفعيل على الشبكة) أو اترك مسؤولي المواقع الفرعية يفعّلونها بأنفسهم. تعمل القوالب بنفس الطريقة: يتيحها المدير الأعلى، ويختار كل موقع فرعي قالبه الخاص.
ملاحظة مهمة: بعض الإضافات لا تدعم وضع الشبكة. تحقق من التوافق في وثائق الإضافة قبل تفعيلها على الشبكة — إضافة غير متوافقة قد تحجب لوحة تحكم جميع المواقع الفرعية في وقت واحد.
Multisite مقابل نسخ WordPress منفصلة: جدول مقارنة
مرّر الجدول أفقيًا
| المعيار | WordPress Multisite | نسخ منفصلة |
|---|---|---|
| تحديث WordPress core | عملية واحدة لـ N موقع | N عملية يدوية |
| تحديث إضافة | عملية شبكة واحدة | N عملية، خطر عدم المزامنة |
| عزل بيانات العميل | جزئي (نفس قاعدة MariaDB، بادئات مختلفة) | كامل (قواعد بيانات مختلفة، عمليات PHP مختلفة) |
| تخزين الوسائط | مشترك افتراضياً، قابل للعزل بإضافة | معزول بشكل طبيعي |
| موارد الخادم | مشتركة — توفير في RAM وCPU | تراكمية — كل نسخة تستهلك حصتها |
| إضافة غير متوافقة مع الشبكة | قد تحجب جميع المواقع | تؤثر على نسخة واحدة فقط |
| إعداد موقع جديد | نموذج في الشبكة — ثوانٍ | توفير كامل — دقائق إلى ساعات |
| شهادة SSL wildcard | شهادة واحدة `*.example.com` | شهادة لكل نطاق عميل |
أمان Multisite على VPS: الحد من تأثير الثغرات
الاعتراض الأكثر شيوعاً على WordPress Multisite صحيح: إذا تعرضت إضافة ضعيفة للاختراق، فإن سطح الهجوم المحتمل يغطي الشبكة بأكملها، وليس موقعاً واحداً فقط. على خادم VPS مخصص، تُقلل عدة إجراءات من هذا التأثير:
نسخ احتياطية يومية تلقائية. تفريغ MariaDB مجدول كل ليلة (cron + mysqldump أو mariabackup) يمنحك نقطة استعادة حديثة لكل موقع فرعي. خزّن عمليات التفريغ خارج خادم VPS — على bucket متوافق مع S3 أو وحدة تخزين عن بُعد.
جدار حماية تطبيقي. يرشح WAF على Nginx (ModSecurity أو قواعد OWASP) الطلبات الضارة قبل وصولها إلى PHP. ادمجه مع fail2ban لحظر عناوين IP التي تحاول القوة الغاشمة على /wp-login.php.
تحديثات فورية. قوة Multisite — تحديث واحد للمحفظة بأكملها — هي أيضاً أفضل دفاع لك: طبّق تصحيحات أمان WordPress والإضافات في يوم نشرها. بدون Multisite، يكون تأخر تحديث نسخة منسية هو الثغرة الأكثر استغلالاً.
صلاحيات محدودة للمدير الأعلى. حساب المدير الأعلى للشبكة له صلاحيات على جميع المواقع. استخدم مصادقة ثنائية على هذا الحساب وأنشئ حسابات مسؤول موقع فرعي منفصلة لكل عميل.
استكشاف الأخطاء: ثلاثة أخطاء شائعة على شبكة WordPress Multisite
1. إضافة مُبلَّغ عنها كـ«غير متوافقة مع وضع الشبكة».
تتحقق بعض الإضافات صراحةً مما إذا كان WordPress يعمل في وضع Multisite وترفض التفعيل على الشبكة. السبب غالباً استخدام $wpdb->blogid أو خيارات مخزنة بطريقة غير متوافقة مع جداول كل موقع فرعي المُعرَّفة ببادئات. الحل: تحقق من مشكلات GitHub الخاصة بالإضافة، وابحث عن بديل متوافق، أو فعّل الإضافة فقط على المواقع الفرعية التي تحتاجها (إذا سمحت الإضافة بذلك) بدلاً من مستوى الشبكة.
2. صفحة إدارة الشبكة غير متاحة (/wp-admin/network/ تعيد التوجيه إلى لوحة التحكم العادية).
المدير الأعلى ليس نفس مستخدم مسؤول الموقع الرئيسي. عند إنشاء الشبكة، يضيف WordPress علامة super_admin للمستخدم النشط. إذا أنشأت الشبكة بحساب ثم سجلت دخولك بحساب آخر، فهذا الحساب الثاني لن يرى قائمة الشبكة. تحقق في MariaDB:
SELECT meta_value FROM wp_usermeta
WHERE meta_key = 'wp_user_level'
AND user_id = <معرف_حسابك>;للترقية إلى مدير أعلى: استخدم دالة grant_super_admin( $user_id ) من ملف في مجلد mu-plugins.
3. نطاقات فرعية غير متاحة: DNS wildcard لا ينتشر فوراً.
بعد إضافة *.example.com A <IP>، تحدد مدة TTL للسجل وقت الانتشار. خلال هذه الفترة، تُرجع المواقع التي أُنشئت في الشبكة خطأ DNS في المتصفح — WordPress أنشأها بشكل صحيح، لكن المحلل لا يعرف النطاق الفرعي بعد. إذا كنت تعمل محلياً مع خادم VPS للتطوير، أضف سجلاً في /etc/hosts على جهازك لكل نطاق فرعي تريد اختباره: <IP_VPS> client1.example.com.
حالة رابعة تحدث مع إعدادات www / بدون www المختلطة: إذا كان كل من example.com وwww.example.com يشيران إلى خادم VPS، فتأكد أن DOMAIN_CURRENT_SITE في wp-config.php يطابق تماماً النطاق الرئيسي بدون بادئة www، وأن Nginx يعيد توجيه صيغة www إلى الصيغة الأساسية قبل تمرير الطلب إلى WordPress.
نقل المواقع الحالية إلى شبكة Multisite
إذا كنت تدير بالفعل مواقع WordPress منفصلة وتريد دمجها في شبكة Multisite، فإن إضافة WordPress Importer (الإضافة الرسمية) تصدّر المحتويات والتعليقات والمستخدمين من كل نسخة مصدر، ثم تستوردها إلى موقع فرعي في الشبكة.
ثلاث نقاط للانتباه قبل النقل:
- ملفات الرفع لا تُنقل تلقائياً. انسخ مجلد wp-content/uploads/ من كل موقع مصدر إلى wp-content/uploads/sites/<ID>/ في الشبكة (يُعيَّن المعرف بواسطة WordPress عند إنشاء الموقع الفرعي).
- تحقق من توافق إضافات الشبكة قبل التبديل: قد لا تعمل إضافة نشطة على الموقع القديم في وضع الشبكة. أدرج إضافات كل موقع مصدر وقارنها مع قائمة إضافات الشبكة المتاحة.
- اختبر إعادة توجيه النطاقات. إذا كان الموقع المنقول يمتلك نطاقه الخاص (www.client1.com)، فقم بإعداد وحدة WordPress MU Domain Mapping أو ميزة النطاق المخصص الأصلية لتوجيه client1.example.com نحو www.client1.com — أو العكس حسب اختيارك.
الإطلاق في الإنتاج: خطوات التحقق قبل فتح الموقع لعملائك
قبل نقل مواقع عملائك الأولى إلى الشبكة، راجع هذه النقاط:
- اختبر إنشاء موقع فرعي عبر client1.example.com وتحقق من إمكانية الوصول إليه من متصفح خارجي.
- تحقق من أن شهادة wildcard تغطي *.example.com: openssl s_client -connect client1.example.com:443 -servername client1.example.com | grep subject.
- محاكاة تحديث إضافة الشبكة والتحقق من بقاء جميع المواقع الفرعية تعمل.
- خطط واختبر الاستعادة لموقع فرعي من تفريغ MariaDB: الاستعادة غير المختبرة ليست نسخة احتياطية.
- وثّق إجراء الإعداد لعملائك: عنوان URL للإدارة، وبيانات الاعتماد، والصلاحيات الممنوحة لحساب مسؤول الموقع الفرعي.
خادم ServOrbit VPS مُعدٌّ لمحفظة WordPress الخاصة بك يمنحك التحكم الكامل في مكدس التقنيات بأكمله — PHP وMariaDB وNginx والنسخ الاحتياطية — بدون طبقة تجريد تخفي الأخطاء.
