چگونه خطای سفید صفحه مرگ در وردپرس را برطرف کنیم؟

ساعت یازده شب است، مشتری زنگ می‌زند و می‌گوید: «سایتم سفید شده، هیچ‌چیز نشان نمی‌دهد.» پیشخوان هم باز نمی‌شود. چند بار F5 می‌زنم؛ صفحهٔ سفید خالی. سکوت مطلق. نه خطایی، نه پیامی، نه حتی یک کاراکتر. این همان چیزی است که در دنیای وردپرس با نام White Screen of Death (به اختصار WSOD) شناخته می‌شود — و از دید کاربر، بدترین نوع خرابی است؛ چون هیچ سرنخی نمی‌دهد. تجربه‌ام می‌گوید پشت هر صفحهٔ سفید، یکی از شش علت مشخص قرار دارد؛ اگر این شش علت را بشناسید، در بیش‌تر موارد در کمتر از سی دقیقه سایت به زندگی برمی‌گردد.

صفحهٔ سفید مرگ (WSOD) دقیقاً چیست؟

صفحهٔ سفید مرگ، یک حالت خاص از خطای وردپرس است که در آن هیچ چیزی برای کاربر نمایش داده نمی‌شود — نه محتوای سایت، نه هدر، نه فوتر، نه حتی پیام خطای فارسی که وردپرس معمولاً برای مسائل ساده نشان می‌دهد. فقط یک صفحهٔ کاملاً سفید. گاهی حتی در پیشخوان هم همین حالت تکرار می‌شود و مدیر سایت نمی‌تواند وارد شود.

تفاوت مهمی که باید بدانید: WSOD با خطای ۵۰۰، خطای ۴۰۳ و خطای ۵۰۳ فرق دارد. در خطای ۵۰۰، مرورگر یک صفحهٔ خطای سرور نشان می‌دهد (مثل «Internal Server Error»). در خطای ۴۰۳، پیام «Forbidden» می‌آید. اما در WSOD، پاسخ HTTP معمولاً کد ۲۰۰ است — یعنی سرور می‌گوید «همه‌چیز خوب است»، ولی محتوایی که می‌فرستد خالی است. این تفاوت، عیب‌یابی را سخت‌تر می‌کند، چون ابزارهای معمول سرور، مشکل را «عادی» می‌بینند.

اگر تازه با ساختار وردپرس آشنا می‌شوید، پیش از هر چیز توصیه می‌کنم مقالهٔ وردپرس چیست و چگونه شروع کنیم را بخوانید. همچنین درک نحوهٔ کار هسته و لایهٔ نمایش در ساختار هسته وردپرس به شما کمک می‌کند بفهمید چرا یک خطای کوچک در functions.php می‌تواند کل سایت را از کار بیندازد.

صفحهٔ سفید، بدترین نوع خطای وردپرس است؛ چون هیچ سرنخی نمی‌دهد. کار مهندس، بازگرداندن پیام گم‌شده است، نه حدس‌زدن مقصر.

چرا وردپرس به‌جای پیام خطا، صفحهٔ سفید نشان می‌دهد؟

پاسخ در تنظیمات PHP نهفته است. به‌طور پیش‌فرض، PHP روی سرورهای تولیدی (Production) طوری تنظیم شده که خطاها را «نمایش ندهد». هدف این تنظیم امنیتی است: خطاهای PHP می‌توانند مسیر فایل، نام کاربری دیتابیس و جزئیات معماری سرور را افشا کنند. پس مدیر سرور display_errors را خاموش و error_reporting را محدود می‌کند.

نتیجه این است: وقتی کدی در وردپرس خطای Fatal (کشنده) می‌دهد، PHP اجرای اسکریپت را متوقف می‌کند، هیچ پیامی چاپ نمی‌کند، و وردپرس نمی‌تواند ادامه دهد. آنچه به مرورگر می‌رسد، یک HTML نیمه‌کاره یا خالی است. همین لحظه است که صفحهٔ سفید رخ می‌دهد.

