حل أخطاء ووردبريس الشائعة: الشاشة البيضاء وخطأ 500

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

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

ما الفلسفة العامة لحلّ أي خطأ في ووردبريس؟

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

المنهج الذي نتبعه في هذا الدليل بأكمله خمس خطوات بالترتيب، لا تتجاوز أيًّا منها:

1. نسخة احتياطية فورية — قبل أي تغيير، احفظ نسخة من الملفات وقاعدة البيانات. إن ساء الوضع تعود لها.
2. تفعيل WP_DEBUG وقراءة debug.log — تجعل ووردبريس يطبع/يسجّل سبب العطل بدل إخفائه خلف شاشة بيضاء.
3. عزل السبب بالاستبعاد — تعطيل الإضافات، التحويل لقالب افتراضي، رفع الذاكرة، إعادة توليد .htaccess — واحدة تلو الأخرى حتى يعود الموقع.
4. الإصلاح — بعد تحديد المتسبّب، أصلحه أو استبدله أو احذفه.
5. التحقّق — تأكّد أن الموقع يعمل في الواجهة ولوحة الإدارة معًا، ثم أعد تفعيل ما عطّلته تدريجيًا.

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

متى تأخذ النسخة الاحتياطية؟ إن كان موقعك ما زال يصل لوحة الإدارة، استخدم إضافة نسخ احتياطي مثل UpdraftPlus فورًا. وإن انهارت اللوحة، انسخ مجلّد الموقع كاملًا عبر FTP وصدّر قاعدة البيانات من phpMyAdmin قبل أي عبث. راجع دليل النسخ الاحتياطي للموقع لخطّة منهجية.

كيف تفعّل WP_DEBUG وتقرأ سجلّ الأخطاء؟

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

تفعيل التنقيح والتسجيل في ملف

افتح ملف wp-config.php في جذر الموقع عبر FTP أو مدير الملفات في cPanel، وابحث عن السطر /* That's all, stop editing! */. قبل هذا السطر مباشرة، أضف ما يلي:

// تفعيل وضع التنقيح
define( 'WP_DEBUG', true );

// تسجيل الأخطاء في ملف debug.log بدل عرضها للزائر
define( 'WP_DEBUG_LOG', true );

// منع عرض الأخطاء على الشاشة للزوّار (أمان + موقع نظيف)
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

بهذا الإعداد لن يرى الزائر شيئًا، لكن كل خطأ سيُسجَّل في ملف debug.log داخل مجلّد wp-content/. افتح الموقع أو الصفحة المعطوبة مرّة، ثم افتح wp-content/debug.log عبر FTP واقرأ آخر الأسطر — ستجد عادة سطرًا مثل:

PHP Fatal error: Uncaught Error: Call to undefined function ...
in /home/user/public_html/wp-content/plugins/some-plugin/file.php on line 142

هذا السطر يعطيك اسم الإضافة والملف ورقم السطر — تشخيص مكتمل في ثوانٍ. الجدول التالي يشرح رموز التنقيح الأساسية ووظيفة كلٍّ منها:

مهم جدًا: أعِد WP_DEBUG إلى false فور انتهاء التشخيص. ترك التنقيح مفعّلًا على موقع حيّ يسرّب مسارات الخادم وقد يكشف ثغرات. واحذف ملف debug.log بعد قراءته لأنه قد يصبح ضخمًا ويحوي معلومات حسّاسة. لمزيد عن إغلاق المنافذ الأمنية راجع تأمين موقع ووردبريس.

أين تجد سجلّات الأخطاء الأخرى؟

debug.log ليس المصدر الوحيد. أحيانًا يقع الخطأ على مستوى الخادم نفسه (PHP-FPM أو Apache) قبل أن يصل ووردبريس. الجدول التالي يدلّك على أماكن السجلّات المختلفة حسب نوع الاستضافة:

في الاستضافة المشتركة قد لا تصل لسجلّات النظام مباشرة، لكن لوحة cPanel غالبًا توفّر قسم «Errors» يعرض أحدث الأخطاء. وعلى الـVPS تصل لكل شيء عبر SSH كما في أساسيات SSH للمبتدئين.

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

