أنشئ شبكة مواقع ووردبريس متعددة بسهولة

الحاجة / مشكلة الخادم

إذا سبق لك أن رأيت موقعًا متعدد المواقع يستجيب بشكل متكرر بخطأ 301، فقم بتقديم سيئة الموقع على النطاق الصحيح، أو تعطيل الوسائط (404 على /wp-content/uploads/sites/)، نادراً ما تأتي المشكلة من WordPress نفسه. يأتي ذلك دائمًا تقريبًا من طبقة الخادم: نظام أسماء النطاقات (DNS)، أو المضيف الافتراضي (vhost)، أو بروتوكول أمان طبقة النقل (TLS)، أو قواعد إعادة الكتابة، أو ذاكرة التخزين المؤقت.

شبكة ووردبريس (ووردبريس 6.9.4، أبريل) 2026يتيح لك هذا استضافة مواقع متعددة باستخدام نواة ووردبريس واحدة، ومجموعة واحدة من الإضافات/القوالب (مع تفعيل الشبكة)، وقاعدة بيانات مشتركة. إنه فعال للغاية... بشرط أن تقوم بتهيئة الخادم كخادم وكيل عكسي وموجه للمواقع، وليس كموقع واحد فقط.

بنهاية هذا الدرس، ستتعلم كيفية: اختيار النطاقات الفرعية مقابل المجلدات الفرعية، وإعداد مضيف افتراضي قوي (Nginx أو Apache)، وتفعيل خاصية المواقع المتعددة عبر wp-config.php، تطبيق قواعد إعادة الكتابة الصحيحة، وإدارة الشبكة بشكل يومي باستخدام WP-CLI، وقبل كل شيء الترحيل / الاستعادة دون كسر ربط النطاق بالموقع.

ملخص سريع

• النطاقات الفرعية : يتطلب استخدام أحرف البدل في نظام أسماء النطاقات (DNS) وغالبًا شهادة أحرف البدل؛ وهو أكثر مرونة في ربط النطاقات.
• الدلائل الفرعية الأمر أبسط من ناحية نظام أسماء النطاقات/بروتوكول أمان طبقة النقل، ولكن احذر من تعارضات عناوين URL وقواعد إعادة الكتابة.
• يجب على الخادم الحفاظ على Host وتشغيل ووردبريس على جهاز واحد document_root مع إعادة كتابة المواقع المتعددة.
• WP-CLI هي "لوحة التحكم" الخاصة بك: إنشاء الموقع، والتخطيط، والبحث/الاستبدال، ومسح ذاكرة التخزين المؤقت.
• هجرة تصدير SQL + الملفات + تحديث الجدول wp_blogs/wp_site + البحث/الاستبدال المستهدف، وإلا ستتلف عناوين URL.
• مخبأ : نسخة "متغيرة" ذات ذاكرة تخزين مؤقتة ضعيفة بواسطة Host يقوم الموقع A بالوصول إلى النطاق B. وهذا شائع في حالة سوء تكوين Nginx fastcgi_cache.

قبل البدء (المتطلبات الأساسية)

الوصول والأدوات

• SSH على الخادم (أو على الأقل واجهة سطر أوامر على الحاوية).
• WP-CLI (موصى به). المرجع: أوامر WP-CLI.
• الولوج إلى ماي / MariaDB ل سطر الأوامر (mysql, mysqldump).
• الوصول إلى الملفات (SFTP/rsync). تجنب استخدام بروتوكول نقل الملفات (FTP) في عام 2026 إن أمكن.

إصدارات الخادم الموصى بها (2026)

• WordPress : 6.9.4 (أنت تملكه بالفعل).
• PHP 8.1+ (8.2/8.3 شائع جدًا). ​​المرجع: إصدارات PHP المدعومة.
• MySQL 8.0+ أو MariaDB ل : 10.6+ (تجنب الإصدارات الأقدم، خاصة فيما يتعلق بالأداء والوجبات الخفيفة).
• إنجن إكس ou Apache (كلاهما يعمل، لكن Nginx غالباً ما يكون من الأسهل "تثبيته" في ذاكرة التخزين المؤقت).

يلزم إجراء نسخ احتياطي (واختبار الاستعادة)

لا تختبر خاصية المواقع المتعددة في بيئة الإنتاج دون استعادة مُعتمدة. لقد رأيتُ مرارًا عمليات نقل بيانات حيث wp-config.php إذا تم تعديلها، فمن المستحيل التراجع عنها لأن قاعدة البيانات أصبحت "متعددة المواقع" جزئيًا.