یک نکتهٔ ظریف که در جلسه‌های مشاوره زیاد می‌بینم: بعضی مدیران سایت، برای «رفع سریع» مشکل، display_errors را روی On می‌گذارند تا خطا را ببینند. این کار در استجینگ یا لوکال، اشکالی ندارد و یکی از ابزارهای مهم عیب‌یابی است؛ ولی روی سایت زنده، خطاها به‌طور کامل به کاربران نمایش داده می‌شوند و می‌تواند حفرهٔ امنیتی جدی ایجاد کند. تفصیل این موضوع در راهنمای امنیت وردپرس برای مبتدیان آمده است.

شش علت رایج صفحهٔ سفید در وردپرس

در تجربه‌ام، این شش علت تقریباً تمام پرونده‌ها را پوشش می‌دهند:

1. کمبود حافظهٔ PHP (Memory Exhaustion): شایع‌ترین علت. اگر memory_limit کمتر از نیاز باشد، PHP خطای Fatal می‌دهد و صفحه سفید می‌شود. این حالت معمولاً بعد از نصب یک افزونهٔ سنگین یا آپدیت قالب رخ می‌دهد.
2. خطای Parse در فایل‌های PHP: اگر در functions.php یا هر فایل PHP قالب و افزونه، یک سمیکالن یا آکولاد جا افتاده باشد، کل سایت سفید می‌شود. این خطا معمولاً بعد از ویرایش دستی کد رخ می‌دهد. راهنمای رفع در خطای Parse error در فایل functions.php آمده است.
3. تعارض افزونه‌ها: دو افزونه که هم‌زمان یک hook مشترک را در اختیار می‌گیرند یا تابعی با نام یکسان تعریف می‌کنند، می‌توانند سایت را به سفیدی ببرند.
4. مشکل در قالب فعال: یک قالب خراب یا ناقص، یا تعارض بین قالب و افزونه، می‌تواند باعث WSOD شود. روش تشخیص در چگونه خطای قالب وردپرس را عیب‌یابی کنیم توضیح داده شده است.
5. کد سفارشی معیوب: اسنیپت‌های افزود‌شده به functions.php چایلد تم یا استفاده از کد از منابع نامعتبر، معمولاً با یک اشتباه کوچک کل سایت را از کار می‌اندازند.
6. افزایش اجباری نسخهٔ PHP یا ناسازگاری با آن: اگر هاست نسخهٔ PHP را از ۷.۴ به ۸.۲ ارتقا دهد و افزونه‌ای کد ناسازگار داشته باشد، WSOD بی‌درنگ رخ می‌دهد.

جدول زیر برای تشخیص سریع در جلسه‌های عیب‌یابی همیشه کمک کرده:

تشخیص سریع: از کجا شروع کنیم؟

در لحظه‌ای که با صفحهٔ سفید مواجه می‌شوید، سه اصل را دنبال کنید: آرامش، مستندسازی، و اول از همه، فعال‌سازی ابزار دیدن خطا. سه ابزار کلیدی در جعبه‌ابزار من همیشه حاضرند:

ابزار اول: فعال‌سازی WP_DEBUG در wp-config.php

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

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SCRIPT_DEBUG', true );

سه نکته در این تنظیمات:

• WP_DEBUG حالت دیباگ را روشن می‌کند.
• WP_DEBUG_LOG خطاها را در فایل wp-content/debug.log ذخیره می‌کند.
• WP_DEBUG_DISPLAY را روی false نگه دارید تا خطاها به کاربر نمایش داده نشوند.

حالا سایت را ریلود کنید و فایل debug.log را باز کنید. در بیش‌تر موارد، نام فایل، شماره خط و نام افزونه یا قالب مقصر، دقیقاً در همان فایل نوشته شده است. این مرحله، کلید ورود به فاز دوم عیب‌یابی است.

