استضافة ووردبريس على VPS في 2026: Nginx وPHP 8.4 والكاش

بص على فاتورة الاستضافة المُدارة بتاعتك، وبعدين بص على اللي بتاخده فعلاً: Nginx وPHP وقاعدة بيانات وكاش. نفس الحاجات دي بالظبط ممكن تشغّلها على سيرفر صغير بجزء من التمن، وتشغّل عليه كذا موقع كمان. المقال ده هيبنيلك الـ Stack طبقة طبقة، ويقولك بصراحة إمتى الاستضافة المُدارة لسه تستاهل فلوسها.

هل تحتاج فعلاً إلى سيرفر خاص؟

بحسب كاتب المقال الأصلي، تتراوح خطط الاستضافة المُدارة (Managed Hosting) لووردبريس بين 25 و45 دولاراً شهرياً للموقع الواحد، بينما يكفي الاستضافة المشتركة ويحتاج خبرة أو…">سيرفر افتراضي خاص (VPS) بسعر 6 إلى 12 دولاراً شهرياً لتشغيل عدة مواقع. الفرق بين الرقمين هو ثمن الراحة: أحد غيرك يحدّث ويراقب ويرد على المشاكل في منتصف الليل.

القاعدة العملية بسيطة. إذا كنت مطوراً يتعامل مع السيرفرات، أو وكالة تدير مواقع عدة عملاء، فالحساب يميل بقوة نحو الـ VPS. أما إذا كنت لا تعرف ما هو السيرفر وتنفيذ الأوامر عليه عن بُعد، ويُفضَّل استخدامه بمفتاح بدل كلمة المرور لأنه أكثر أمانًا وأسهل في الأتمتة، وتوفره أغلب الاستضافات الحديثة.">SSH ولا تريد أن تتعلمه، فادفع للاستضافة المُدارة واسترح.

تنبيه: سيرفر VPS مهمل أسوأ من استضافة مُدارة متوسطة. ووردبريس هو أكثر نظام إدارة محتوى يتعرض للهجمات، وأي تثبيت لا يُحدَّث سيُكتشف عاجلاً أو آجلاً.

ملاحظة: لقرائنا في مصر والخليج، اختر سيرفراً في مركز بيانات أوروبي قريب مثل فرانكفورت، وضع أمامه Cloudflare. زمن الاستجابة من القاهرة أو الرياض إلى أوروبا أقل بوضوح من الوصول إلى سيرفر في أمريكا.

مكوّنات الـ Stack الحديث: أربع طبقات

الـ Stack المقترح يتكون من أربع قطع، ولكل قطعة دور واضح:

1. Nginx: يستقبل الطلبات، ويتعامل مع شهادة SSL، ويقدّم الملفات الثابتة مباشرة.
2. PHP 8.4 عبر PHP-FPM: يشغّل ووردبريس نفسه.
3. MySQL أو MariaDB: يخزّن المحتوى.
4. Valkey: يحتفظ بـ كاش الكائنات (السلة صفحة الدفع هي الصفحة التي يُدخل فيها العميل بيانات الشحن ويختار طريقة الدفع لإتمام الطلب. كل حقل زائد أو خطوة مربكة فيها ترفع نسبة التخلي عن…">وصفحة الدفع في متاجر WooCommerce.">Object Cache) في الذاكرة.

فكّر فيها كقطع بازل: كل قطعة تُضبط وحدها، ثم تتركب مع الباقي في صورة واحدة سريعة. أغلب الشروحات العامة تتجاهل الضبط الخاص بووردبريس في كل طبقة، وهنا الفرق الحقيقي.

الطبقة الأولى: إعداد Nginx لووردبريس

ووردبريس تطبيق من نوع Front Controller، أي أن كل طلب ديناميكي يمر عبر ملف واحد هو index.php. كان Apache مع .htaccess هو الخيار التقليدي، لكن Nginx يتحمل عدداً أكبر من الاتصالات بذاكرة أقل، وإعداداته صريحة في ملف واحد بدلاً من ملفات متناثرة في كل مجلد.

هذا هو الـ Server Block المقترح في المقال الأصلي للإنتاج:

