لماذا تستضيف WordPress ذاتيًا على خادم VPS
تتقاسم الاستضافة المشتركة وحدة المعالجة (CPU) والذاكرة (RAM) وحتى قاعدة البيانات مع مئات المواقع الأخرى: تعتمد سرعتك على الجيران، وغالبًا ما يكون الوصول عبر SSH أو الإعداد الدقيق للخادم مقفلًا. يمنحك خادم VPS موارد مخصّصة لجهازك، وتحكمًا كاملًا في PHP-FPM وخادم الويب والتخزين المؤقت للكائنات (Redis) والتخزين المؤقت للصفحات. وبالنسبة إلى وكالة تدير عدة مواقع لعملائها، فهذا يعني أيضًا إمكانية عزل كل شيء في حاويات على جهاز واحد، مع نسخ احتياطية ونشر مُحكَمين، حيث تفرض الاستضافة المشتركة حدودها وتكاليفها الإضافية.
مكاسب WordPress على خادم VPS
- موارد CPU/RAM مخصّصة لجهازك: تباطؤ أقل بسبب الجيران
- تحكم كامل في PHP-FPM وخادم الويب والإضافات
- التخزين المؤقت للكائنات عبر Redis والتخزين المؤقت للصفحات لتقليص أزمنة الاستجابة إلى النصف
- وصول كامل عبر SSH/WP-CLI لأتمتة الصيانة وعمليات النشر
- العزل عبر الحاويات: عدة مواقع لعملاء على خادم VPS واحد
- نسخ احتياطية وقواعد أمان تحدّدها أنت، دون تكلفة إضافية لكل موقع
متطلبات واقعية
يتحمّل خادم VPS بمعالجَين افتراضيَّين (2 vCPU) و2 غيغابايت من الذاكرة (RAM) موقع WordPress بحركة زوار معتدلة بأريحية؛ انتقل إلى 4 غيغابايت مع Redis أو WooCommerce أو عدة مواقع. تحتاج إلى Docker + Compose، وقاعدة بيانات MariaDB أو MySQL، ويُفضَّل Redis للتخزين المؤقت للكائنات، ونطاق yourdomain.com مع شهادة SSL الخاصة به. خصّص بعض الضبط لـPHP (upload_max_filesize وmemory_limit) بحسب وسائطك وإضافاتك.
النشر خطوة بخطوة
تركيب WordPress وMariaDB وRedis
في ملف
docker-compose.yml، صرِّح عنwordpress:php8.3-fpmأوwordpress:apache، وخدمةmariadb:11وredis:alpine. احفظwp-contentوقاعدة البيانات في وحدات تخزين مُسمّاة، على شبكة Docker داخلية.إدخال بيانات قاعدة البيانات والأسرار
مرّر
WORDPRESS_DB_*وكلمات مرور قوية عبر متغيرات البيئة. أضِف مفاتيح الأمان (salts) المولَّدة من واجهة WordPress الرسمية فيWORDPRESS_CONFIG_EXTRA.تشغيل WordPress وتثبيته
ابدأ بـ
docker compose up -dثم افتح نطاقك لمعالج التثبيت. والأفضل: أتمِت العملية عبر WP-CLI (wp core install) للحصول على عمليات نشر قابلة للتكرار من موقع إلى آخر.وضع reverse proxy وSSL
أعدّ Nginx/Caddy بـHTTPS أمام WordPress. اضبط
client_max_body_sizeلعمليات الرفع، وفعِّل ضغط gzip/brotli والتخزين المؤقت للأصول الثابتة (الصور وCSS وJS) مع ترويساتCache-Controlطويلة الأمد.تفعيل التخزين المؤقت للكائنات عبر Redis
ثبّت إضافة للتخزين المؤقت للكائنات (مثل Redis Object Cache)، ووجّهها إلى خدمة
redis، وفعّلها: عندئذٍ تُخدَّم الاستعلامات المتكررة إلى قاعدة البيانات من الذاكرة، ما يخفّف العبء بشدة عن MariaDB.التحصين والنسخ الاحتياطي
عطّل تحرير الملفات في لوحة الإدارة (
DISALLOW_FILE_EDIT)، وحُدّ من محاولات تسجيل الدخول، وجدوِل نسخة احتياطية ليلية لـwp-content+ نسخة SQL إلى تخزين كائنات بعيد.أول تسجيل دخول
افتح رابط الموقع: يبدأ WordPress تثبيته الذي يستغرق خمس دقائق — اللغة، ثم عنوان الموقع، ثم إنشاء اسم المستخدم الخاص بك كمسؤول مع كلمة المرور والبريد الإلكتروني اللذين تختارهما. أكمل التثبيت دون تأخير، فالتثبيت غير المكتمل متروك لأول زائر يصل إليه.
للحصول على أداء ينافس أسرع المنصات المُدارة، أضِف تخزينًا مؤقتًا كاملًا للصفحات أمام PHP: إضافة تولّد ملفات HTML ثابتة يخدمها Nginx مباشرةً (عبر try_files)، أو وحدة FastCGI cache. عندئذٍ لا تلمس صفحاتك العامة PHP ولا MariaDB إطلاقًا، ما يتيح لخادم VPS متواضع استيعاب آلاف الزوار المتزامنين، مع إبقاء لوحة الإدارة وسلة الشراء (WooCommerce) خارج التخزين المؤقت.
تنبيه PHP بتاريخ 21/10/2026 (PHP2Shell): تحديث WordPress لا يصلح PHP
في 21 أكتوبر 2026 أصدر مشروع PHP نسخًا أمنية لثغرتين تتيحان تنفيذ شيفرة عن بُعد، هما CVE-2026-109618 وCVE-2026-109619. يكمن الإصلاح في PHP نفسها: النسخ المصحَّحة هي 8.5.12 و8.4.27 و8.3.36 و8.2.35. لذلك قد يكون WordPress محدَّثًا بالكامل (النواة والقوالب والإضافات) وهو يعمل مع ذلك على PHP معرَّضة للثغرة، لأن شاشة التحديثات في WordPress لا تلمس المفسِّر أبدًا. في المكدّس الذي يعرضه هذا المقال تقيم PHP داخل صورة Docker الخاصة بـWordPress: ما لم تسحب صورة أُعيد بناؤها على نسخة مصحَّحة وتُعِد إنشاء الحاوية، تبقى الثغرة مفتوحة. لتفاصيل الثغرتين اقرأ مقال php2shell-cve-2026-109618-109619-mettre-a-jour-php، ولإعادة بناء الصور مقال php2shell-docker-wordpress-reconstruire-images-php.
تحقّق ثم أصلح في خمس خطوات
اقرأ نسخة PHP التي تُخدَّم فعلًا
الأوثق هو WordPress نفسه: الأدوات > صحة الموقع > معلومات > الخادم تعرض نسخة PHP التي تنفّذ صفحاتك. وعلى خادم VPS بلا Docker احذر من الأمر
php -v: فهو يسأل الملف التنفيذي لسطر الأوامر، وقد يختلف عن PHP-FPM الذي يخدم زوارك. اسأل الخدمة نفسها بالأمرphp-fpm -v(أو php-fpm8.3 -vعلى Debian وUbuntu).افحص النسخة داخل الحاوية
مع Docker نفّذ
docker compose exec wordpress php -v: تحمل الصورة نسخة PHP واحدة، فتصحّ النتيجة على FPM أو mod_php في الحاوية. قارنها بالنسخ المصحَّحة أعلاه مع البقاء في الفرع نفسه (يجب أن تبلغ 8.3.x النسخة 8.3.36 لا 8.4.27).اسحب الصورة المحدَّثة
نفّذ
docker compose pull && docker compose up -d. ينزّل pull آخر صورة منشورة لوسمك (مثل wordpress:php8.3-fpm)، ويعيدup -dإنشاء الحاوية عليها. تحتفظ وحداتك المسمّاة بالمجلدwp-contentوقاعدة البيانات. إن ظلّphp -vيعرض نسخة قديمة فالصورة المصحَّحة لم تُنشر بعد لذلك الوسم: عاود الفحص لاحقًا، أو انتقل إلى فرع PHP آخر إن كان موقعك يدعمه.أعد تشغيل PHP-FPM
تحديث حزمة أو ملفات لا يغيّر الشيفرة المحمَّلة أصلًا في العمليات الجارية. على خادم تقليدي أعد تشغيل الخدمة بالأمر
systemctl restart php8.3-fpm(عدّل رقم النسخة)؛ ومع Docker يكفي إعادة إنشاء الحاوية، وإلا فنفّذdocker compose restart wordpress. إعادة التحميل (reload) وحدها أقل ضمانًا من إعادة التشغيل حين تريد تجديد كل العمليات العاملة.ابحث عن آثار استغلال
التحديث يغلق الباب لكنه لا يخبرك هل دخل أحد من قبل. راجع سجلات الوصول والأخطاء في Nginx أو Apache (الأمر
docker compose logs --since 72h wordpressمع Docker) بحثًا عن انهيارات عمليات PHP-FPM ورسائل نفاد الذاكرة المتكررة وطلبات غير معتادة كبيرة الحجم. وداخلwp-contentاعرض ملفات.phpالمعدَّلة حديثًا بالأمرfind wp-content -name '*.php' -mtime -7، خصوصًا تحتuploadsحيث لا ينبغي أن يوجد أي سكربت. عند أدنى شك، استعد من نسخة احتياطية سليمة وغيّر كلمات المرور والـsalts.أتمتة الفحص عبر WP-CLI وcron
لاحظ أن
wp --infoيعرض نسخة PHP لسطر الأوامر لا نسخة PHP-FPM: احتفظ به للسكربتات لا للحكم على التعرّض عبر الويب. بدلًا من ذلك جدول مهمة cron أسبوعية تنفّذdocker compose pullثم تقارن ناتجdocker compose exec wordpress php -vبالنسخة المتوقعة وتراسلك بالبريد عند أي اختلاف. وهكذا لا يعود التنبيه الأمني القادم لـPHP معتمدًا على ذاكرتك.تحقّق مرة أخرى
افتح صحة الموقع مجددًا وأعد
php -vداخل الحاوية: يجب أن يعرض الاثنان نسخة مصحَّحة. دوّن التاريخ في سجل الصيانة، وكرّر الإجراء مع كل إصدار أمني جديد لـPHP.
تخفيف جزئي وليس إصلاحًا
بالنسبة إلى CVE-2026-109619 يوصي إشعار PHP بتعطيل session.upload_progress.enabled في ملف php.ini أو في مجمّع FPM ثم إعادة تشغيل كل العمليات العاملة؛ ولا يكفي استخدام ini_set() أو .user.ini. يخفّض ذلك التعرّض ريثما تجدول التحديث، لكن تحديث PHP وحده يصلح الثغرتين فعلًا.
الوثائق الرسمية
للإعداد المتقدّم والخيارات الخاصة بالأداة، ارجع إلى الوثائق الرسمية لـWordPress. يغطّي هذا الدليل النشر على خادم VPS؛ وتبقى وثائق الناشر المرجعَ للضبط الدقيق والترقيات الكبرى وحالات الاستخدام الخاصة.