ابزار دوم: غیرفعال‌سازی از طریق FTP

اگر پیشخوان هم باز نمی‌شود، باید از FTP وارد شوید و پوشهٔ افزونه‌ها را تغییرنام دهید. مسیر پوشه: wp-content/plugins. نام آن را موقتاً به plugins-disabled تغییر دهید. وردپرس به‌طور خودکار همهٔ افزونه‌ها را غیرفعال در نظر می‌گیرد. اگر سایت برگشت، مقصر در میان افزونه‌ها است.

نکته: تغییرنام پوشه، فقط برای تشخیص است. بعد از پایان، نام را برگردانید و افزونه‌ها را یکی‌یکی از پیشخوان فعال کنید تا مقصر را پیدا کنید — همان روشی که در چگونه افزونه مشکل‌ساز وردپرس را پیدا کنیم گام‌به‌گام توضیح داده‌ام.

ابزار سوم: تغییر قالب به پیش‌فرض از دیتابیس یا FTP

اگر با غیرفعال‌سازی افزونه‌ها مشکل حل نشد، سراغ قالب بروید. از FTP، پوشهٔ wp-content/themes/your-active-theme را موقتاً تغییرنام دهید. وردپرس به قالب پیش‌فرض (مثل Twenty Twenty-Four) بازمی‌گردد. اگر سایت برگشت، مقصر قالب فعلی یا چایلد تم است. برای بررسی دقیق‌تر خطای قالب، مرجع چگونه خطای قالب را در وردپرس دیباگ کنیم را ببینید.

ابزار چهارم: بررسی لاگ خطای سرور

اگر هیچ‌کدام از ابزارهای بالا خطا را نشان ندادند، لاگ سرور را بررسی کنید. در cPanel، از بخش «Error Log» یا از مسیر /home/username/logs قابل دسترسی است. بعضی خطاهای PHP فقط در این لاگ ثبت می‌شوند — به‌ویژه خطاهای سطح سرور یا مسائل مربوط به مجوز فایل.

در پرونده‌های WSOD، اولین سؤال همیشه این است: «چه چیزی از آخرین بار تغییر کرده؟» نُه مورد از ده مورد، پاسخ در همین یک سؤال خلاصه می‌شود.

راه‌حل‌های گام‌به‌گام رفع صفحهٔ سفید

بسته به علت، یکی از این پنج مسیر را انتخاب کنید:

مسیر اول: افزایش حافظهٔ PHP

اگر خطای Allowed memory size exhausted در لاگ دیده می‌شود، مقدار حافظه را افزایش دهید. سه راه دارید:

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

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

تفاوت این دو خط مهم است: WP_MEMORY_LIMIT برای درخواست‌های فرانت‌اند اعمال می‌شود و WP_MAX_MEMORY_LIMIT برای پیشخوان و آپلود — یعنی همان جایی که به حافظهٔ بیشتر نیاز دارید.

ب) از فایل .htaccess: اگر سرور شما Apache است، این خطوط را اضافه کنید:

php_value memory_limit 256M
php_value max_execution_time 300

پ) از پنل هاست: در cPanel، از «MultiPHP INI Editor» یا «Select PHP Version» مقدار memory_limit را افزایش دهید. این تمیزترین راه است، چون در فایل‌های وردپرس دست نمی‌برد.

مسیر دوم: بازگردانی از بکاپ

اگر مقصر، خطای Parse در یک فایل قالب یا functions.php است و نمی‌دانید کدام خط خراب شده، سریع‌ترین راه بازگردانی از بکاپ است. اگر بکاپ ندارید، اول از همه یک بکاپ از وضعیت فعلی بگیرید — حتی اگر خراب است — چون در صورت خرابی بیشتر، همین نسخه نجاتتان می‌دهد. روش بکاپ را در چگونه از سایت وردپرسی بکاپ بگیریم گام‌به‌گام توضیح داده‌ام. برای بازگردانی، مرجع بازیابی سایت از بکاپ راهنمای دقیقی دارد.