# In the http context:
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=1r/s;

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

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

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Front controller: try the file, then the directory, then WordPress
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.4-fpm-example.sock;
    }

    # Long-lived caching for static assets
    location ~* .(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        access_log off;
        try_files $uri =404;
    }

    # XML-RPC is a brute-force and amplification target. Block it.
    location = /xmlrpc.php {
        deny all;
    }

    # Rate-limit login attempts at the edge
    location = /wp-login.php {
        limit_req zone=wplogin burst=2 nodelay;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.4-fpm-example.sock;
    }

    # Never serve dotfiles (except ACME challenges)
    location ~ /.(?!well-known) {
        deny all;
    }
}

ركّز على ثلاث نقاط في هذا الإعداد:

• try_files $uri $uri/ /index.php?$args هو قلب التوجيه كله: إن وُجد الملف قدّمه، وإلا سلّم الطلب لووردبريس.
• الاتصال بـ PHP-FPM يتم عبر Unix Socket وليس TCP، فيتجاوز طبقة الشبكة تماماً لأن الاثنين على نفس السيرفر.
• الملفات الثابتة (CSS والصور والخطوط) تحصل على كاش لمدة 30 يوماً وتُستثنى من سجل الوصول، فيقل ضجيج السجلات ولا يعيد المتصفح تحميل ملفات Elementor تصميم محفوظ يُعاد استخدامه، مثل رأس الموقع أو التذييل أو صفحة المقالة أو صفحة المنتج. تصممه مرة وتحدد شروط ظهوره، فيُطبَّق على كل…">القالب مع كل صفحة.

قاعدتا xmlrpc.php وwp-login.php ضوابط أمان، وسنعود إليهما في قسم الحماية.

الطبقة الثانية: PHP 8.4 وضبط PHP-FPM

ما زال ووردبريس يذكر PHP 7.4 كحد أدنى موصى به، رغم أن هذا الإصدار توقف عن تلقي التحديثات الأمنية منذ نوفمبر 2022. النواة متوافقة مع سلسلة PHP 8.x منذ سنوات، والتشغيل على PHP 8.4 أسرع بشكل ملموس من أي إصدار 7.x.

المشكلة الحقيقية في الإضافات القديمة. إضافة عمرها سنوات ويديرها مطور واحد قد تُظهر تحذيرات Deprecation أو أخطاء قاتلة. اختبر مجموعة إضافاتك على PHP 8.4 في بيئة الاختبار (Staging) قبل تغيير الإنتاج، وإذا عطّلتك إضافة واحدة فغالباً الحل هو استبدالها، لا البقاء على PHP قديم.

حجم الـ Pool: احسبه من الذاكرة الحقيقية

أكثر خطأ شائع في سيرفرات ووردبريس هو ضبط pm.max_children بتفاؤل. طلب واحد يمر عبر منشئ صفحات وعشرات الإضافات قد يستهلك بين 80 و150 ميجابايت. الطريقة الصحيحة: خذ الذاكرة المتاحة لـ PHP، واقسمها على استهلاك العملية الواحدة الذي قسته فعلاً، واترك هامشاً لقاعدة البيانات وValkey.

نقطة بداية معقولة لسيرفر بذاكرة 4 جيجابايت يستضيف موقعاً واحداً نشطاً:

[example]
user = example
group = example
listen = /run/php/php8.4-fpm-example.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 12
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

; Recycle workers to contain plugin memory leaks
pm.max_requests = 500

php_admin_value[memory_limit] = 256M

; OPcache: WordPress ships thousands of PHP files
php_admin_value[opcache.memory_consumption] = 192
php_admin_value[opcache.max_accelerated_files] = 20000
php_admin_value[opcache.interned_strings_buffer] = 16

الإعداد pm.max_requests = 500 يعيد تشغيل كل عملية بعد 500 طلب، وهو تأمين رخيص ضد تسريبات الذاكرة التي تسببها الإضافات سيئة البرمجة.

أما كاش أكواد PHP (OPcache) فيحتاج ذاكرة حقيقية. موقع فيه منشئ صفحات وعشرون إضافة يتجاوز بسهولة 10,000 ملف PHP، والقيمة الافتراضية لـ max_accelerated_files ستمتلئ وتضعف نسبة الإصابة بصمت.

في Elementor: مواقع Elementor Pro مع JetEngine من أثقل التركيبات على عمليات PHP. قِس استهلاك العملية الواحدة على موقعك قبل اعتماد الرقم 12، فقد تحتاج رقماً أقل على سيرفر 4 جيجابايت.

الطبقة الثالثة: ضبط MySQL لهيكل ووردبريس

