صفحه سفید مرگ در وردپرس؛ توضیح کامل

صفحه سفید مرگ در واقع یک خطای مهلک PHP است که نمی‌بینیدش. وردپرس وسط رندر شدن به خطایی برخورده که قابل بازیابی نیست، PHP متوقف شده و چون نمایش خطا روی سرورهای production خاموش است، به جای چاپ کردن دلیل خطا، صفحه‌ای خالی برگردانده شده. رفع این مشکل تقریباً هیچ‌وقت حدس و گمان نیست: لاگ دیباگ را روشن کنید، فایل wp-content/debug.log را باز کنید و آخرین خط fatal را بخوانید. این خط دقیقاً نام فایل مقصر را می‌گوید — که تقریباً همیشه یک افزونه یا قالب است — و همان یک خط، کل ماجرای تعمیر است.

چرا صفحه خالی است

PHP تنظیمی به نام display_errors دارد. روی یک ماشین توسعه معمولاً روشن است، پس خطای مهلک یک stack trace روی صفحه چاپ می‌کند. اما روی یک هاست واقعی به‌صورت پیش‌فرض خاموش است، چون لو دادن مسیر فایل‌ها و خطاها به بازدیدکننده‌ها یک مشکل امنیتی است. پس وقتی چیزی خطای مهلک می‌دهد — فراخوانی تابعی که دیگر وجود ندارد، کلاسی که بارگذاری نشده، یا خطای نحوی در به‌روزرسانی یک افزونه — PHP از کار می‌افتد و چیزی ارسال نمی‌کند. مرورگر شما یک سند خالی نمایش می‌دهد. این همان «صفحه سفید» است.

از وردپرس ۵.۲ به بعد یک هندلر خطای مهلک (WP_Fatal_Error_Handler) وجود دارد که تلاش می‌کند این خطاها را بگیرد. وقتی کار کند، صفحه خالی نمی‌بینید — پیام «یک خطای مهم در این وب سایت رخ داده است» را می‌بینید، به‌علاوه ایمیلی به آدرس مدیر که اغلب خودِ خطای واقعی و لینکی به حالت بازیابی (Recovery Mode) را در بر دارد. یک صفحه واقعاً خالی معمولاً یعنی خطا پیش از آنکه این هندلر بتواند اجرا شود شلیک شده: یک خطای نحوی/پارس (که در زمان کامپایل گرفته می‌شود)، یک افزونه must-use خراب، یا یک خطای مهلک در فایل functions.php قالب فعال. در هر صورت، علت جایی نوشته شده است. فقط باید نوشتن را روشن کنید.

رفعش کنید، به ترتیب

۱. لاگ را روشن کنید. فایل wp-config.php را از طریق SFTP ویرایش کنید و این خطوط را بالای خط /* That's all, stop editing! */ اضافه کنید:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

مقدار false برای WP_DEBUG_DISPLAY خطاها را از صفحه عمومی دور نگه می‌دارد، در حالی که WP_DEBUG_LOG آن‌ها را در wp-content/debug.log می‌نویسد. یک بار صفحه خراب را دوباره بارگذاری کنید تا یک ورودی تازه ساخته شود.

۲. آخرین خطای مهلک را بخوانید. فایل wp-content/debug.log را باز کنید و به انتهای آن نگاه کنید:

tail -n 30 wp-content/debug.log

دنبال خطی مثل این می‌گردید:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

مسیر، مقصر را نام می‌برد: plugins/some-addon. این جواب شماست. اگر trace طولانی است یا پیام مبهم است (Allowed memory size exhausted، Cannot redeclare، یا نام کلاسی که نمی‌شناسید)، آن را در رمزگشای لاگ خطا ما جای‌گذاری کنید — نویز را حذف می‌کند، به شما می‌گوید مسیر به کدام افزونه یا قالب اشاره دارد و توضیح می‌دهد که آن نوع خطای خاص یعنی چه.