اگر بکاپ ندارید و می‌دانید ویرایش آخر در functions.php بوده، می‌توانید از طریق FTP آن فایل را باز کنید و آخرین تغییرات را حذف کنید. یک روش امن: نسخهٔ اصلی را از پوشهٔ wp-content/themes/your-theme/ در بستهٔ نصب قالب دوباره آپلود کنید — ولی این کار تغییرات دیگرتان را هم پاک می‌کند. اگر تغییرات زیاد است، بازگردانی از نسخهٔ قبلی همین فایل (اگر نسخه‌ای در گیت نگه می‌دارید) انتخاب بهتری است.

مسیر سوم: رفع تعارض افزونه‌ها

اگر با غیرفعال‌سازی پوشهٔ plugins سایت برگشت، مقصر در میان افزونه‌ها است. افزونه‌ها را دوبه‌دو فعال کنید تا مقصر پیدا شود. اگر تعداد زیاد است، روش تقسیم دوتایی — همان روشی که در مقالهٔ پیدا کردن افزونهٔ مشکل‌ساز توضیح دادم — سریع‌ترین مسیر است. برای پیشگیری از تکرار این مسئله، پیش از فعال‌سازی هر افزونهٔ جدید، تست سازگاری را اجرا کنید؛ روشش در بررسی سازگاری افزونه‌های وردپرس آمده است.

مسیر چهارم: رفع مشکل قالب

اگر با تغییر قالب به پیش‌فرض سایت برگشت، مسئله در قالب فعلی یا چایلد تم است. سه حالت را بررسی کنید:

• اگر چایلد تم دارید، آن را موقتاً غیرفعال کنید و قالب والد را فعال کنید. اگر سایت برگشت، مشکل در کد چایلد تم است — معمولاً در functions.php.
• اگر با قالب والد هم مشکل هست، نسخهٔ فعلی قالب را با نسخهٔ اصلی از مخزن مقایسه کنید. تفاوت‌ها را با diff ببینید.
• اگر قالب از منبع نامعتبر نصب شده، آن را کاملاً حذف کنید و از مخزن رسمی یا سازندهٔ معتبر نصب کنید. معیارهای تشخیص قالب استاندارد در تشخیص قالب استاندارد وردپرس آمده است.

مسیر پنجم: رفع مشکل ناسازگاری PHP

اگر WSOD بعد از ارتقای نسخهٔ PHP توسط هاست رخ داده، دو راه دارید: بازگردانی موقت نسخهٔ PHP به نسخهٔ قبلی از پنل هاست (اگر امکانش هست)، یا آپدیت افزونه‌ها و قالب به نسخه‌های سازگار با PHP جدید. راه دوم توصیه می‌شود، چون در بلندمدت امنیت و سرعت سایت بهتر می‌شود. برای فهمیدن کدام افزونه ناسازگار است، از WP_DEBUG و فایل debug.log استفاده کنید.

اشتباهات رایج در مواجهه با WSOD

سه اشتباه که در پرونده‌های واقعی زیاد دیده‌ام و هر کدام می‌تواند یک مشکل کوچک را به بحران تبدیل کند:

• ویرایش مستقیم فایل روی سایت زنده: ویرایش فایل قالب یا functions.php روی سایت زنده، بدون نسخهٔ آزمایشی و بدون بکاپ، شایع‌ترین دلیل WSOD است. حتی یک سمیکالن جاافتاده کافی است. عادت کنید تغییرات را در محیط لوکال یا استجینگ تست کنید و بعد روی سایت زنده اعمال کنید.
• رهاکردن WP_DEBUG روی true: برای دیدن خطا، WP_DEBUG را روشن می‌کنید؛ بعد از حل مشکل، فراموش می‌کنید خاموشش کنید. روی سایت زنده، این یعنی نمایش خطاها به کاربر و افشای مسیر فایل‌ها و جزئیات سرور. بعد از هر عیب‌یابی، این تنظیم را به false برگردانید.
• بازگردانی کورکورانه از بکاپ بدون تحلیل: اگر مقصر یک افزونهٔ ناسازگار با PHP است، بازگردانی از بکاپ مشکل را فقط به تأخیر می‌اندازد — چون بار بعدی که سایت آپدیت شود، دوباره سفید می‌شود. باید علت واقعی فهمیده شود، نه فقط اثر ظاهری پاک شود.