كيف تحلّ الشاشة البيضاء (WSOD)؟

الشاشة البيضاء للموت (White Screen of Death) هي صفحة فارغة تمامًا بلا أي نص أو خطأ. سببها أن سكربت PHP توقّف عن التنفيذ فجأة — إمّا بسبب خطأ فادح (Fatal Error) في كود إضافة أو قالب، أو نفاد ذاكرة PHP المخصّصة. لأنها لا تعرض رسالة، خطوتك الأولى دائمًا تفعيل WP_DEBUG_LOG كما شرحنا أعلاه لتحويل الصمت إلى تشخيص.

ملاحظة مهمّة: في ووردبريس الحديث (5.2 فأحدث) صارت الشاشة البيضاء أندر، إذ يلتقط ووردبريس الأخطاء الفادحة ويعرض بدلًا منها رسالة «حدث خطأ حرج» مع وضع الاسترداد (سنشرحه في القسم التالي). فإذا رأيت شاشة بيضاء بالكامل فالأرجح أن العطل أعمق: نفاد ذاكرة، أو خطأ في النواة نفسها، أو ملف wp-config.php معطوب.

خطوات حلّ WSOD بالاستبعاد

اتبع الترتيب التالي، واختبر الموقع بعد كل خطوة قبل الانتقال للتي تليها:

1. ارفع حدّ الذاكرة — أضف define( 'WP_MEMORY_LIMIT', '256M' ); إلى wp-config.php. كثير من حالات WSOD مجرّد نفاد ذاكرة.
2. عطّل كل الإضافات — أعد تسمية مجلّد wp-content/plugins عبر FTP (سنشرح أدناه). إن عاد الموقع، فالسبب إضافة.
3. حوّل لقالب افتراضي — أعد تسمية مجلّد القالب الحالي فيرجع ووردبريس لقالب افتراضي مثل twentytwentyfour.
4. افحص wp-config.php — مسافة زائدة أو خطأ صياغي بعد علامة الإغلاق ?> يسبّب شاشة بيضاء.
5. اقرأ debug.log — إن لم تنجح الخطوات أعلاه، فالسجلّ يكشف الملف والسطر بالضبط.

الجدول التالي يربط أعراض WSOD الدقيقة بأسبابها الأرجح لتختصر التشخيص:

ما «الخطأ الحرج» ووضع الاسترداد (Recovery Mode)؟

منذ الإصدار 5.2 أدخل ووردبريس آلية الحماية من الأخطاء الفادحة (Fatal Error Protection). فبدل الشاشة البيضاء، إذا أطلقت إضافة أو قالب خطأً فادحًا، يعرض ووردبريس رسالة مهذّبة: «حدث خطأ حرج في هذا الموقع. يرجى التحقّق من بريد مشرف الموقع للحصول على تعليمات». وهذه الرسالة هي مفتاح الحل لأنها ترسل بريدًا تلقائيًا إلى بريد المشرف.

كيف تستخدم رابط وضع الاسترداد من البريد؟

البريد الذي يصلك من ووردبريس يحوي ثلاثة أشياء قيّمة:

1. اسم الإضافة أو القالب المتسبّب ورسالة الخطأ ورقم السطر — تشخيص جاهز بلا حتى فتح FTP.
2. رابط وضع الاسترداد (Recovery Mode) — يفتح لوحة الإدارة في وضع آمن يعطّل العنصر المعطوب مؤقّتًا حتى تصلحه.
3. تفاصيل تقنية إضافية تساعد على فهم الخطأ.

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

ماذا لو لم يصل البريد؟

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

العملية إذن لا تتوقّف على البريد إطلاقًا — التعطيل اليدوي عبر FTP يحلّ كل شيء، وهو ما نشرحه الآن.

كيف تعزل السبب: تعطيل الإضافات والقالب يدويًا؟

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

تعطيل كل الإضافات دفعة واحدة (FTP/SSH)