۳. مؤلفه نام‌برده‌شده را غیرفعال کنید. به /wp-admin دسترسی ندارید، پس این کار را از طریق SFTP انجام دهید. نام پوشه افزونه خاطی را تغییر دهید، مثلاً some-addon را به some-addon.off. وردپرس نمی‌تواند پوشه‌ای را که پیدا نمی‌کند بارگذاری کند، پس افزونه را غیرفعال می‌کند و سایت برمی‌گردد. اگر لاگ به قالب شما اشاره می‌کند، با تغییر نام پوشه قالب فعال، به یک قالب پیش‌فرض سوئیچ کنید — وردپرس به یک قالب همراهش مثل twentytwentysomething برمی‌گردد.

۴. اگر لاگ نوشته نمی‌شود، یعنی wp-content قابل نوشتن نیست، یا خطا در سطح سرور است. به‌جایش لاگ خطای PHP خودِ هاست را بررسی کنید:

find . -name "error_log" -newermt "-1 hour"

همان اطلاعات، فایل متفاوت. استک‌های cPanel/Apache اغلب یک error_log در ریشه سایت یا در دایرکتوری خطادار می‌گذارند.

چه کارهایی نکنید

فقط محدودیت حافظه را بالا نبرید. پرتکرارترین توصیه‌ای که آنلاین می‌بینید این است که WP_MEMORY_LIMIT را به 256M یا 512M افزایش دهید. این فقط زمانی صفحه سفید را رفع می‌کند که لاگ واقعاً بگوید Allowed memory size of N bytes exhausted. اگر خطا Call to undefined function است، حافظه بیشتر هیچ کاری نمی‌کند — یک تنظیم را الکی عوض کرده‌اید و صفحه هنوز سفید است. اول لاگ را بخوانید، بعد فقط در صورتی حافظه را بالا ببرید که حافظه مشکلِ بیان‌شده باشد.

کش را پاک نکنید و اسمش را عیب‌یابی نگذارید. صفحه سفید یعنی PHP روی سرور، پیش از آنکه هیچ HTMLای وجود داشته باشد، از کار افتاده است. یک فایل کش‌شده قدیمی نمی‌تواند باعث سند خالی شود. (یک افزونه کش خراب می‌تواند — اما لاگ نامش را می‌برد، که نکته اصلی همین است.)

هسته وردپرس را ویرایش یا دوباره‌نصب نکنید. خطای مهلک تقریباً هیچ‌وقت در wp-includes یا wp-admin نیست؛ در همان افزونه یا قالبی است که لاگ به آن اشاره می‌کند. نصب مجدد هسته کند و پرریسک است و علامتی را درمان می‌کند که تأییدش نکرده‌اید.

همه افزونه‌ها را غیرفعال و بعد کورکورانه یکی‌یکی دوباره فعال نکنید. روش دوبخشی (bisect) جواب می‌دهد، اما مسیر کند است. لاگ پوشه دقیق را در یک قدم به شما می‌گوید. فقط زمانی سراغ روش «همه‌چیز را خاموش کن» بروید که اصلاً هیچ خطای قابل‌خواندنی وجود نداشته باشد.

display_errors را در production روشن رها نکنید. به‌محض اینکه سایت برگشت، define‌های دیباگ را حذف کنید (یا WP_DEBUG را دوباره false کنید). خطاهایی که برای بازدیدکننده‌ها چاپ می‌شوند مسیرهای شما را افشا می‌کنند.

هنوز گیر کرده‌اید؟

اگر لاگ یک افزونه را نام می‌برد اما غیرفعال کردنش صفحه را پاک نمی‌کند، یعنی زیر خطای اول یک خطای مهلک دوم هست — لاگ را دوباره روشن کنید و آخرین خط جدید را بخوانید؛ خطاهای مهلک روی هم انباشته می‌شوند. اگر خودِ پیام دیوار مقابل شماست، آن را در رمزگشای لاگ خطا بیندازید و بگذارید نوع خطا و مسیر فایل را برایتان ترجمه کند. صفحه سفید فقط تا وقتی که لاگ خاموش است یک معما باقی می‌ماند.