و یک اشتباه ظریف که در پروژه‌های تیمی زیاد دیده‌ام: هم‌زمان ویرایش چند فایل بدون یادداشت‌برداری. اگر بعد از پنج ویرایش همزمان سایت سفید شود، پیدا کردن مقصر سخت می‌شود. عادت سالم این است که در هر نوبت، یک تغییر اعمال شود، تست شود و بعد سراغ تغییر بعدی بروید.

نگاه مهندسی عمیق: چرا وردپرس نمی‌میرد، سکوت می‌کند؟

برای مهندسانی که می‌خواهند بدانند در لایهٔ زیرین چه می‌گذرد، پاسخ در ترتیب بارگذاری وردپرس نهفته است. هسته وردپرس از فایل index.php شروع می‌شود که wp-blog-header.php را فراخوانی می‌کند، و آن به‌نوبه خود wp-load.php و wp-settings.php را لود می‌کند. در حین این زنجیره، افزونه‌ها و قالب یکی‌یکی فراخوانی می‌شوند.

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

در سطح معماری، این رفتار دلیل وجود چند لایهٔ دفاعی است که در پروژه‌های حساس به کار می‌برم:

• Autoloader امن برای کد سفارشی: به‌جای افزودن کد مستقیم به functions.php، کد سفارشی را در فایل جداگانه در چایلد تم بگذارید و با بررسی وجود فایل (file_exists) آن را بار کنید. اگر فایل نبود، سایت خطا نمی‌دهد.
• Error Handler سراسری: با تابع set_error_handler می‌توان یک لایهٔ میانجی ساخت که خطاهای Fatal را در لاگ ثبت کند و به کاربر پیام دوستانه نشان دهد، نه صفحهٔ سفید. این کار در سایت‌های پرترافیک باعث می‌شود از دست دادن یک صفحه، به از دست دادن کل تجربه تبدیل نشود.
• سلامت‌سنجی خارجی (External Health Check): یک سرویس پایش خارجی که هر پنج دقیقه سایت را چک می‌کند، در صورت WSOD بی‌درنگ هشدار می‌دهد. این ابزار، زمان کشف مسئله را از ساعت‌ها به دقیقه‌ها کاهش می‌دهد.
• Feature Flag برای تغییرات پرخطر: در تیم‌های بزرگ، تغییرات پرخطر را پشت یک قابلیت قابل خاموش‌کردن قرار می‌دهند تا در صورت مشکل، در چند ثانیه خاموش شود. این الگو از دنیای Continuous Deployment آمده و در وردپرس هم با کمی خلاقیت قابل پیاده‌سازی است.

یک نکتهٔ ظریف‌تر: بعضی از WSOD ها، در واقع «نیمه-WSOD» هستند؛ یعنی صفحهٔ HTML بالا می‌آید ولی چیدمان کامل نیست، یا هدر و فوتر می‌آید ولی محتوا خالی است. این حالت‌ها از همان جنس Fatal هستند ولی در میانهٔ رندر رخ می‌دهند. در اینجا هم ابزار تشخیص، همان WP_DEBUG و لاگ است. تفاوت اصلی این است که این خطاها معمولاً توسط کد قالب یا افزونه‌ای که در حلقهٔ نمایش ذخیره شده به کار می‌رود، ایجاد می‌شوند. برای دیباگ عمیق‌تر کد سفارشی، مرجع دیباگ کردن کدهای سفارشی وردپرس راهنمای دقیقی دارد.

