צור רשת מרובת אתרים בוורדפרס בקלות

הצורך / בעיית השרת

אם אי פעם ראיתם אתר אינטרנט רב-אתרי מגיב בלולאה עם שגיאת 301, הגישו את mauvais אתר בדומיין הנכון, או לשבור את המדיה (404 ב /wp-content/uploads/sites/), הבעיה נובעת לעיתים רחוקות מ וורדפרס עצמו. זה כמעט תמיד מגיע משכבת ​​השרת: DNS, vhost, TLS, כללי כתיבה מחדש או מטמון.

רשת וורדפרס (וורדפרס 6.9.4, אפריל) 2026זה מאפשר לך לארח אתרים מרובים עם ליבת וורדפרס אחת, סט יחיד של תוספים/תבניות (עם הפעלת רשת) ומסד נתונים משותף. זה מאוד יעיל... בתנאי שתגדיר את השרת כ-Reverse Proxy ונתב אתרים, ולא כ"אתר יחיד" פשוט.

בסוף, תדעו כיצד: לבחור תת-דומיינים לעומת תיקיות משנה, להכין מארח וירטואלי חזק (Nginx או Apache), ולהפעיל ריבוי אתרים באמצעות wp-config.php, להחיל את כללי הכתיבה מחדש הנכונים, לנהל את הרשת על בסיס יומי באמצעות WP-CLI, ומעל הכל לבצע הגירה/שחזור מבלי לשבור את מיפוי הדומיין ↔ האתר.

סיכום קצר

• תת-דומיינים דורש תו כללי של DNS ולעתים קרובות גם אישור תו כללי; גמיש יותר למיפוי דומיינים.
• ספריות משנה פשוט יותר בצד ה-DNS/TLS, אך היזהרו מהתנגשויות של כתובות URL וכללי כתיבה מחדש.
• השרת חייב לשמור Host ולהגיש את וורדפרס על יחיד document_root עם כתיבה מחדש של אתרים מרובים.
• WP-CLI הוא "לוח הבקרה" שלך: יצירת אתר, מיפוי, חיפוש/החלפה, ניקוי מטמון.
• הגירות ייצוא SQL + קבצים + עדכון טבלה wp_blogs/wp_site + חיפוש/החלפה ממוקדים, אחרת כתובות ה-URL נפגעות.
• סליק : "גרסה" שנשמרה במטמון בצורה גרועה על ידי Host משרת את אתר A בדומיין B. זה נפוץ כאשר Nginx fastcgi_cache מוגדר בצורה שגויה.

לפני שמתחילים (דרישות מוקדמות)

גישה וכלים

• SSH על השרת (או לפחות מעטפת על הקונטיינר).
• WP-CLI (מומלץ). מקור: פקודות WP-CLI.
• גישה ל MySQL / MariaDB שורת הפקודה (mysql, mysqldump).
• גישה לקבצים (SFTP/rsync). הימנעו מ-FTP בשנת 2026 אם אתם יכולים.

גרסאות שרת מומלצות (2026)

• וורדפרס : 6.9.4 (כבר יש לך את זה).
• PHP : 8.1+ (8.2/8.3 נפוץ מאוד). מקור: גרסאות נתמכות של PHP.
• MySQL : 8.0+ או יותר מריאד : 10.6+ (הימנעו מגרסאות ישנות יותר, במיוחד עבור ביצועים וחטיפים).
• nginx ou אַפָּשׁ (שניהם עובדים, אבל 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בצד השרת, זה הכי פשוט: דומיין יחיד, בלי DNS עם תווים כלליים, בלי אישור תווים כלליים.

• יתרון: התקנה מהירה, פחות משתני רשת.
• חיסרון: אם האתר הראשי שלך כבר משתמש בסלאגים "שמורים", אתה יכול קואל התנגשויות (למשל, דף) /blog ואתר /blog).

תת-דומיינים

דוגמא: site1.example.com, site2.example.comזוהי לרוב הבחירה הטובה ביותר אם אתם מתכננים... מיפוי דומיינים (לדוגמה: client-a.com מצביע לאתר ברשת).

• יתרון: בידוד על ידי מארח, ניקוי עבור אחסון במטמון ופרוקסי.
• חיסרון: דורש תו כללי של DNS (*.example.com) ובאופן אידיאלי תו כללי של TLS.

תאימות Divi 5 / Elementor / Avada

שלושתם תומכים בסביבות מרובות אתרים, אך המציאות המעשית היא ניהול רישיונות וספריות גלובליות. ברשתות לקוח, אני ממליץ:

• הפעל את בונה הדפים לכל אתר (לא מחובר לרשת) אם ברצונך להגביל את ההשפעה של באג.
• שמרו על אתר "בימוי פנימי" ברשת כדי לבדוק עדכונים לבונה ולמודולים.

שלב 2: הכנת DNS, vhost ו-TLS (תו כללי במידת הצורך)

DNS (תת-דומיינים)

עליך ליצור רשומת תווים כלליים. דוגמה (רעיונית):

• A : example.com → כתובת IP של השרת
• A : *.example.com → כתובת IP של השרת

בלי תו כללי (wildcard), וורדפרס תיצור אתרים, אבל ה-DNS לא יפתור, ותבזבזו זמן באבחון "וורדפרס לא עובד".

TLS (בואו נצפין / תו כללי)

תעודת wildcard של Let's Encrypt דורשת בדרך כלל בדיקת DNS (בהתאם למערכת ההפעלה). אם אינך יכול להשתמש בתעודת wildcard, חלופה ריאלית היא להשתמש בתעודה מרובת דומיינים עבור תת-דומיינים ידועים, אך פעולה זו הופכת במהירות לבלתי ניתנת לניהול.

Vhost: document_root יחיד

רשת מרובת האתרים חייבת להצביע אל le meme document_root וורדפרס. אל תיצרו vhost עבור כל תת-אתר עם roots שונים: זה יפריע להעלאות, לעוגיות ולרזולוציית האתר.

שלב 3: הפעל את Multisite כראוי (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 תת-ספריות כרגע. שינוי זה לאחר מכן אפשרי, אבל זו העברה (DNS, כתובות URL, קובצי Cookie), לא מעבר פשוט.

קבועים אופייניים של אתרים מרובי-אתרים (דוגמה)

דוגמה לרשת עם תת-דומיינים 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
}

טעות מציאותית: העתקה למקום הלא נכון

אני רואה לעתים קרובות קבועים מרובי אתרים דבוקים זה לזה האפרה השורה "הפסק עריכה". במקרה הזה, וורדפרס לא קוראת אותם, ואתם מקבלים פאנל ניהול ש"שוכח" את חיבור הרשת בכל רענון. שמרו אותם לפני סוף הקובץ.

שלב 4: כתיבה מחדש של כללים (Nginx/Apache) ומלכודות מטמון

הנה מה שקורה מאחורי הקלעים: וורדפרס מנתבת אתרי משנה דרך כתובת ה-URL ו/או המארח, אך השרת חייב לשלוח תחילה את כל הבקשות "שאינן קשורות לקבצים" אל... index.phpבסביבה מרובת אתרים, ישנם כללים ספציפיים נוספים עבור wp-admin וגם עבור העלאות "אתר".

Nginx: נקודות שאינן ניתנות למשא ומתן

• הבלוק server_name חייב לכסות את הדומיין (ואם מדובר בתת-דומיינים) את תו הכללי (wildcard).
• Le try_files חייב להפנות אל /index.php עם הטיעונים.
• גישה ל /wp-admin חייב להתמודד עם החתך האחרון.

אפאצ'י: שימו לב ל-.htaccess ול-AllowOverride

Si AllowOverride מושבת, שלך .htaccess זה חסר טעם. תוצאה אופיינית: פאנל הניהול עובד, אבל כל אתרי המשנה מחזירים שגיאות 404. בדוק את תצורת האפאצ'י, לא רק את קובץ התצורה.

מלכודת מטמון (fastcgi_cache / proxy_cache)

הבאג הקלאסי: המטמון לא משתנה לפי $hostכתוצאה מכך, site1.example.com מטמון את דף הבית, לאחר מכן site2.example.com מקבל את דף הבית של site1. נתקלתי בזה על ערימות ש"עברו אופטימיזציה" ידנית.

אם אתם משתמשים במטמון של Nginx, המפתח חייב לכלול $scheme$host$request_uri לכל הפחות.

שלב 5: ניהול הרשת על בסיס יומי באמצעות WP-CLI

WP-CLI היא הדרך האמינה ביותר לנהל רשת ללא עובר אורח על ידי מסכים שמסתירים פרטים. מסמך: אתר wp et רשת wp.

רשימה ובקרה של אתרים

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

עדכנו את וורדפרס והתוספים (בזהירות)

ברשת מרובת אתרים, עדכון תוסף "גלובלי" משפיע על כל האתרים. הנוהג הרגיל שלי הוא לעדכן בסביבת staging, ואז בסביבת ייצור עם חלון ו-rollback מוכן.

# 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), ולפעמים מיפוי דומיינים. השרת חייב להיות מוכן אוונגרד כדי לייבא את מסד הנתונים.

יצירת שרת staging (עותק) דרך 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

שיקום (חזרה למצב הקודם): אסטרטגיה ריאלית

• לְשַׁחְזֵר fichiers + בסיס יחד (הימנעו מערבוב של dump של J-1 עם העלאות J).
• אם אתם משתמשים ב-Redis/Object Cache, נקו אותו לאחר השחזור (אחרת אתם משתמשים באפשרויות מיושנות).

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

קבצי תצורה מלאים

הדוגמאות שלהלן מוכנות להעתקה והדבקה, אך התאימו את הנתיבים, sockets 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 מותר על vhost.

# /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 וכו'. הפניה: wp-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): הגדרות שימושיות עבור Multisite

באתרים מרובי אתרים, מגבלות זמן העלאה וביצוע הן הגורמים העיקריים ל"קריסת המערכת כשאני מעלה ערכת נושא לרשת". דוגמה מינימלית (התאמתה לערימה שלך):

; 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 בכל הדפים מלבד דף הבית: כתיבה מחדש שגויה של 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 → cache.

תרשים אבחון (תסמינים בפועל)

סימפטום	סיבה סבירה	אימות	פתרון
תת-דומיין מציג את האתר הראשי	תו כללי של 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	מטמון השרת אינו משתנה בהתאם למארח	כותרות מטמון + בדיקת תצורת מטמון	לִכלוֹל $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() לפני סוף הקובץ
שכחו מ-DNS עם תווים כלליים עבור תת-דומיינים	אתרי המשנה לא פותרים	להוסיף ב *.domaine צד DNS + vhost
בדיקות בייצור ללא גיבוי/שחזור	אין דרך חזרה	dump של SQL + ארכיון קבצים + בדיקת שחזור
מטמון Nginx שאינו משתנה בין מחשבי אחסון שונים	מפתח מטמון לא שלם	לִכלוֹל $host במפתח, ניקוי
קישורים קבועים "שבורים" לאחר ההעברה	כתיבה מחדש בצד השרת לא מיושרת	מאמת try_files/.htaccess + ניקוי מטמונים
השתמש בקטע קוד ישן שנמצא ב-2017	הנחות מיושנות (PHP, פרוקסי, אבטחה)	חזור לתיעוד הרשמי של WP 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 "העתק-הדבק" שפוגע באלמנטור/דיווי/אבדתיהתחל עם כותרות בטוחות ולא פולשניות.

# 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;

בידוד רשת וזכויות מנהל