# Chemin WordPress (adaptez)
cd /var/www/example.com/public

# 1) Sauvegarde fichiers (hors cache)
tar --exclude='./wp-content/cache' --exclude='./wp-content/uploads/cache' 
  -czf /root/backup-files-$(date +%F).tar.gz .

# 2) Sauvegarde base (adaptez DB_NAME/DB_USER)
# Astuce : récupérez les infos depuis wp-config.php
mysqldump --single-transaction --quick --routines --triggers 
  -u'wp_user' -p'wp_pass' wp_db > /root/backup-db-$(date +%F).sql

الخطوة 1: اختر وضع المواقع المتعددة (النطاقات الفرعية مقابل الدلائل الفرعية)

الدلائل الفرعية

مثال: example.com/site1, example.com/site2من جانب الخادم، الأمر في غاية البساطة: نطاق واحد، بدون نظام أسماء نطاقات عام، بدون شهادة عامة.

• الميزة: إعداد سريع، عدد أقل من متغيرات الشبكة.
• العيب: إذا كان موقعك الرئيسي يستخدم بالفعل عناوين URL "محجوزة"، يمكنك خلق التصادمات (على سبيل المثال، صفحة) /blog وموقع /blog).

النطاقات الفرعية

مثال: site1.example.com, site2.example.comغالباً ما يكون هذا هو الخيار الأفضل إذا كنت تخطط لـ... تعيين النطاق (السابق : client-a.com يشير إلى موقع على الشبكة).

• الميزة: العزل حسب المضيف، وتنظيف التخزين المؤقت والخوادم الوكيلة.
• العيوب: يتطلب أحرف البدل في نظام أسماء النطاقات (DNS) (*.example.com) ومن الأفضل رمز TLS البديل.

التوافق مع Divi 5 / Elementor / Avada

تدعم جميعها بيئات المواقع المتعددة، لكن الواقع العملي يكمن في إدارة التراخيص والمكتبات العالمية. أما بالنسبة لشبكات العملاء، فأوصي بما يلي:

• فعّل أداة إنشاء الصفحات لكل موقع (غير متصل بالشبكة) إذا كنت ترغب في الحد من تأثير الخطأ.
• احتفظ بموقع "تجريب داخلي" على الشبكة لاختبار التحديثات الخاصة بالمنشئ والوحدات النمطية.

الخطوة الثانية: تجهيز نظام أسماء النطاقات (DNS) والمضيف الافتراضي (vhost) وبروتوكول أمان طبقة النقل (TLS) (باستخدام الأحرف البديلة إذا لزم الأمر)

نظام أسماء النطاقات (النطاقات الفرعية)

يجب عليك إنشاء سجل عام. مثال (توضيحي):

• A : example.com → عنوان IP للخادم
• A : *.example.com → عنوان IP للخادم

بدون استخدام رمز البدل، سيقوم ووردبريس بإنشاء المواقع، لكن نظام أسماء النطاقات لن يعمل، وستضيع وقتك في تشخيص مشكلة "ووردبريس لا يعمل".

بروتوكول أمان طبقة النقل (TLS) (Let's Encrypt / wildcard)

تتطلب شهادة Let's Encrypt ذات النطاق الفرعي عادةً اجتياز اختبار DNS (بحسب إعداداتك). إذا تعذر استخدام شهادة ذات نطاق فرعي، فإن البديل العملي هو استخدام شهادة متعددة النطاقات للنطاقات الفرعية المعروفة، ولكن سرعان ما يصبح هذا الأمر معقدًا.

Vhost: جذر مستند واحد

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

الخطوة 3: تفعيل خاصية المواقع المتعددة بشكل صحيح (wp-config.php)

التفعيل عملية من خطوتين: (1) السماح بتثبيت الموقع المتعدد، (2) إدخال ثوابت الشبكة. تبقى الوثائق الرسمية هي المرجع. تركيب متعدد المواقع.

1) السماح بالتثبيت في مواقع متعددة

أضف هذا إلى wp-config.phpمن الأفضل أن يكون ذلك فوق خط "إيقاف التحرير" مباشرة.

<?php
// Autorise l'écran "Configuration du réseau" dans l'admin.
// À retirer éventuellement après installation si vous voulez verrouiller le setup.
define( 'WP_ALLOW_MULTISITE', true );

/* C'est tout, ne touchez pas à ce qui suit ! */