الطريقة الأسرع لمعرفة هل السبب إضافة: عطّلها كلها مرّة واحدة. عبر FTP، انتقل إلى wp-content/ وأعد تسمية مجلّد plugins إلى plugins-off. عبر SSH على الـVPS، نفّذ:

cd /home/user/public_html/wp-content
mv plugins plugins-off

افتح الموقع الآن: إن عاد للعمل، فأحد الإضافات هو السبب. أعد التسمية للأصل (mv plugins-off plugins)، ثم عطّل الإضافات واحدة تلو الأخرى بإعادة تسمية مجلّد كل إضافة على حدة حتى يعود العطل — تلك هي المتّهمة:

cd /home/user/public_html/wp-content/plugins
mv suspect-plugin suspect-plugin-disabled

التحويل لقالب افتراضي

إن استمرّ العطل بعد تعطيل كل الإضافات، فالقالب هو المشتبه التالي. أعد تسمية مجلّد قالبك النشط داخل wp-content/themes/:

cd /home/user/public_html/wp-content/themes
mv my-theme my-theme-disabled

عند عدم وجود القالب النشط، يرجع ووردبريس تلقائيًا لأحدث قالب افتراضي مثبّت (مثل twentytwentyfour). تأكّد من وجود قالب افتراضي واحد على الأقل في المجلّد. إن عاد الموقع، فالعطل في قالبك — راجع آخر تعديل أجريته عليه أو حدّثه.

التعطيل عبر phpMyAdmin (إن تعذّر FTP)

طريقة بديلة لتعطيل كل الإضافات عبر قاعدة البيانات مباشرة: افتح phpMyAdmin، اختر جدول wp_options، ابحث عن الصفّ active_plugins، وعدّل قيمته إلى سلسلة فارغة (a:0:{}). هذا يعطّل كل الإضافات فورًا. الجدول التالي يلخّص طرق العزل حسب أداة الوصول المتاحة:

كيف تحلّ خطأ 500 Internal Server Error؟

خطأ «500 Internal Server Error» رسالة عامّة من الخادم تعني «حدث خطأ ما لكنني لا أستطيع تحديده». في ووردبريس، أشهر أسبابه ثلاثة: ملف .htaccess تالف، تجاوز حدّ ذاكرة PHP، أو إضافة/قالب يطلق خطأً على مستوى الخادم. خلافًا للشاشة البيضاء، قد يظهر 500 حتى قبل تحميل ووردبريس، لذا قد لا يلتقطه debug.log — راجع سجلّ خطأ الخادم (Apache/Nginx) أيضًا.

فهم أكواد أخطاء الخادم 5xx

قبل الحل، ميّز بين أكواد الأخطاء لأن كلًّا منها يشير لمصدر مختلف:

أكواد 502/504 غالبًا مشاكل خادم أو أداء (PHP-FPM، مهلة التنفيذ)، بينما 500 يميل لمشاكل التطبيق نفسه. إن واجهت 504 متكرّرًا فالموقع قد يحتاج موارد أكبر — راجع متى تنتقل إلى VPS.

إعادة توليد ملف .htaccess الافتراضي

السبب الأوّل لخطأ 500 هو ملف .htaccess تالف (قد يفسده تحديث إضافة أو تعديل يدوي خاطئ). الحلّ: أعد تسمية .htaccess الحالي إلى .htaccess-old عبر FTP، ثم جرّب الموقع. إن عاد للعمل، فالملف كان السبب. أنشئ ملف .htaccess جديدًا في الجذر بالمحتوى الافتراضي لووردبريس:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

ثم ادخل لوحة الإدارة (إن عادت) واذهب إلى «الإعدادات ← الروابط الدائمة» واحفظ دون تغيير — هذا يعيد توليد القواعد تلقائيًا. لاحظ أن الملف يبدأ بنقطة (.htaccess) لذا قد يكون مخفيًا في مدير الملفات؛ فعّل «إظهار الملفات المخفيّة».

رفع حدّ الذاكرة وفحص الإضافات

إن لم يكن .htaccess السبب، فارفع الذاكرة (القسم التالي) ثم عطّل الإضافات بالاستبعاد كما شرحنا. الجدول التالي قائمة تشخيص خطأ 500 بالترتيب:

كيف تتجاوز حدّ ذاكرة PHP؟

كثير من أخطاء ووردبريس — الشاشة البيضاء، فشل رفع الصور، تعطّل لوحة الإدارة عند صفحة معيّنة — سببها الحقيقي نفاد ذاكرة PHP. الرسالة الكلاسيكية في السجلّ: Allowed memory size of 134217728 bytes exhausted. الحلّ رفع الحدّ المخصّص لووردبريس.

رفع WP_MEMORY_LIMIT في wp-config.php

أضف هذين السطرين إلى wp-config.php قبل /* That's all, stop editing! */:

// حدّ الذاكرة للواجهة
define( 'WP_MEMORY_LIMIT', '256M' );

// حدّ أعلى للوحة الإدارة (عمليات أثقل)
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

إن لم يرفع هذا الحدّ فعليًا (بعض الاستضافات تقيّده على مستوى php.ini)، فأضف في ملف php.ini أو عبر لوحة الاستضافة: memory_limit = 256M. وفي بعض البيئات يمكن وضع توجيه في .htaccess: php_value memory_limit 256M. الجدول التالي يوصي بحدود الذاكرة حسب نوع الموقع:

ارفع الذاكرة بقدر الحاجة لا أكثر — رفعها بلا داعٍ على استضافة مشتركة قد يخالف حدود المزوّد. إن وصلت لـ512M وما زلت تنفد، فالمشكلة غالبًا إضافة سيّئة الكتابة (تسريب ذاكرة) لا الحدّ نفسه.

رفع حدود الرفع (Upload Limits)

مشكلة قريبة: فشل رفع صورة أو قالب أو إضافة كبيرة برسالة «الملف يتجاوز الحجم الأقصى». هذه حدود رفع منفصلة عن الذاكرة. عدّلها في php.ini:

upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

في الاستضافة المشتركة قد تحتاج لطلب رفعها من الدعم. وعلى الـVPS تعدّلها بنفسك ثم تعيد تشغيل PHP-FPM. هذه الحدود نفسها تؤثّر على نقل الموقع — راجع نقل ووردبريس بدون توقّف قبل أي ترحيل.

كيف تصلح خطأ الاتصال بقاعدة البيانات؟

«Error establishing a database connection» من أكثر الأخطاء إثارة للقلق لأنه يعطّل الموقع بالكامل، لكن أسبابه محدّدة وقابلة للحل. ووردبريس يخزّن كل المحتوى (المقالات، الإعدادات، المستخدمين) في قاعدة بيانات MySQL، وهذا الخطأ يعني أنه عجز عن الاتصال بها. الأسباب الأربعة الكبرى: بيانات دخول خاطئة في wp-config.php، خادم قاعدة البيانات متوقّف، جداول تالفة، أو ضغط زائد على الخادم.

تصحيح بيانات الاتصال في wp-config.php

أوّل ما تفحصه: أربعة ثوابت في wp-config.php يجب أن تطابق ما في لوحة الاستضافة بالضبط:

define( 'DB_NAME', 'اسم_قاعدة_البيانات' );     // اسم القاعدة
define( 'DB_USER', 'اسم_المستخدم' );           // مستخدم القاعدة
define( 'DB_PASSWORD', 'كلمة_المرور' );        // كلمة مرور المستخدم
define( 'DB_HOST', 'localhost' );             // غالبًا localhost

أكثر الأخطاء شيوعًا: تغيير كلمة مرور قاعدة البيانات من لوحة الاستضافة دون تحديثها في wp-config.php، أو خطأ في DB_HOST (بعض المزوّدين يستخدمون عنوانًا مخصّصًا لا localhost). تحقّق من القيم الصحيحة من قسم «MySQL Databases» في cPanel. الجدول التالي يربط أعراض خطأ قاعدة البيانات بأسبابها:

إصلاح جداول قاعدة البيانات التالفة

إن كانت البيانات صحيحة لكن الجداول تالفة، يوفّر ووردبريس إصلاحًا تلقائيًا مدمجًا. أضف هذا السطر مؤقّتًا إلى wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