پیشگیری از صفحهٔ سفید آینده

سه عادت که در پروژه‌هایم همیشه اجرا می‌کنم:

1. محیط استجینگ اجباری: پیش از هر تغییر روی افزونه، قالب یا کد سفارشی، آن را در یک نسخهٔ موازی سایت (Staging) تست کنید. روش ساخت محیط لوکال یا استجینگ در توسعه وردپرس با محیط لوکال توضیح داده شده است.
2. بکاپ خودکار روزانه: ابزاری که هر شب یک نسخهٔ کامل از فایل‌ها و دیتابیس را در جای امن بیرون از هاست ذخیره کند. در پرونده‌های فاجعه‌بار، همین بکاپ‌ها نجات‌دهنده بوده‌اند. تحلیل کامل افزونه‌های بکاپ در بهترین افزونه‌های بکاپ وردپرس آمده است.
3. نسخه‌بندی با Git برای کد سفارشی: برای کدهای functions.php و چایلد تم، مخزن گیت نگه دارید. این کار امکان بازگشت دقیق به نسخهٔ سالم را در چند ثانیه فراهم می‌کند و دیگر نیازی به جست‌وجوی کورکورانه در انبوه تغییرات نیست. راهنمای کاربردی گیت در وردپرس در گیت در وردپرس آمده است.

و یک توصیهٔ تکمیلی که در پروژه‌های پرترافیک ارزش زیادی داشته: تنظیم یک سرویس پایش خارجی (مثل UptimeRobot یا Better Uptime) که سایت را از چند نقطهٔ جغرافیایی مختلف چک کند و در صورت WSOD یا خطای HTTP، از طریق ایمیل و SMS هشدار دهد. هزینه این سرویس‌ها در پلن رایگان، صفر است و ارزش آن در یک شب بحرانی، چندین برابر تمام سرویس‌های دیگر است.

اگر WSOD بعد از اضافه‌کردن یک فایل PHP ناشناخته به سایت ظاهر شده، حتماً امنیت را هم بررسی کنید. بعضی بدافزارها با کد معیوب، هم خودشان کار نمی‌کنند و هم سایت را می‌خوابانند. نشانه‌های آلودگی در علائم هک و بدافزار در وردپرس فهرست شده است. در صورت شک، مسیر پاک‌سازی در راهنمای پاک‌سازی سایت وردپرسی هک شده به ترتیب آمده است. اگر بعد از همهٔ این مراحل، WSOD با هیچ‌کدام از این شش علت تطبیق نکرد، ممکن است مشکل سطح سرور باشد — در این حالت مسئلهٔ هاست و منابع سرور جدی می‌شود. برای بازبینی آن لایه، تأثیر هاست بر سرعت سایت و کاهش مصرف منابع هاست دو مرجع مفیدند. راهنمای جامع خطاهای دیگر وردپرس هم در راهنمای جامع رفع خطاهای رایج وردپرس آماده است.

حرف آخر

صفحهٔ سفید مرگ در وردپرس، از آن خطاهایی است که در نگاه اول ترسناک به نظر می‌رسد، ولی پس از شناخت شش علت رایج و ابزارهای تشخیص، در بیش‌تر موارد در کمتر از نیم‌ساعت حل می‌شود. کلید اصلی، صبر در تشخیص است: به‌جای بازگردانی کورکورانه از بکاپ، لایهٔ شکسته را با WP_DEBUG پیدا کنید، مقصر را در همان لایه رفع کنید، و سپس ابزارهای پیشگیری را جدی بگیرید. اگر صفحهٔ سفید ای داشته‌اید که با هیچ‌کدام از این شش علت جا نمی‌گرفت — مثلاً فقط در یک مرورگر خاص یا یک اپراتور خاص رخ می‌داد — تجربه‌تان را در دیدگاه بنویسید؛ همان موارد نادر معمولاً نکات طلایی به همین راهنما اضافه می‌کنند. 🩺