2) التثبيت عبر المسؤول (بدون لقطات شاشة)

بعد ذلك، في لوحة تحكم ووردبريس (الإدارة)، تقوم بإنشاء ثوابت المواقع المتعددة. لن أرفق لقطة شاشة، لكن النتيجة النهائية هي شفرة التمسك بها wp-config.php وإعادة صياغة القواعد لتطبيقها.

نقطة ملموسة: اختر النطاقات الفرعية ou المجلدات الفرعية الآن. من الممكن تغيير ذلك لاحقاً، لكنه يتطلب عملية نقل (نظام أسماء النطاقات، عناوين المواقع الإلكترونية، ملفات تعريف الارتباط)، وليس مجرد تبديل بسيط.

ثوابت نموذجية متعددة المواقع (مثال)

مثال لشبكة ذات نطاقات فرعية على example.comقم بتكييف النطاق والمسارات.

<?php
// --- Configuration Multisite (WordPress 6.9.4+) ---

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );

// Domaine et chemin "racine" du réseau.
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );

// Site principal (blog_id) et réseau (site_id).
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

// Optionnel : si vous êtes derrière un proxy/Load Balancer
// et que vous gérez HTTPS au niveau du proxy.
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
	$_SERVER['HTTPS'] = 'on'; // Force WordPress à générer des URLs en https
}

خطأ شائع: النسخ إلى المكان الخطأ

أرى في كثير من الأحيان ثوابت المواقع المتعددة ملتصقة ببعضها البعض بعد سطر "إيقاف التحرير". في هذه الحالة، لا يقرأه ووردبريس، وينتهي بك الأمر بلوحة تحكم "تنسى" اتصال الشبكة مع كل تحديث. احتفظ به قبل نهاية الملف.

الخطوة الرابعة: قواعد إعادة الكتابة (Nginx/Apache) ومصائد ذاكرة التخزين المؤقت

إليك ما يحدث في الخفاء: يقوم ووردبريس بتوجيه المواقع الفرعية عبر عنوان URL و/أو المضيف، ولكن يجب على الخادم أولاً إرسال جميع الطلبات "غير المتعلقة بالملفات" إلى index.phpفي بيئة متعددة المواقع، توجد قواعد محددة إضافية لـ wp-admin وبالنسبة لعمليات التحميل "للموقع".

Nginx: نقاط لا تقبل المساومة

• الكتلة server_name يجب أن يغطي النطاق و (إذا كانت نطاقات فرعية) الحرف العام.
• Le try_files يجب إعادة التوجيه إلى /index.php مع الحجج.
• الوصول إلى /wp-admin يجب التعامل مع الشرطة المائلة الأخيرة.

أباتشي: انتبه إلى ملف .htaccess و AllowOverride

Si AllowOverride معطل، جهازك .htaccess لا جدوى من ذلك. النتيجة المعتادة: لوحة التحكم تعمل، لكن جميع المواقع الفرعية تُظهر خطأ 404. تحقق من إعدادات Apache، وليس ملف الإعدادات فقط.

مصيدة ذاكرة التخزين المؤقت (fastcgi_cache / proxy_cache)

الخطأ الكلاسيكي: لا تتغير ذاكرة التخزين المؤقت بواسطة $host. نتيجة ل، site1.example.com يقوم بتخزين الصفحة الرئيسية مؤقتًا، ثم site2.example.com يستقبل الصفحة الرئيسية للموقع 1. لقد صادفت هذا في مجموعات تم "تحسينها" يدويًا.

إذا كنت تستخدم التخزين المؤقت لـ Nginx، فيجب أن يتضمن المفتاح $scheme$host$request_uri على الأقل.

الخطوة 5: إدارة الشبكة بشكل يومي باستخدام WP-CLI

يُعد WP-CLI الطريقة الأكثر موثوقية لإدارة الشبكة بدون تجاوز بواسطة شاشات تحجب التفاصيل. وثيقة: موقع ووردبريس et شبكة ووردبريس.

قم بإدراج المواقع ومراجعتها

cd /var/www/example.com/public

# Liste des sites
wp site list --fields=blog_id,url,registered,last_updated,public,archived,deleted,spam

# Détails d'un site (blog_id = 3)
wp site get 3

إنشاء موقع ويب

# Sous-domaines : --slug crée site3.example.com
wp site create --slug=site3 --title="Site 3" [email protected]

# Sous-répertoires : --slug crée example.com/site3
wp site create --slug=site3 --title="Site 3" [email protected]