ثم افتح في المتصفّح الرابط: https://yoursite.com/wp-admin/maint/repair.php واختر «Repair Database» (أو «Repair and Optimize»). بعد انتهاء الإصلاح، احذف السطر فورًا لأن هذه الصفحة لا تتطلّب تسجيل دخول ويمكن لأي شخص الوصول إليها. بديلًا، يمكنك الإصلاح من phpMyAdmin: اختر الجداول، ثم من القائمة المنسدلة اختر «Repair table».

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

كيف تصل لموقعك عند فقد لوحة الإدارة؟

أصعب لحظة هي حين ينهار الموقع وتفقد الوصول للوحة wp-admin نفسها، فلا تستطيع تعطيل أي شيء من الداخل. هنا تنقذك ثلاث أدوات وصول خلفية لا تعتمد على لوحة ووردبريس إطلاقًا:

استعادة كلمة مرور المشرف عبر phpMyAdmin

إن نسيت كلمة مرور المشرف ولم يصل بريد الاستعادة، يمكن تعيينها مباشرة في قاعدة البيانات: افتح phpMyAdmin، اختر جدول wp_users، عدّل صفّ المستخدم، وفي حقل user_pass اختر دالّة MD5 من القائمة المنسدلة ثم اكتب كلمة المرور الجديدة. ووردبريس يقبل MD5 ويعيد تشفيرها بأمان عند أوّل دخول.

استخدام WP-CLI على الـVPS

إن كان موقعك على VPS، فأداة WP-CLI أسرع وسيلة لإدارة الأعطال من سطر الأوامر دون لوحة. أمثلة عملية:

# تعطيل كل الإضافات دفعة واحدة
wp plugin deactivate --all

# تفعيل قالب افتراضي
wp theme activate twentytwentyfour

# مسح الكاش (إن كانت إضافة كاش هي السبب)
wp cache flush

# فحص سلامة ملفات النواة مقابل النسخة الرسمية
wp core verify-checksums

أمر verify-checksums تحديدًا قوي: يقارن ملفات نواتك بالنسخة الرسمية ويكشف أي ملف معدّل أو محقون — مفيد جدًا عند الاشتباه باختراق. إن كشف ملفات معدّلة فقد يكون موقعك مصابًا؛ راجع اكتشاف وإزالة برمجيات الموقع الخبيثة للخطوات.

كيف تتعامل مع الأخطاء بعد التحديث أو تثبيت إضافة؟

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

قاعدة «آخر تغيير هو المتّهم»

إذا انهار الموقع بعد تثبيت إضافة معيّنة، عطّلها عبر FTP (أعد تسمية مجلّدها) وسيعود الموقع فورًا. إذا انهار بعد تحديث إضافة، ارجع للنسخة السابقة منها (إضافة WP Rollback إن كانت اللوحة تعمل، أو رفع النسخة القديمة يدويًا عبر FTP). الجدول التالي قائمة التحقّق قبل أي تحديث لتفادي الكارثة أصلًا:

ملف الصيانة العالق

خطأ شائع بعد تحديث متوقّف: رسالة «Briefly unavailable for scheduled maintenance». يحدث حين يضع ووردبريس ملف .maintenance في الجذر أثناء التحديث ثم يفشل قبل حذفه. الحل بسيط جدًا: احذف ملف .maintenance من جذر الموقع عبر FTP، فيعود الموقع فورًا. لاحظ أن الملف مخفيّ (يبدأ بنقطة) فعليك تفعيل إظهار الملفات المخفيّة.

كيف تقي موقعك من الأخطاء قبل وقوعها؟

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

الركيزة الأولى: نسخ احتياطي منتظم

النسخة الاحتياطية هي الفرق بين عطل مزعج وكارثة كاملة. مع نسخة حديثة، أسوأ سيناريو هو استرجاع يستغرق دقائق. اجعل النسخ تلقائيًا وخارج الخادم (Off-site)، فلا تعتمد على نسخة مخزّنة على نفس الخادم الذي قد ينهار.

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

