چرا صفحه سفید مرگ در وردپرس ظاهر می‌شود؟
رفع خطای White Screen of Death در وردپرس چطور انجام می‌شود؟ راهنمای فنی ریشه‌یابی WSOD با WP_DEBUG، غیرفعال‌سازی افزونه از طریق FTP و بازیابی سریع سایت بدون از دست دادن داده.
پرونده‌ای که این مقاله را به من الهام داد، سایتی فروشگاهی بود که صاحبش با صدای لرزان تماس گرفت و گفت همه‌چیز سفید شده است. کد تخفیفی که دو ساعت قبل در functions.php اضافه کرده بود، یک پرانتز جا افتاده داشت و کل پیشخوان و فرانت‌اند را سفید کرده بود. مشکل نه در هک بود و نه در سرور؛ یک خطای ترکیبی در یکی از فایل‌های قالب. آن روز به من یادآوری شد که صفحه سفید مرگ (White Screen of Death) یا به اختصار WSOD، بیشتر از آنکه خطا باشد، یک وضعیت اضطراری است که در آن سایت هیچ اطلاعاتی نمی‌دهد و شما باید با ابزارهای بیرونی، به داخل نفوذ کنید.
صفحه سفید مرگ در وردپرس دقیقاً چیست؟
صفحه سفید مرگ یا White Screen of Death در وردپرس، وضعیتی است که در آن صفحه به‌طور کامل سفید رندر می‌شود و هیچ پیام خطایی نمایش داده نمی‌شود. از منظر کاربر، سایت ناپدید شده؛ از منظر سرور، درخواست دریافت شده و یک پاسخ خالی برگردانده شده است. خودم در پرونده‌های متعدد دیده‌ام که این حالت، دو تفاوت مهم با خطاهای ۵۰۰ یا ۵۰۳ دارد: نخست اینکه اغلب یک صفحه‌ی خالی با کد وضعیت ۲۰۰ برمی‌گردد که تشخیص را از دید ابزارهای مانیتورینگ عمومی سخت‌تر می‌کند، و دوم اینکه پیشخوان و فرانت‌اند ممکن است مستقل از هم سفید شوند که این خودش یکی از کلیدهای ریشه‌یابی است.
به‌طور فنی، صفحه سفید نتیجه‌ی یک خطای مرگبار (Fatal Error) در PHP است که پیش از ارسال هر خروجی رخ می‌دهد. در نسخه‌های قدیمی‌تر PHP، خطای مرگبار با یک پیام هشدار همراه بود؛ اما در نسخه‌های مدرن، به‌دلیل تنظیمات پیش‌فرض حساس به امنیت، پیام سرکوب می‌شود و مرورگر فقط پاسخ خالی می‌گیرد. این خطا می‌تواند در افزونه، قالب، فایل wp-config.php، هسته‌ی وردپرس یا حتی در لایه‌ی وب‌سرور رخ دهد و به همین دلیل، ریشه‌یابی درست نیاز به یک روش نظام‌مند دارد.
صفحه سفید مرگ، خطا نیست؛ وضعیت اضطراری است. مشکل واقعی، آن خطای مرگباری است که پشت پرده رخ داده و وردپرس یاد نگرفته چگونه آن را به شما بگوید.
ریشه‌های اصلی WSOD در وردپرس
در بیش از ده سال کار روی سایت‌های وردپرسی، صفحه سفید را همیشه از یکی از پنج ریشه‌ی مشخص دیده‌ام. شناخت این پنج ریشه، به شما امکان می‌دهد در دقایق اول، جستجوی خود را از خطای تصادفی به یک مسیر نظام‌مند تبدیل کنید.
ریشه اول: ناسازگاری یا خطای افزونه
شایع‌ترین دلیل صفحه سفید، افزونه‌ای است که یا با نسخه‌ی فعلی PHP ناسازگار است، یا با افزونه‌ی دیگری تداخل دارد، یا خودش بعد از یک آپدیت ناقص، خطای مرگبار می‌دهد. تجربه‌ی من می‌گوید بیش از نیمی از پرونده‌های صفحه سفید، مستقیماً به افزونه‌ای مربوط می‌شود که در ۴۸ ساعت گذشته به‌روز شده یا تازه نصب شده. اگر به‌تازگی این تجربه را داشته‌اید، راهنمای پیدا کردن و رفع خطای افزونه وردپرس دقیقاً مسیری است که در ادامه‌ی این مقاله می‌پیماییم.
ریشه دوم: خطای قالب یا چایلد تم
قالبی که با نسخه‌ی جدید وردپرس سازگار نیست، یا چایلد تمی که در functions.php خطای نحوی دارد، می‌تواند کل سایت را از دسترس خارج کند. اگر صفحه سفید بلافاصله پس از تغییر قالب، ویرایش فایل قالب یا آپدیت قالب رخ داده، اولویت اول شما بررسی همین لایه است.
ریشه سوم: خطای فایل wp-config.php
این فایل، حساس‌ترین فایل وردپرس است؛ چون حاوی اطلاعات اتصال به دیتابیس و کلیدهای امنیتی است. یک نقل‌قول اضافه، یک ; جاافتاده یا حتی یک فاصله اضافی در انتهای فایل، می‌تواند باعث صفحه سفید شود. اگر بلافاصله پس از ویرایش این فایل، سایت سفید شده، همین‌جا بایستید.
ریشه چهارم: مصرف بیش از حد حافظه
وقتی اسکریپتی بیشتر از حد مجاز memory_limit از هاست درخواست حافظه کند، PHP با خطای memory exhausted متوقف می‌شود و نتیجه، صفحه سفید است. در پروژه‌هایی که افزونه‌های سنگین (مثل صفحه‌سازها یا افزونه‌های ترجمه) روی سایت نصب است، این ریشه بسیار شایع است. اگر با سقف حافظه درگیر هستید، راهنمای رفع خطای حافظه در وردپرس مسیر دقیق افزایش و مدیریت این محدودیت را نشان می‌دهد.
ریشه پنجم: خرابی هسته یا فایل‌های وردپرس
در موارد کمتر شایع اما جدی، یکی از فایل‌های هسته‌ی وردپرس در جریان آپدیت ناقص خراب شده و همان باعث خطای مرگبار می‌شود. این حالت معمولاً پس از یک به‌روزرسانی نیمه‌کاره یا قطع اینترنت در حین آپدیت رخ می‌دهد.
راهبرد برخورد: تشخیص سریع قبل از هر اقدام
قبل از هر اقدامی، سه سؤال را از خودتان بپرسید. این سه سؤال، مسیر تشخیص را تا حد زیادی مشخص می‌کنند.
سؤال اول: صفحه سفید کجا رخ می‌دهد؟
اگر فقط پیشخوان سفید است و فرانت‌اند سالم است، دامنه‌ی مشکل به افزونه‌های مدیریتی یا ناسازگاری هسته محدود می‌شود. اگر فرانت سفید و پیشخوان سالم است، مشکل در قالب یا یکی از افزونه‌های نمایشی است. اگر هر دو سفید است، معمولاً مشکل در لایه‌های پایه مثل wp-config یا هسته است.
سؤال دوم: آخرین تغییری که روی سایت انجام شده چه بوده؟
یک دفترچه‌ی تغییرات حتی ذهنی داشته باشید: آخرین آپدیت، آخرین افزونه‌ی نصب‌شده، آخرین ویرایش فایل. در پرونده‌های متعدد، همین یک سؤال، ریشه‌یابی را از چند ساعت به چند دقیقه کاهش داده است. اگر مطمئن نیستید چه چیزی اخیراً تغییر کرده، از لاگ هاست یا لاگ افزونه‌ی امنیتی کمک بگیرید.
سؤال سوم: خطای مرگبار در لاگ سرور دیده می‌شود؟
در پنل هاست، بخشی به نام Error Log وجود دارد که خطاهای مرگبار PHP را ثبت می‌کند. اگر خطایی با مهر زمانی مطابق آخرین بازدید سایت در آن هست، مسیر دقیقاً همان است. برای اطلاعات بیشتر درباره‌ی نحوه‌ی خواندن این لاگ‌ها، راهنمای بررسی خطاهای سرور در لاگ‌ها را توصیه می‌کنم.
فعال‌سازی حالت دیباگ برای دیدن خطای واقعی
ابزار اصلی ریشه‌یابی صفحه سفید، فعال کردن WP_DEBUG در فایل wp-config.php است. این تنظیم، به وردپرس می‌گوید که خطاهای PHP و وردپرس را نمایش بدهد و در صفحه، پیام دقیقی از خطای مرگبار چاپ کند.
ابتدا از فایل 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-content/debug.log ثبت می‌شوند، بدون اینکه به کاربر نمایش داده شوند. این روش امن‌ترین حالت برای سایت‌های زنده است. اگر می‌خواهید خطاها را مستقیماً روی صفحه ببینید (فقط در محیط staging)، مقدار WP_DEBUG_DISPLAY را true کنید. جزئیات کامل این تنظیمات و خطاهای مرتبط با آنها در رفع خطای Parse error در فایل functions.php با مثال‌های واقعی آمده است.
در تشخیص صفحه سفید، WP_DEBUG چراغ‌قوه‌ای است که شما در انبار خاموش روشن می‌کنید. بدون آن، هر اقدامی حدس است؛ با آن، هر اقدامی تصمیم است.
غیرفعال‌سازی افزونه از طریق FTP و File Manager
وقتی پیشخوان هم سفید است، نمی‌توانید از داشبورد افزونه‌ها را غیرفعال کنید. تنها راه عملی، دسترسی مستقیم به فایل‌ها از طریق FTP یا File Manager هاست است. این پروتکل، ستون فقرات بازیابی در تمام پرونده‌های صفحه سفیدی است که با آن روبه‌رو شده‌ام.
گام اول: اتصال به هاست
با اطلاعات FTP یا SFTP که از هاست‌تان دارید، به سرور متصل شوید و به پوشه‌ی wp-content/plugins/ بروید. اگر مطمئن نیستید چطور باید اتصال FTP برقرار کنید، جزئیات فنی این کار در راهنمای رفع خطای دسترسی به فایل‌ها آمده است، چون در بعضی موارد خطای دسترسی فایل هم خودش را به شکل صفحه سفید نشان می‌دهد.
گام دوم: غیرفعال‌سازی دسته‌ای افزونه‌ها
پوشه‌ی plugins را باز کنید و تمام پوشه‌های افزونه‌ها را به یک نام موقت تغییر دهید؛ مثلاً از akismet به akismet.disabled. سریع‌ترین راه، انتخاب همه و تغییر دسته‌ای نام است. سپس سایت را در مرورگر باز کنید. اگر سایت برگشت، مشکل در یکی از همین افزونه‌هاست.
گام سوم: فعال‌سازی تدریجی برای پیدا کردن مقصر
اکنون پوشه‌ها را یکی‌یکی به نام اصلی برگردانید و پس از هر بازگشت، سایت را باز کنید. لحظه‌ای که صفحه سفید برگشت، افزونه‌ی مقصر شناسایی شده است. این همان رویکردی است که در آموزش نصب افزونه برای مبتدیان به‌عنوان پروتکل تشخیصی معرفی کرده‌ام.
گام چهارم: تصمیم‌گیری درباره افزونه‌ی مقصر
وقتی افزونه‌ی مقصر مشخص شد، سه گزینه دارید: نصب نسخه‌ی قدیمی‌تر از سازنده (rollback)، جستجوی افزونه‌ی جایگزین، یا انتظار برای آپدیت سازنده. تصمیم به‌موقع در همین گام، مانع از آن می‌شود که در بازه‌ی انتظار، سایت شما همچنان از دسترس خارج باشد.
ریشه‌یابی مشکل در قالب و چایلد تم
اگر با غیرفعال‌سازی افزونه‌ها سایت برنگشت، مشکل در قالب یا چایلد تم است. ساده‌ترین راه برای تأیید این فرض، آن است که قالب فعال را از طریق تغییر نام پوشه‌اش در wp-content/themes/ موقتاً غیرفعال کنید. وردپرس به‌طور خودکار به قالب پیش‌فرض برمی‌گردد و اگر سایت با آن بالا آمد، مقصر قالب فعلی است.
در این حالت، دو سناریو داریم. اگر مشکل در چایلد تم باشد، کافی است فایل functions.php آن را با یک نسخه‌ی خالی موقتاً جایگزین کنید تا سایت بالا بیاید و سپس خطای واقعی را از debug.log استخراج کنید. اگر مشکل در قالب والد باشد، باید با سازنده تماس بگیرید یا از نسخه‌ی قدیمی‌تر استفاده کنید. تجربه‌ی مشابهی را در رفع صفحه سفید بعد از تغییر قالب به‌تفصیل شرح داده‌ام؛ همان مراحل، با اندکی تنظیم، برای ریشه‌یابی هر نوع خطای قالب کاربرد دارد.
تفسیر خطاهای مرگبار PHP
وقتی debug.log را باز می‌کنید، ممکن است با انواع مختلفی از خطاها روبه‌رو شوید. سه خطای مرگباری که بیشترین سهم را در صفحه سفید دارند، این‌ها هستند:
خطای Fatal error: Call to undefined function
این خطا معمولاً زمانی رخ می‌دهد که یک افزونه یا قالب، تابعی را فراخوانی می‌کند که یا وجود ندارد، یا در ترتیب بارگذاری هنوز تعریف نشده. ریشه‌ی این خطا اغلب یکی از این دو است: نصب‌نشدن افزونه‌ی پیش‌نیاز، یا آپدیت هسته وردپرس که تابعی را حذف یا تغییر داده. راهنمای رفع خطای Fatal error بعد از فعال‌سازی افزونه دقیقاً همین سناریو را باز کرده است.
خطای Parse error: syntax error, unexpected
این خطا مربوط به یک نقص نحوی در کد PHP است؛ مثلاً پرانتز یا آکولاد جاافتاده، کاما یا نقطه‌ویرگول اشتباه. Parse error معمولاً مستقیماً نام فایل و شماره خط را می‌دهد و به همین دلیل، سریع‌ترین نوع خطا برای رفع است. پروتکل استاندارد رفع این خطا در همان راهنمای functions.php آمده که قبلاً به آن اشاره کردم.
خطای Fatal error: Allowed memory size exhausted
وقتی این خطا را می‌بینید، یعنی اسکریپت PHP بیش از حد مجاز حافظه خورده است. راه‌حل‌ها عبارتند از افزایش memory_limit از طریق wp-config.php، حذف افزونه‌های سنگین، و در بعضی موارد ارتقای پلن هاست. مسیر کامل این رفع خطا و همچنین ملاحظات مربوط به هاست را در راهنمای رفع خطای Memory Limit در وردپرس گردآوری کرده‌ام.
بازگشت به .htaccess پیش‌فرض
در بعضی موارد، خطای صفحه سفید نه از PHP بلکه از فایل .htaccess می‌آید. یک قاعده‌ی نادرست redirect، یک پیکربندی خراب mod_rewrite، یا اضافه شدن قوانین نامعتبر از یک افزونه‌ی امنیتی، می‌تواند کل سایت را از دسترس خارج کند و به‌صورت یک صفحه‌ی خالی نمایش دهد. راه‌حل، ساده است: از فایل .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 بوده است. این الگو را در پرونده‌های مربوط به رفع خطای ریدایرکت بی‌نهایت در وردپرس نیز دیده‌ام؛ همان منطق ریشه‌یابی، اما با نشانه‌های متفاوت.
خطای حد حافظه و راه‌حل‌های عملی
خطای حد حافظه، خودش را به دو شکل متفاوت نشان می‌دهد: یا صفحه سفید کامل، یا خطای پیام‌دار در بازه‌ی محدودی از صفحات. تشخیص این دو سناریو از هم، در انتخاب راه‌حل بسیار مهم است. در سناریوی اول، PHP قبل از هر خروجی متوقف شده؛ در سناریوی دوم، خروجی تا نقطه‌ای پیش رفته و بعد متوقف شده است.
سه راه عملی برای افزایش حد حافظه وجود دارد. نخست، ویرایش wp-config.php با خط زیر، پیش از خط That's all, stop editing:
define( 'WP_MEMORY_LIMIT', '256M' );دوم، ویرایش فایل .htaccess با خط php_value memory_limit 256M که فقط در هاست‌هایی که از PHP با handler CGI استفاده می‌کنند کار می‌کند. سوم، درخواست از پشتیبانی هاست برای ارتقای مقدار memory_limit در سطح سرور. من در پروژه‌های واقعی، ترکیب این سه راه را استفاده می‌کنم؛ چون هرکدام بسته به معماری هاست، ممکن است تنها یا بی‌اثر باشد.
مسیرهای بازیابی سریع برای کاربران بدون بکاپ
در بدترین سناریو، صفحه سفید رخ می‌دهد و بکاپ قابل‌بازگردانی هم در دسترس نیست. با اینکه توصیه‌ی همیشگی من داشتن بکاپ است، در پروژه‌های متعدد با این حالت روبه‌رو شده‌ام و پروتکل بازیابی مشخصی دارم.
گام اول: تعیین محدوده‌ی خرابی
از طریق FTP، فهرست کامل فایل‌ها را مرور کنید و ببینید آیا فایلی با تاریخ دیرتر از بقیه وجود دارد که ممکن است به‌تازگی تغییر کرده باشد. اگر فایل مشکوکی دیدید، آن را موقتاً با نسخه‌ی اصلی از مخزن رسمی وردپرس جایگزین کنید. خود وردپرس، به‌طور پیش‌فرض امکان دانلود نسخه‌ی کامل هسته را از مخزن رسمی دارد.
گام دوم: بازنصب هسته از طریق پیشخوان
اگر پیشخوان در دسترس نیست، می‌توانید فایل‌های هسته‌ی وردپرس را از مسیر رسمی دانلود کنید و به‌جای فایل‌های فعلی روی سرور بگذارید. این کار روی فایل‌های wp-config.php و پوشه‌ی wp-content اثر نمی‌گذارد، پس داده‌های شما امن می‌ماند. مسیر گام‌به‌گام این بازیابی در راهنمای پاکسازی سایت هک‌شده وردپرسی هم به‌کار رفته است؛ همان منطق جایگزینی هسته، در پرونده‌ی صفحه سفید هم کاربرد دارد.
گام سوم: بازیابی دیتابیس
اگر بکاپ دیتابیس قدیمی در دسترس دارید، می‌توانید جداول را از طریق phpMyAdmin بازگردانید. اگر بکاپ نیست، ولی سایت فقط با صفحه سفید روبه‌روست و دیتابیس سالم است، باید تمام تغییرات را روی لایه‌ی فایل متمرکز کنید، نه دیتابیس. این تفکیک، در بسیاری از پرونده‌ها از بازسازی کامل سایت جلوگیری کرده است.
پرسش‌های پرتکرار درباره صفحه سفید مرگ وردپرس
در این بخش، پرتکرارترین پرسش‌هایی که در مکاتبات و پشتیبانی با آنها روبه‌رو می‌شوم را جمع کرده‌ام؛ ساختاری که هم به مخاطب کمک می‌کند و هم با بهینه‌سازی برای موتورهای پاسخ‌ده (AEO)، دسترسی سریع‌تری به پاسخ فراهم می‌کند.
آیا صفحه سفید همیشه به‌معنی هک شدن سایت است؟
خیر. بیش از ۹۰ درصد پرونده‌های صفحه سفیدی که با آن روبه‌رو شده‌ام، ریشه در خطای کد و ناسازگاری افزونه داشته‌اند، نه هک. با این حال، در پرونده‌هایی که هم‌زمان با صفحه سفید، رفتارهای مشکوک دیگری مثل ریدایرکت خودکار یا تغییرات ناشناخته در فایل‌ها دیده می‌شود، احتمال آلودگی جدی است. اگر علائم هک مشاهده کردید، اول علائم هک سایت وردپرسی را بررسی کنید.
چرا فقط پیشخوان سفید است ولی فرانت‌اند کار می‌کند؟
این الگو معمولاً به دو دلیل رخ می‌دهد: یا افزونه‌ای در مسیر پیشخوان خطای مرگبار می‌دهد، یا هسته‌ی وردپرس در بخش مدیریتی ناسازگاری دارد. در این حالت، معمولاً خطا فقط در پوشه‌ی wp-admin یا فایل wp-admin/includes/ رخ می‌دهد و نیازی به بررسی لایه‌ی قالب نیست.
آیا می‌توان بدون غیرفعال کردن همه افزونه‌ها، مقصر را پیدا کرد؟
بله، اگر پیشخوان باز است، می‌توانید افزونه‌ها را یکی‌یکی غیرفعال کنید. اما اگر پیشخوان سفید است، سریع‌ترین راه، غیرفعال‌سازی دسته‌ای از طریق FTP و سپس فعال‌سازی تدریجی است؛ چون هر بار بازگشت به پیشخوان، ممکن است چند دقیقه طول بکشد.
بعد از رفع خطا، چه چیزی را باید فوراً چک کنم؟
سه چیز: نخست، تست ارسال و دریافت ایمیل سایت (اگر با فرم تماس یا ووکامرس ارتباط دارد)، دوم، تست صفحه‌ی محصول یا برگه‌های مهم برای اطمینان از سالم بودن داده، و سوم، چک کردن Search Console برای یافتن خطاهای احتمالی جدید. اگر سایت شما ووکامرسی است، رفع خطاهای رایج ووکامرس را هم به‌عنوان چک‌لیست تکمیلی مرور کنید.
چگونه از تکرار صفحه سفید در آینده پیشگیری کنیم؟
سه اقدام کافی است. اول، یک محیط staging برای تست تغییرات قبل از اعمال روی سایت زنده. دوم، فعال کردن بکاپ روزانه‌ی خودکار روی سرور مستقل از سایت. سوم، محدود کردن آپدیت خودکار افزونه‌ها و قالب‌ها به موارد ضروری. تجربه‌ی من نشان می‌دهد که این سه، بیش از ۹۰ درصد ریسک را کاهش می‌دهند.
پایان کار: چه چیزی را در پیشگیری نباید از دست بدهید
صفحه سفید مرگ، ترسناک است اما در بیشتر موارد، با یک رویکرد نظام‌مند در بازه‌ی نیم ساعت تا دو ساعت رفع می‌شود. چیزی که مسئله را جدی می‌کند، نبود بکاپ و نبود محیط staging است. اگر این دو را داشته باشید، هر بحرانی از این جنس، یک تمرین فنی است؛ اگر نداشته باشید، هر بحران، یک فاجعه‌ی چندروزه. توصیه‌ی من این است که همین امروز، بکاپ خودکار و یک محیط staging راه‌اندازی کنید؛ حتی اگر سایت شما کوچک است.
اگر در جریان رفع صفحه سفید به مورد خاصی برخوردید — مثلاً خطای مرگباری که با هیچ‌کدام از این روش‌ها برطرف نشد، یا سایت شما روی هاست خاصی رفتار متفاوتی داشت — تجربه‌تان را در دیدگاه‌ها بنویسید. بیش از آنکه توصیه‌های کلی کمک کنند، همین پرونده‌های واقعی هستند که مسیر رفع را برای خواننده‌ی بعدی کوتاه‌تر می‌کنند. 🔧
نویسنده در وردپرس کار.