تفعيل/تعطيل إضافة على مستوى الشبكة بأكملها

# Activation réseau (mu-plugins mis à part)
wp plugin activate --network redis-cache

# Désactivation réseau
wp plugin deactivate --network redis-cache

قم بتحديث ووردبريس والإضافات (بحذر)

في شبكة متعددة المواقع، يؤثر تحديث الإضافة "العالمي" على جميع المواقع. أتبع عادةً إجراء التحديث في بيئة الاختبار، ثم في بيئة الإنتاج مع وجود نافذة زمنية وخيار للتراجع جاهز.

# Core
wp core update
wp core update-db

# Plugins et thèmes
wp plugin update --all
wp theme update --all

البحث/الاستبدال (الترحيل، HTTPS، التعيين)

Le search-replace هي الأداة التي تنقذ... وهي الأداة التي تدمر إذا استخدمتها في المكان الخطأ. اصنع --dry-run أولا.

# Exemple : passage http -> https sur tout le réseau
wp search-replace 'http://example.com' 'https://example.com' --all-tables --network --dry-run

# Puis exécution réelle
wp search-replace 'http://example.com' 'https://example.com' --all-tables --network

خطأ واقعي: نسيان الشبكة

بدون --networkلا يمكنك تعديل سوى الموقع الحالي (بحسب السياق)، وينتهي بك الأمر بشبكة "مختلطة" حيث لا تزال بعض المواقع تُنشئ عناوين URL من نوع HTTP. يصعب تصحيح هذا الخطأ لأنه يُشبه ذاكرة التخزين المؤقت.

الخطوة 6: تجهيز وترحيل واستعادة موقع متعدد

تتم عملية ترحيل المواقع المتعددة كما لو كانت موقعًا واحدًا، باستثناء وجود قيود إضافية: جداول متعددة (wp_2_options, wp_3_postsإلخ)، جدول التوجيه (wp_blogsوأحيانًا تعيين النطاق. يجب أن يكون الخادم جاهزًا قبل لاستيراد قاعدة البيانات.

أنشئ نسخة تجريبية (نسخة احتياطية) عبر SSH + MySQL + rsync

نهج بسيط وقوي: استنساخ الملفات + قاعدة البيانات، ثم ضبط النطاق وTLS.

# 1) Copier les fichiers (exemple vers /var/www/staging)
rsync -aHAX --delete 
  --exclude='wp-content/cache/' 
  /var/www/example.com/public/ 
  /var/www/staging.example.com/public/

# 2) Dumper la base prod
mysqldump --single-transaction --quick 
  -u'wp_user' -p'wp_pass' wp_db > /root/prod.sql

# 3) Importer dans la base staging
mysql -u'stg_user' -p'stg_pass' stg_db < /root/prod.sql

تكييف مجال الشبكة (الحالة الأكثر شيوعاً)

إذا كان تجهيزك قيد التشغيل staging.example.comغالباً ما تصبح شبكة النطاقات الفرعية الخاصة بك *.staging.example.comخياران:

• الخيار أ: أنت تحتفظ DOMAIN_CURRENT_SITE à example.com ويمكنك فرض المضيفين عبر /etc/hosts (عملي محليًا، وأقل فائدة على الخادم).
• الخيار ب: أنت تغير DOMAIN_CURRENT_SITE وتحديث قاعدة البيانات (أكثر واقعية في بيئة اختبار الخادم).

بالنسبة للخيار ب، يجب عليك على الأقل تحديث الجدول wp_site et wp_blogs (بادئة متغيرة). مثال SQL (مع تعديل البادئة والنطاقات):

mysql -u'stg_user' -p'stg_pass' stg_db

-- Remplacez wp_ par votre préfixe réel
UPDATE wp_site SET domain = 'staging.example.com' WHERE id = 1;

-- Sous-domaines : met à jour les domaines de chaque site
UPDATE wp_blogs
SET domain = REPLACE(domain, '.example.com', '.staging.example.com')
WHERE domain LIKE '%.example.com';

-- Site principal (souvent example.com sans sous-domaine)
UPDATE wp_blogs
SET domain = 'staging.example.com'
WHERE blog_id = 1;

ثم قم بـ search-replace بالنسبة لعناوين URL المخزنة في المحتوى (مع توخي الحذر).

wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables --network --dry-run
wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables --network

الاستعادة (العودة إلى الحالة السابقة): استراتيجية واقعية

• يعيد ملفات + قاعدة معًا (تجنب خلط ملفات J-1 مع ملفات J المرفوعة).
• إذا كنت تستخدم Redis/Object Cache، فقم بمسحه بعد الاستعادة (وإلا فأنت تستخدم خيارات قديمة).

# Exemple : purge Redis si vous utilisez un cache objet Redis
redis-cli FLUSHDB

ملفات التكوين الكاملة

الأمثلة أدناه جاهزة للنسخ واللصق، ولكن يُرجى تعديل المسارات، ومنافذ PHP-FPM، والنطاقات، وسياسات TLS. أُقدّم لكم Nginx. et أباتشي، لأن كليهما لا يزال موجودًا إلى حد كبير في عام 2026.

Nginx: كتلة خادم المواقع المتعددة (النطاقات الفرعية)

# /etc/nginx/sites-available/example.com.conf
server {
    listen 80;
    listen [::]:80;

    server_name example.com *.example.com;

    # Redirection vers HTTPS (adaptez si vous terminez TLS ailleurs)
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name example.com *.example.com;

    root /var/www/example.com/public;
    index index.php;

    # --- TLS (exemple) ---
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Taille upload (Multisite = médias, donc on évite 2M par défaut)
    client_max_body_size 128m;

    # Sécurité basique (voir section sécurité pour plus)
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options SAMEORIGIN always;
    add_header Referrer-Policy strict-origin-when-cross-origin always;

    # Logs
    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log warn;

    # --- WordPress Multisite rewrites ---
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Évite les redirections bizarres sur /wp-admin
    location = /wp-admin {
        return 301 /wp-admin/;
    }

    # PHP
    location ~ .php$ {
        include snippets/fastcgi-php.conf;

        # Adaptez : socket php-fpm ou host:port
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;

        # Important : évite certaines attaques PATH_INFO
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # Bloque l'exécution PHP dans uploads (fréquent vecteur d'infection)
    location ~* ^/wp-content/uploads/.*.php$ {
        deny all;
    }

    # Cache statique long (attention : plugins de cache peuvent gérer autrement)
    location ~* .(css|js|jpg|jpeg|png|gif|webp|svg|ico|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000, immutable";
        try_files $uri =404;
    }
}

أباتشي: ملف .htaccess متعدد المواقع (المجلدات الفرعية)

يفترض هذا الملف أن mod_rewrite نشطة وأن AllowOverride All مسموح به على المضيف الافتراضي.

# /var/www/example.com/public/.htaccess
# --- WordPress Multisite (sous-répertoires) ---
RewriteEngine On
RewriteBase /

# Protège wp-config.php (utile si mal configuré ailleurs)
<Files wp-config.php>
  Require all denied
</Files>

# Évite index.php dans l'URL
RewriteRule ^index.php$ - [L]

# Ajoute le slash final à /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

# Si le fichier/dossier existe, on sert directement
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

# Uploads multisite (sous-répertoires) : route via WordPress
RewriteRule ^wp-content/uploads/(.*)$ wp-includes/ms-files.php?file=$1 [L]

# Tout le reste vers WordPress
RewriteRule . index.php [L]

ملف wp-config.php: أساسي + متعدد المواقع + تحسين أمان خفيف

مقتطف "كامل" (باستثناء المفاتيح الفريدة) يركز على المواقع المتعددة. لا تنسخ أسرارك في مقال: احتفظ بها لنفسك. AUTH_KEY إلخ. المرجع: الفسفور الابيض بين config.php ل.

<?php
// --- Base de données ---
define( 'DB_NAME', 'wp_db' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'changez-moi' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

// Préfixe (attention : en Multisite, il reste unique pour le réseau)
$table_prefix = 'wp_';

// --- Debug (en staging, pas en prod) ---
// define( 'WP_DEBUG', true );
// define( 'WP_DEBUG_LOG', true );
// define( 'WP_DEBUG_DISPLAY', false );

// --- Durcissement raisonnable ---
define( 'DISALLOW_FILE_EDIT', true ); // Évite l'éditeur de fichiers dans l'admin

// --- Autorise l'écran d'installation Multisite (optionnel après setup) ---
define( 'WP_ALLOW_MULTISITE', true );

// --- Multisite ---
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 );

// Si vous êtes derrière un reverse proxy qui termine le TLS
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
	$_SERVER['HTTPS'] = 'on';
}

// --- Mémoire PHP (si vous maîtrisez votre hébergement) ---
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

/* C'est tout, ne touchez pas à ce qui suit ! */
if ( ! defined( 'ABSPATH' ) ) {
	define( 'ABSPATH', __DIR__ . '/' );
}
require_once ABSPATH . 'wp-settings.php';

ملف php.ini (أو ملف PHP-FPM conf): إعدادات مفيدة للمواقع المتعددة

في المواقع المتعددة، تُعدّ حدود وقت التحميل والتنفيذ السبب الرئيسي لمشكلة "تعطل الموقع عند تحميل قالب إلى الشبكة". مثال بسيط (يُرجى تعديله ليناسب بيئة التطوير لديك):

; Exemple : /etc/php/8.3/fpm/conf.d/99-wordpress.ini
memory_limit = 512M
upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 120
max_input_time = 120
max_input_vars = 5000

; Sécurité
expose_php = Off

التحقق

تحقق من حل DNS وTLS

# DNS
dig +short example.com
dig +short site1.example.com

# TLS + Host correct
curl -I https://example.com/
curl -I https://site1.example.com/

تأكد من أن ووردبريس "يرى" الشبكة

cd /var/www/example.com/public

# Affiche des infos réseau si Multisite actif
wp core is-installed
wp site list

تحقق من وجود عمليات إعادة كتابة (أعراض نموذجية)

• Si /wp-admin إعادة توجيه متكررة: مشكلة في رؤوس HTTPS/proxy أو مشكلة أخرى siteurl.
• إذا أعاد موقع فرعي خطأ 404 في جميع الصفحات باستثناء الصفحة الرئيسية: فهذا يعني وجود خطأ في إعادة كتابة عناوين URL في Nginx/Apache، أو try_files غائب.
• إذا أعادت الوسائط خطأ 404: قواعد تحميل المواقع المتعددة مفقودة، أو الأذونات/المسارات.

اختبار MySQL المستهدف

mysql -u'wp_user' -p'wp_pass' wp_db -e "
SELECT blog_id, domain, path, public, archived, deleted, spam
FROM wp_blogs
ORDER BY blog_id ASC
LIMIT 20;
"

إذا لم ينجح الأمر

عندما يتعطل نظام المواقع المتعددة، يكون رد الفعل الصحيح هو التشخيص من الأسفل إلى الأعلى: DNS → TLS → vhost → PHP-FPM → WordPress → ذاكرة التخزين المؤقت.

مخطط التشخيص (الأعراض الفعلية)

عرض	السبب المحتمل	التحقق	الحلول
يعرض النطاق الفرعي الموقع الرئيسي	لا يوجد حرف بدل في نظام أسماء النطاقات (DNS) أو أن المضيف الظاهري (vhost) ليس حرف بدل.	dig site2.example.com, nginx -T | grep server_name	إضافة *.example.com إلى نظام أسماء النطاقات (DNS) وإلى server_name
حلقة إعادة التوجيه 301/302 إلى /wp-admin	تم اكتشاف بروتوكول HTTPS بشكل خاطئ خلف خادم وكيل	curl -I و شاهد Location:	تكوين X-Forwarded-Proto + قوة $_SERVER['HTTPS']='on' اذا لزم
خطأ 404 في جميع صفحات المواقع الفرعية	قواعد إعادة الكتابة مفقودة / تم تجاهل ملف .htaccess	أباتشي: تحقق AllowOverrideNginx: تحقق try_files	قم بتطبيق قواعد المواقع المتعددة الصحيحة
الوسائط معطوبة (خطأ 404 في التحميلات)	قواعد التحميل متعددة المواقع مفقودة أو الأذونات غير متوفرة	اختبر ملفًا مباشرًا بالإضافة إلى سجلات Nginx/Apache	إضافة قواعد uploads + الأذونات الصحيحة
يقدم النطاق B محتوى النطاق A	لا تختلف ذاكرة التخزين المؤقت للخادم باختلاف المضيف	فحص رؤوس ذاكرة التخزين المؤقت + إعدادات ذاكرة التخزين المؤقت	inclure $host في مفتاح ذاكرة التخزين المؤقت، قم بالتنظيف

السجلات المراد قراءتها (في المكان الصحيح)

# Nginx
tail -n 200 /var/log/nginx/example.com.error.log
tail -n 200 /var/log/nginx/example.com.access.log

# PHP-FPM (chemin variable selon distro)
tail -n 200 /var/log/php8.3-fpm.log

# WordPress debug log (si activé)
tail -n 200 /var/www/example.com/public/wp-content/debug.log

تحقق من الأذونات (التحميلات، التحديثات)

الصلاحيات الصارمة جدًا تُعطّل عمليات التحميل، بينما الصلاحيات الواسعة جدًا تُعرّضك للخطر. الحل الوسط الشائع: المجلدات بصلاحيات 755، والملفات بصلاحيات 644، والمالك هو مستخدم مجموعة PHP-FPM.

cd /var/www/example.com/public

# Adaptez www-data au user de votre serveur/PHP-FPM
chown -R www-data:www-data .

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

الأخطاء الشائعة والمزالق

خطأ	سبب	الحلول
ألصق ثوابت المواقع المتعددة بعد عبارة "إيقاف التحرير".	لا يستطيع ووردبريس قراءة الإعدادات	حرك define() قبل نهاية الملف
انسَ أمر نظام أسماء النطاقات ذي الأحرف البديلة للنطاقات الفرعية	لا تحل المواقع الفرعية المشكلة	إضافة *.domaine جانب نظام أسماء النطاقات + المضيف الظاهري
الاختبار في بيئة الإنتاج بدون نسخ احتياطي/استعادة	لا رجعة إلى الوراء	اختبار تفريغ SQL + أرشفة الملفات + استعادة الملفات
ذاكرة تخزين مؤقتة لـ Nginx لا تختلف باختلاف المضيف	مفتاح ذاكرة التخزين المؤقت غير مكتمل	inclure $host في المفتاح، تطهير
الروابط الدائمة "معطلة" بعد عملية النقل	إعادة الكتابة من جانب الخادم غير متوافقة	متحقق try_files/.htaccess + مسح ذاكرة التخزين المؤقت
استخدم مقتطفًا قديمًا تم العثور عليه في عام 2017	افتراضات قديمة (PHP، بروكسي، أمان)	ارجع إلى وثائق ووردبريس الرسمية 6.9.x وقم بتكييفها مع PHP 8.1+
التحميلات 413 حجم ملف الطلب كبير جدًا	حد Nginx/PHP	client_max_body_size + upload_max_filesize/post_max_size
تم تعطيل المقتطف بواسطة إضافة المقتطفات	خطأ في بناء الجملة (فاصلة منقوطة، قوسان)	انشر عبر Git/SSH، ثم تحقق من صحة البيانات. php -l قبل

أمان الخادم

يُضاعف إعداد المواقع المتعددة من تأثير الثغرة الأمنية: فالإضافة المُعرّضة للثغرة والمُفعّلة عبر الشبكة تُؤثر على جميع المواقع. على جانب الخادم، أقوم بتأمين ثلاثة جوانب بشكل منهجي: تنفيذ PHP في عمليات التحميل، ونقاط النهاية الحساسة، ورؤوس الرسائل.

حظر استخدام PHP في عمليات التحميل (Nginx/Apache)

لقد اطلعت بالفعل على قاعدة Nginx أعلاه. بالنسبة لـ Apache، أضف هذا إلى ملف vhost أو .htaccess في wp-content/uploads (و AllowOverride (يسمح بذلك). الخطر: إذا قام مهاجم بتحميل .phpيجب ألا يتم تنفيذه أبداً.

# /var/www/example.com/public/wp-content/uploads/.htaccess
<FilesMatch ".php$">
  Require all denied
</FilesMatch>

رؤوس HTTP (الأساسية)

تجنب التحميل الزائد باستخدام سياسة أمان المحتوى (CSP) "النسخ واللصق" التي تُعطل Elementor/Divi/فتحابدأ برؤوس آمنة وغير متطفلة.

# Extraits Nginx (déjà partiellement inclus plus haut)
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options SAMEORIGIN always;
add_header Referrer-Policy strict-origin-when-cross-origin always;

عزل الشبكة وحقوق المسؤول

• قلل عدد المشرفون المتميزونهذا هو المكافئ الرئيسي على جانب ووردبريس.
• تجنب تفعيل المكونات الإضافية "الخدمية" غير الأساسية (مثل أدوات البناء، والشرائح، وما إلى ذلك) عبر الشبكة.
• إذا كنت تستضيف عملاء، فافصل البيئات (التجريب/الإنتاج) على مستوى نظام أسماء النطاقات + المضيفات الافتراضية + قاعدة البيانات.

الموارد

• موارد المطورين: المواقع المتعددة (الإدارة المتقدمة)
• تركيب متعدد المواقع
• ملف wp-config.php: واجهة برمجة التطبيقات والثوابت
• WP-CLI: أمر موقع ووردبريس
• وثائق WordPress.org: إنشاء شبكة
• جيت هاب: نواة ووردبريس (wordpress-develop)
• تتبع نظام WordPress الأساسي
• PHP.net: توجيهات php.ini (الأساسية)

الأسئلة الشائعة

هل من الممكن تحويل موقع موجود إلى موقع متعدد المواقع دون إحداث أي خلل فيه؟

نعم، ولكن جرب ذلك في بيئة تجريبية أولاً. من أكثر المشاكل شيوعاً إعادة كتابة عناوين الخادم (أخطاء 404) واكتشاف HTTPS (الحلقات). احفظ موقعك، فعّل خاصية المواقع المتعددة، طبّق القواعد، ثم اختبره.

هل تقصد النطاقات الفرعية أو الدلائل الفرعية لشبكة العميل؟

بحسب تجربتي، فإن استخدام النطاقات الفرعية مع ربط النطاقات يُعدّ حلاً أفضل على المدى البعيد. صحيح أن المجلدات الفرعية أبسط في البداية، لكنك غالباً ما تحتاج في النهاية إلى نطاقات مخصصة.

هل استخدام WP-CLI إلزامي؟

لا، ولكن بمجرد إجراء عملية الترحيل/الاستعادة، فإن WP-CLI يجنبك الأخطاء اليدوية. هذا كل شيء. wp site list et wp search-replace --network تستحق التركيب.

كيف يمكنني منع ذاكرة التخزين المؤقت للخادم من خلط مواقع الويب؟

تأكد من أن مفتاح التخزين المؤقت يختلف بـ Hostفي Nginx، مفتاح التخزين المؤقت بدون $host هذا نمط برمجي غير مرغوب فيه في المواقع المتعددة. ثم قم بمسح ذاكرة التخزين المؤقت.

لماذا تُظهر الوسائط الخاصة بي خطأ 404 بعد التبديل إلى وضع المواقع المتعددة؟

في أغلب الأحيان: قواعد إعادة كتابة غير مكتملة (أباتشي) أو try_files قد يكون هناك خطأ في خادم Nginx، أو حظر للأذونات. تأكد أيضًا من أنك لا تقوم بحظرها عن طريق الخطأ. /wp-content/uploads/sites/.

هل من الممكن استضافة موقع ويب من الشبكة على خادم آخر؟

ليس "أصليًا" باستخدام نواة ووردبريس واحدة. المواقع المتعددة تعني وجود بنية أساسية مشتركة وقاعدة بيانات مشتركة. يمكنك تخزين الوسائط خارجيًا (S3) أو استخدام شبكة توصيل المحتوى (CDN)، ولكن لا يمكنك نقل موقع فرعي بشكل منفصل دون إزالته من الشبكة.

كيف يمكنني استنساخ موقع فرعي واحد إلى موقع مستقل؟

هذا استخراج: تصدير جداول المدونة (wp_12_*تصدير الملفات المرفوعة من الموقع (uploads/sites/12ثم أعد كتابة عناوين URL. استخدم WP-CLI وبرنامج SQL النصي للقيام بذلك، وإلا ستفقد المراجع المتسلسلة.

ماذا لو كان من الضروري تفعيل إضافة ما في كل مكان؟

فعّل هذه الميزة على مستوى الشبكة إذا لزم الأمر (الأمان، تخزين البيانات مؤقتًا، تحسين محركات البحث "العالمي"). وإلا، فعّلها لكل موقع على حدة لتقليل نطاق تأثير الثغرة.

هل يشكل Divi 5 / Elementor / Avada مشاكل في المواقع المتعددة؟

من الناحية التقنية لا، ولكن من الناحية العملية نعم: التحديثات العالمية، والتراخيص، والمكتبات المشتركة. حافظ على مرحلة تجريبية وتجنب التنشيط التلقائي للشبكة.

كيف يمكنني التحقق بسرعة مما إذا كنت أستخدم بالفعل موقعًا متعدد المواقع؟

wp site list يجب أن يعمل، وفي wp-config.php يجب أن يكون لديك define('MULTISITE', true)في قسم الإدارة، يجب أن ترى "مواقعي".

ما هي أكبر مأزق في الهجرة؟

تعديل النطاقات داخل المحتوى دون تحديثها wp_blogs/wp_siteأو العكس. افعل كلا الأمرين، واصنع --dry-run قبل أي عملية إعادة كتابة ضخمة.