قاعدة بيانات ووردبريس تُقرأ كثيراً وتُكتب قليلاً، وفيها جدولان يسببان أغلب المتاعب: wp_options الذي يُستعلم عنه مع كل طلب، وwp_postmeta الذي قد يصل إلى ملايين الصفوف في مواقع WooCommerce والمواقع الغنية بالمحتوى.

لا تحتاج ضبطاً معقداً. ثلاث خطوات تغطي أغلب الحالات:

1. اضبط innodb_buffer_pool_size بحيث تتسع البيانات المستخدمة في الذاكرة. على سيرفر 4 جيجابايت يشارك PHP، القيمة بين 512 ميجابايت و1 جيجابايت معقولة.
2. اترك innodb_flush_log_at_trx_commit على القيمة 1 حفاظاً على سلامة البيانات، إلا إذا كان لديك سبب مقاس.
3. افحص البيانات المحمّلة تلقائياً في wp_options دورياً بهذا الاستعلام:

SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';

إذا تجاوزت النتيجة ميجابايت أو اثنين، فغالباً تركت إضافات محذوفة بيانات تُحمَّل مع كل طلب. نظّفها.

الطبقة الرابعة: كاش الكائنات مع Valkey

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

Valkey هو النسخة مفتوحة المصدر المتفرعة من Redis بعد تغيير رخصته في 2024، ويتحدث بنفس بروتوكول Redis. لذلك تعمل الإضافة (Plugin) المعروفة Redis Object Cache معه دون أي تعديل. التفعيل عبر واجهة سطر أوامر ووردبريس (WP-CLI) يأخذ دقيقة:

wp plugin install redis-cache --activate

wp config set WP_REDIS_HOST 127.0.0.1
wp config set WP_REDIS_PORT 6379
wp config set WP_CACHE_KEY_SALT "example.com:"

# Drops the object-cache.php drop-in into wp-content
wp redis enable

# Verify
wp redis status

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

كيف تتكامل طبقات الكاش الأربع؟

الخلط بين طبقات الكاش هو سبب “مسحت الكاش خمس مرات ومفيش حاجة اتغيرت”. كل طبقة تحفظ شيئاً مختلفاً في مكان مختلف وتُمسح بطريقة مختلفة:

الخلاصة الذهنية: OPcache يوفر ترجمة الكود، وكاش الكائنات يوفر الاستعلامات، وكاش الصفحات يوفر تشغيل ووردبريس أصلاً، والـ CDN يوفر وصول الطلب لسيرفرك. الطبقات تتراكب ولا تتنافس.

كاش الصفحات مع fastcgi_cache

أسرع استجابة للزائر غير المسجل هي التي لا يعمل فيها ووردبريس إطلاقاً. يحفظ fastcgi_cache في Nginx صفحة HTML الجاهزة ويقدمها للزوار التاليين بسرعة الملف الثابت، دون المرور على PHP-FPM. وهذا ما تسوّقه كثير من الاستضافات المُدارة تحت اسم “Edge Cache”.

هذا هو الإعداد مع قواعد التجاوز التي تجعله آمناً:

# In the http context:
fastcgi_cache_path /var/cache/nginx/example levels=1:2
                   keys_zone=EXAMPLE:100m inactive=60m max_size=512m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# In the server block:
set $skip_cache 0;

# Never cache writes or query-string requests
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }

# Never cache admin, API, feeds, or auth pages
if ($request_uri ~* "/wp-admin/|/wp-json/|wp-login.php|/feed/|sitemap.*.xml") {
    set $skip_cache 1;
}

# Never cache for logged-in users, commenters, or active carts
if ($http_cookie ~* "wordpress_logged_in|wp-postpass|comment_author|woocommerce_cart_hash|woocommerce_items_in_cart") {
    set $skip_cache 1;
}

location ~ .php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.4-fpm-example.sock;

    fastcgi_cache EXAMPLE;
    fastcgi_cache_valid 200 301 302 60m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    fastcgi_cache_use_stale error timeout updating http_500 http_503;
    add_header X-FastCGI-Cache $upstream_cache_status;
}

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

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

الترويسة X-FastCGI-Cache تعطيك HIT أو MISS أو BYPASS مع كل رد، فيصبح التحقق أمر curl واحداً. والإعداد fastcgi_cache_use_stale يقدم آخر نسخة سليمة من الصفحة إذا تعطل PHP-FPM بدلاً من عرض خطأ.