الركيزة الثانية: بيئة تجريبية (Staging)

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

الركيزة الثالثة: تحديثات منظّمة وحدّ أدنى من الإضافات

كل إضافة سطح هجوم محتمل ومصدر تعارض. ثبّت ما تحتاجه فعلًا فقط، واحذف المعطّل، وحدّث بانتظام لكن بحذر (واحدًا تلو الآخر، بعد نسخة احتياطية). الجدول التالي يلخّص عادات الوقاية:

الأمان جزء أصيل من الاستقرار — موقع مخترق يعطل بطرق غامضة. عزّز دفاعك بطبقات كما في الرسم التالي:

وللعمق الكامل راجع تأمين موقع ووردبريس، وللأداء الذي يقلّل أخطاء المهلة والـ504 راجع تسريع موقع ووردبريس.

متى تتواصل مع الدعم الفنّي؟

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

• استمرار خطأ قاعدة البيانات بعد تصحيح wp-config.php (قد يكون خادم MySQL متوقّفًا عندهم).
• أخطاء 502/503/504 متكرّرة لا تزول بتعطيل الإضافات (مشكلة موارد أو إعداد خادم).
• حاجة لرفع حدود php.ini (الذاكرة، الرفع، مهلة التنفيذ) على استضافة مشتركة.
• اشتباه باختراق أو ملفات محقونة لا تستطيع تنظيفها بنفسك.
• بطء أو انقطاع متكرّر يشير لحاجة ترقية الموارد.

قبل التواصل، جهّز المعلومات لتسريع الحل: نصّ الخطأ بالضبط، آخر تغيير أجريته، الخطوات التي جرّبتها، ومقتطف من debug.log. الدعم الجيّد يحلّ في دقائق ما قد يستغرقك ساعات.

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

لماذا يعرض موقعي شاشة بيضاء فارغة تمامًا؟

الشاشة البيضاء (WSOD) تعني أن سكربت PHP توقّف فجأة دون عرض رسالة، غالبًا بسبب خطأ فادح في إضافة أو قالب أو نفاد ذاكرة PHP. الحل: فعّل WP_DEBUG_LOG في wp-config.php واقرأ ملف wp-content/debug.log ليكشف الملف والسطر المتسبّب، ثم ارفع حدّ الذاكرة وعطّل الإضافات بالاستبعاد.

كيف أفعّل WP_DEBUG إن لم أصل للوحة الإدارة؟

عبر FTP أو مدير الملفات في cPanel. حمّل ملف wp-config.php من جذر الموقع، أضف define( 'WP_DEBUG', true ); وdefine( 'WP_DEBUG_LOG', true ); قبل سطر /* That's all, stop editing! */، ثم ارفع الملف. افتح الصفحة المعطوبة مرّة، ثم اقرأ wp-content/debug.log. لا تحتاج لوحة الإدارة إطلاقًا.

ما الفرق بين الشاشة البيضاء و«حدث خطأ حرج»؟

كلاهما ناتج عن خطأ فادح، لكن «حدث خطأ حرج» هو السلوك الحديث (منذ ووردبريس 5.2): يلتقط ووردبريس الخطأ ويعرض رسالة مهذّبة ويرسل بريدًا فيه رابط وضع الاسترداد. الشاشة البيضاء هي السلوك القديم أو يظهر حين يقع الخطأ في النواة نفسها أو عند نفاد ذاكرة شامل قبل أن تعمل آلية الالتقاط.

كيف أعطّل كل الإضافات وأنا لا أصل للوحة؟

عبر FTP، انتقل إلى wp-content/ وأعد تسمية مجلّد plugins إلى plugins-off. هذا يعطّل كل الإضافات فورًا. إن عاد الموقع، أعد التسمية للأصل ثم عطّل الإضافات واحدة تلو الأخرى لتحديد المتّسبب. بديلًا، يمكنك تفريغ قيمة active_plugins في جدول wp_options عبر phpMyAdmin.

كيف أصلح خطأ «Error establishing a database connection»؟