• הגבל את מספר ה- מנהלי-עלזהו המקבילה השורשית בצד של וורדפרס.
• הימנעו מהפעלת תוספים "כלי עזר" שאינם קריטיים (בונים, סליידרים וכו') דרך הרשת.
• אם אתם מארחים לקוחות, הפרידו את הסביבות (staging/prod) ברמת DNS + vhosts + מסד נתונים.

משאבים

• משאבי מפתחים: ריבוי אתרים (ניהול מתקדם)
• התקנה רב-אתרית
• wp-config.php: API וקבועים
• WP-CLI: פקודת אתר wp
• תיעוד WordPress.org: יצירת רשת
• גיטהאב: ליבת וורדפרס (wordpress-develop)
• מעקב ליבת וורדפרס
• PHP.net: הנחיות php.ini (הליבה)

שאלות נפוצות

האם ניתן להמיר אתר קיים לאתר מרובה אתרים מבלי לפגוע בו?

כן, אבל תחילה עשו זאת בסביבת staging. נקודות השבירה הנפוצות ביותר הן כתיבה מחדש של השרת (שגיאות 404) וזיהוי HTTPS (לולאות). שמרו את האתר שלכם, הפעילו Multisite, החלו את הכללים ולאחר מכן בדקו.

תת-דומיינים או תת-ספריות עבור רשת לקוח?

מניסיוני, תת-דומיינים + מיפוי דומיינים נקיים יותר בטווח הארוך. תת-ספריות פשוטות יותר בהתחלה, אבל לעתים קרובות בסופו של דבר רוצים דומיינים ייעודיים.

האם WP-CLI חובה?

לא, אבל ברגע שתעבירו/תשחזרו, WP-CLI חוסך לכם שגיאות ידניות. זה הכל wp site list et wp search-replace --network שווים את ההתקנה.

כיצד ניתן למנוע ממטמון השרת לערבב אתרים?

ודא שמפתח המטמון משתנה בהתאם Hostב-Nginx, מפתח מטמון ללא $host זהו אנטי-דפוס ב-Multisite. לאחר מכן נקה את המטמון.

מדוע המדיה שלי מחזירה שגיאת 404 לאחר המעבר ל-Multisite?

לרוב: כללי שכתוב לא שלמים (אפאצ'י) או try_files חסר (Nginx), או בלוק הרשאה. כמו כן, בדוק שאינך חוסם בטעות /wp-content/uploads/sites/.

האם ניתן להעלות אתר אינטרנט מהרשת לשרת אחר?

לא "באופן טבעי" עם ליבת וורדפרס אחת. מולטי-אתרים מרמזים על בסיס ובסיס קוד משותפים. ניתן להוציא מדיה (S3) או להשתמש ב-CDN, אך לא ניתן להעביר תת-אתר בנפרד מבלי להסירו מהרשת.

כיצד ניתן לשכפל אתר משנה יחיד לאתר עצמאי?

זהו חילוץ: ייצוא של טבלאות הבלוג (wp_12_*), ייצוא של העלאות אתרים (uploads/sites/12), לאחר מכן כתוב מחדש את כתובות ה-URL. עשו זאת באמצעות WP-CLI וסקריפט SQL, אחרת תפספסו הפניות סידוריות.

מה אם תוסף צריך להיות פעיל בכל מקום?

הפעל זאת בקנה מידה רשתי במידת הצורך (אבטחה, שמירת אובייקטים במטמון, קידום אתרים "גלובלי"). אחרת, הפעל זאת לכל אתר כדי להפחית את רדיוס הפיצוץ של באג.

האם Divi 5 / Elementor / Avada מעוררים בעיות ב-Multisite?

טכנית לא, אבל מבחינה תפעולית כן: עדכונים גלובליים, רישיונות וספריות משותפות. יש לשמור על שלב ביניים ולהימנע מהפעלה אוטומטית של הרשת.

איך אני יכול לבדוק במהירות אם אני אכן משתמש באתרים מרובי אתרים?

wp site list חייב לעבוד, ובתוך wp-config.php אתה חייב להיות define('MULTISITE', true)בצד הניהול, אתה אמור לראות את "האתרים שלי".

מהי המכשול מספר אחת בהגירה?

שינוי דומיינים בתוך התוכן מבלי לעדכן wp_blogs/wp_site, או להיפך. עשו את שניהם, וצרו --dry-run לפני כל כתיבה מחדש נרחבת.