بصراحة: نقطة الضعف هنا هي التحديث. مع الاعتماد على المدة فقط، قد يتأخر ظهور تعديل منشور حتى ساعة للزوار. إضافات كاش الصفحات مثل WP Super Cache أبطأ في التقديم لكنها أسهل بكثير في المسح لأنها تعرف متى يتغير المحتوى. لموقع يحرره فريق غير تقني كثيراً، قد تكون الإضافة الخيار الأفضل.

استبدل WP-Cron بـ cron حقيقي

مجدول مهام ووردبريس (WP-Cron) لا يعمل في موعده، بل يعمل عندما يزور أحد الموقع. في المواقع قليلة الزيارات تتأخر المقالات المجدولة والنسخ الاحتياطية، وفي المواقع المزدحمة يُفحص الجدول مع سيل من الطلبات فيضيف عبئاً في أسوأ توقيت.

الحل يأخذ دقيقتين. أولاً عطّل المجدول الوهمي:

wp config set DISABLE_WP_CRON true --raw

ثم أضف سطراً واحداً إلى crontab النظام بصلاحيات مستخدم الموقع:

* * * * * cd /var/www/example.com/current && wp cron event run --due-now >/dev/null 2>&1

كل دقيقة يفحص WP-CLI المهام المستحقة ويشغّلها، سواء زار أحد الموقع أم لا. والأهم أن المهام تعمل في سياق سطر الأوامر بحد ذاكرة مستقل، فلا تبطئ مهمة استيراد ثقيلة صفحة زائر.

حماية سيرفر ووردبريس

ابدأ من مبدأ غير مريح: على سيرفر واحد بلا عزل، اختراق ووردبريس يعني اختراق السيرفر. PHP يعمل بصلاحيات مستخدم الموقع، ومن ينفذ كوداً عبر إضافة مصابة يملك كل ما يملكه هذا المستخدم. حماية ووردبريس تأتي فوق حماية السيرفر العامة (الجدار الناري وSSH وfail2ban)، لا بدلاً منها.

احجب xmlrpc.php

الملف xmlrpc.php واجهة قديمة لها عيبان: الدالة system.multicall تسمح بتجربة مئات كلمات المرور في طلب واحد، وخاصية Pingback استُغلت لتضخيم الهجمات على مواقع أخرى. الـ REST API حل محلها منذ سنوات، وقاعدة deny all في إعداد Nginx أعلاه تقتله قبل أن يصل إلى PHP. الاستثناء: Jetpack وبعض تطبيقات النشر من الموبايل ما زالت تستخدمه، وفي هذه الحالة قيّد الوصول حسب المصدر.

حدّد معدل محاولات الدخول

محاولات تخمين كلمات المرور على wp-login.php لا تتوقف. منطقة limit_req في الإعداد تسمح بمحاولة واحدة في الثانية لكل IP مع هامش صغير، وهذا غير ملحوظ للبشر ومدمّر لهجمات القاموس. أضف إليها fail2ban، وكلمات مرور قوية فريدة، والمصادقة الثنائية (2FA) لكل حساب مدير.

الصلاحيات وملف الإعدادات

• المجلدات على 755، والملفات على 644، وwp-config.php على 600، وكل شيء مملوك لمستخدم الموقع.
• ووردبريس يحتاج الكتابة في wp-content/uploads فقط أثناء التشغيل العادي.
• غيّر مفاتيح التشفير (Salts) عند الشك في اختراق أو عند خروج مدير من الفريق، لأن ذلك يلغي كل جلسات الدخول فوراً. الأمر wp config shuffle-salts يفعلها في خطوة.

سياسة تحديث واضحة

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

النسخ الاحتياطي: قاعدة البيانات وwp-content واختبار الاسترجاع

موقع ووردبريس يتكون من شيئين فقط: قاعدة البيانات، ومجلد wp-content الذي يضم الرفع والقوالب والإضافات. ملفات النواة لا تحتاج نسخاً لأن wp core download يعيد تنزيلها كما هي. لذلك النسخة الاحتياطية (Backup) الكاملة هي تصدير لقاعدة البيانات (wp db export) مع أرشيف لـ wp-content، تُرسل إلى تخزين خارجي متوافق مع S3.

تنبيه: نسخة احتياطية على نفس قرص الموقع ليست نسخة احتياطية، هي مجرد نسخة ستموت مع السيرفر.

الخطوة التي يتجاهلها الجميع هي تجربة الاسترجاع. مرة كل ربع سنة، خذ نسخة حديثة واسترجعها على سيرفر تجريبي أو بيئة محلية، ثم أصلح الروابط:

wp search-replace 'https://example.com' 'https://staging.example.com'

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

مسار تحديث آمن مع WP-CLI

سمعة تحديثات ووردبريس المخيفة سببها أن أغلب الناس يختبرونها على الموقع الحي. مع WP-CLI يصبح العمل عبر بيئة الاختبار سريعاً بما يكفي ليكون القاعدة:

# 1. Clone production to staging (db + wp-content), then fix URLs
wp db export prod.sql        # on production
wp db import prod.sql        # on staging
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid

# 2. Update everything on staging
wp core update
wp plugin update --all
wp theme update --all

# 3. Smoke test: homepage, login, checkout, forms, a recent post
# 4. Same commands on production, with a fresh backup taken first

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

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

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

1. انقل الوسائط: مجلد wp-content/uploads يكبر بلا توقف. نقله إلى تخزين كائنات متوافق مع S3 يصغّر حجم السيرفر والنسخ الاحتياطية.
2. أضف CDN: الخطة المجانية من Cloudflare تخفف الضغط على سيرفرك وتضيف حماية من هجمات DDoS، وتحسن السرعة لزوار المنطقة العربية بشكل واضح.
3. افصل قاعدة البيانات: نقل MySQL إلى سيرفر مستقل يحرر الذاكرة لعمليات PHP، وهو شرط أي توسع أفقي لاحق.

التوسع الأفقي لووردبريس نفسه آخر الحلول، لأن كل خطوة قبله أرخص وتعالج اختناقاً أكثر شيوعاً.

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

س: هل PHP 8.4 آمن لموقع ووردبريس؟
ج: النواة نفسها متوافقة مع PHP 8.x منذ سنوات وتعمل عليه أسرع. الخطر في الإضافات القديمة، فاختبر إضافاتك على نسخة في بيئة الاختبار قبل الترقية، واعتبر أي إضافة تفشل مرشحة للاستبدال.

س: هل أحتاج كاش الكائنات وكاش الصفحات معاً؟
ج: نعم، لأن كل واحد يخدم جمهوراً مختلفاً. كاش الصفحات يخدم الزوار غير المسجلين، أما المسجلون وأصحاب السلال فيتجاوزونه، وهنا يعمل كاش الكائنات على تقليل استعلامات قاعدة البيانات.

س: هل أحجب xmlrpc.php في كل المواقع؟
ج: احجبه ما لم تكن متأكداً أنك تحتاجه. Jetpack وبعض تطبيقات النشر من الموبايل ما زالت تستخدمه، وفي هذه الحالة افتحه للخدمات التي تحتاجه فقط.

س: هل يمكن استخدام Valkey بدلاً من Redis مع ووردبريس؟
ج: نعم. Valkey متوافق مع بروتوكول Redis، وإضافة Redis Object Cache تتصل به بنفس إعدادات WP_REDIS_HOST وWP_REDIS_PORT دون أي تعديل في الكود.

س: ما حجم السيرفر المناسب لموقع ووردبريس واحد؟
ج: بحسب المقال الأصلي، سيرفر 2 جيجابايت مع OPcache وValkey وfastcgi_cache يكفي موقع محتوى عادياً، و4 جيجابايت تعطي مساحة مريحة لـ WooCommerce أو عدة مواقع.

الخلاصة

الفرق بين الاستضافة المُدارة وسيرفر VPS رخيص ليس في العتاد، بل في الإعداد: Server Block صحيح، وPool مضبوط لـ PHP 8.4، وكاش كائنات، وكاش صفحات بقواعد تجاوز سليمة، وcron حقيقي، ونسخ احتياطية جرّبت استرجاعها. لا شيء من هذا غريب، كله نفس الانضباط الذي يحصل عليه أي تطبيق إنتاجي.

ابدأ النهارده بخطوة صغيرة: خد موقع واحد واستبدل WP-Cron بالـ cron الحقيقي، دي دقيقتين ومفيهاش أي مخاطرة. وبعدها كمّل الـ Stack قطعة قطعة.

المصدر الأصلي: Modern WordPress Hosting in 2026: Nginx, PHP 8.4, and Object Caching on a VPS — DEV.to