تحقّق أولًا من تطابق DB_NAME وDB_USER وDB_PASSWORD وDB_HOST في wp-config.php مع القيم في لوحة الاستضافة (قسم MySQL Databases). أكثر سبب شيوعًا تغيير كلمة مرور القاعدة دون تحديث الملف. إن كانت البيانات صحيحة فقد تكون الجداول تالفة: أضف define( 'WP_ALLOW_REPAIR', true ); وافتح /wp-admin/maint/repair.php، ثم احذف السطر بعد الإصلاح.

كم يجب أن يكون حدّ ذاكرة PHP لووردبريس؟

256M قيمة متّزنة لمعظم المواقع. المدوّنات البسيطة تكفيها 128M–256M، ومتاجر WooCommerce تحتاج 256M–512M. أضف define( 'WP_MEMORY_LIMIT', '256M' ); إلى wp-config.php. إن وصلت لـ512M وما زلت تنفد الذاكرة فالمشكلة غالبًا إضافة سيّئة الكتابة لا الحدّ.

ما سبب خطأ 500 وكيف أحلّه سريعًا؟

أشهر سبب لخطأ 500 ملف .htaccess تالف. أعد تسميته إلى .htaccess-old عبر FTP وجرّب الموقع؛ إن عاد فأنشئ .htaccess جديدًا بالمحتوى الافتراضي لووردبريس واحفظ «الروابط الدائمة» من اللوحة. إن لم ينجح، ارفع حدّ الذاكرة وعطّل الإضافات بالاستبعاد، وراجع سجلّ خطأ الخادم لأن 500 قد لا يظهر في debug.log.

ماذا أفعل لو وصلني بريد «حدث خطأ حرج»؟

افتح البريد فهو يحوي اسم الإضافة أو القالب المتسبّب ورسالة الخطأ ورابط وضع الاسترداد (Recovery Mode). اضغط الرابط لتدخل لوحة الإدارة في وضع آمن مع العنصر المعطوب معطّلًا تلقائيًا، ثم احذفه أو حدّثه أو استبدله، واخرج من وضع الاسترداد. إن لم يصلك بريد فعطّل الإضافات يدويًا عبر FTP.

هل تفعيل WP_DEBUG خطر على موقعي الحيّ؟

ليس خطرًا إن ضبطته صحيحًا: استخدم WP_DEBUG_LOG مع WP_DEBUG_DISPLAY بقيمة false ليُسجَّل الخطأ في ملف بدل عرضه للزوّار. لكن لا تتركه مفعّلًا بعد انتهاء التشخيص، لأن عرض الأخطاء يسرّب مسارات الخادم وقد يكشف معلومات تفيد المهاجم. أعِده إلى false واحذف debug.log بعد القراءة.

كيف أمنع تكرار أخطاء ووردبريس مستقبلًا؟

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

هل يمكن أن تفقد بياناتي عند حلّ هذه الأخطاء؟

نادرًا جدًا. معظم أخطاء ووردبريس (الشاشة البيضاء، 500، الخطأ الحرج) مشاكل في الكود أو الإعدادات لا في البيانات، وحلّها لا يمسّ محتواك. الخطر الحقيقي الوحيد على البيانات هو التعديل الخاطئ على قاعدة البيانات أو حذف ملفات بلا فهم — ولهذا تبدأ كل عملية بنسخة احتياطية. مع نسخة حديثة، بياناتك آمنة دائمًا.

الخلاصة

أخطاء ووردبريس تبدو مرعبة لكنها قابلة للحل بمنهج منظّم: نسخة احتياطية، ثم تفعيل WP_DEBUG وقراءة السجلّ، ثم عزل السبب بالاستبعاد، ثم الإصلاح والتحقّق. لا تخمّن — السجلّ يدلّك على الملف والسطر بالضبط، وأدوات الوصول الخلفية (FTP/SSH/phpMyAdmin) تبقي كل الحلول في متناولك حتى لو فقدت لوحة الإدارة. والأهم: الوقاية بالنسخ الاحتياطي والبيئة التجريبية والتحديث المنظّم تحوّل أغلب الكوارث المحتملة إلى استرجاعات تستغرق دقائق.

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

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار