صفحه کاملاً سفید در وردپرس معمولاً به این معناست که اجرای PHP متوقف شده ولی نمایش خطا خاموش است؛ با این حال پاسخ خالی cache، خروجی فشرده‌سازی خراب یا خطای upstream هم می‌تواند ظاهری مشابه بسازد. اگر فقط یک صفحه سفید است، کد یا داده همان مسیر را بررسی کنید. اگر سایت و wp-admin هر دو سفیدند، افزونه سراسری، قالب، bootstrap یا محدودیت PHP محتمل‌تر است.
پاسخ سریع: status و اندازه پاسخ را در Network ببینید، لاگ PHP را در همان timestamp پیدا کنید و فقط مؤلفه‌ای را که trace نشان می‌دهد آزمایش کنید. روشن کردن نمایش خطا برای بازدیدکنندگان، حذف تصادفی افزونه‌ها یا افزایش بی‌حد حافظه راه تشخیص نیست.
اول مطمئن شوید واقعاً «پاسخ سفید» دارید
DevTools مرورگر یا curl مشخص می‌کند پاسخ 200 با body خالی است، 500 دریافت می‌شود یا redirect به صفحه‌ای خالی رخ داده است. تب Network را با Disable cache باز کنید و status، content type، اندازه و redirectها را ببینید. اگر HTML کامل رسیده ولی صفحه چیزی نشان نمی‌دهد، خطای CSS یا JavaScript مطرح است؛ این سناریو با fatal PHP فرق دارد.
- یک URL ساده، صفحه ورود و یک فایل استاتیک را جدا آزمایش کنید.
- از شبکه یا مرورگر دیگری تست کنید تا cache محلی جدا شود.
- زمان شروع و آخرین deploy، آپدیت یا ویرایش کد را ثبت کنید.
- فضای دیسک و سلامت PHP-FPM را بررسی کنید.
لاگ، خطای پنهان را آشکار می‌کند
اول لاگ PHP-FPM یا پنل هاست را بخوانید. اگر دسترسی ندارید، ثبت موقت debug وردپرس را بدون نمایش عمومی فعال کنید:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );درخواست سفید را یک بار تکرار و انتهای wp-content/debug.log را بررسی کنید. اگر فایل ساخته نشد، permission مسیر، ثابت سفارشی WP_CONTENT_DIR و لاگ اصلی PHP را ببینید. پس از تشخیص debug را به تنظیم عادی برگردانید.
علت‌های محتمل به ترتیب عملی
خطای fatal در افزونه یا قالب
نام فایل و نخستین stack frame مرتبط را پیدا کنید. اگر مدیریت هم باز نمی‌شود، پوشه افزونه مظنون را موقتاً تغییر نام دهید. کنار گذاشتن کل پوشه plugins فقط برای محدود کردن دامنه است و باید با فعال‌سازی مرحله‌ای دنبال شود. برای قالب، ابتدا از وجود قالب پیش‌فرض سالم مطمئن شوید.
تمام شدن حافظه PHP
پیام Allowed memory size exhausted مقدار سقف و محل توقف را نشان می‌دهد. افزایش محدود و متناسب ممکن است دسترسی را برگرداند، اما loop، query بزرگ یا پردازش تصویر معیوب را درمان نمی‌کند. مصرف واقعی worker و تعداد درخواست هم‌زمان را نیز بسنجید.
فایل ناقص یا ناسازگاری نسخه
آپلود ناقص، deploy قطع‌شده یا تغییر PHP می‌تواند class/function لازم را حذف کند. checksum هسته را بررسی و نسخه‌های پشتیبانی‌شده افزونه و قالب را با PHP تطبیق دهید. فایل هسته را از منبع رسمی بازگردانید و محتوای سایت را overwrite نکنید.
خروجی زودهنگام یا پاسخ خراب
کد سفارشی ممکن است exit کند یا output buffering و compression در لایه‌های مختلف تداخل داشته باشند. اندازه پاسخ، headerها و لاگ upstream را مقایسه کنید. خاموش کردن تصادفی gzip در همه لایه‌ها بدون شاهد، تنها معماری را تغییر می‌دهد.
مسیر جداسازی کم‌ریسک
- backup فعلی و یک snapshot از لاگ بگیرید.
- یک درخواست قابل تکرار انتخاب کنید.
- عامل مشخص‌شده در trace را موقتاً کنار بگذارید.
- اگر trace ندارید، افزونه‌ها و سپس قالب را مرحله‌ای در staging آزمایش کنید.
- پس از بازگشت صفحه، مسیرهای login، فرم، cron و checkout را smoke test کنید.
- اصلاح پایدار یا نسخه سازگار را جایگزین workaround کنید.
اگر صفحه سفید فقط گاهی دیده می‌شود
خرابی متناوب معمولاً به یک worker، محدودیت منبع یا ورودی خاص وابسته است. زمان درخواست ناموفق را با لاگ PHP-FPM و شناسه request تطبیق دهید و ببینید آیا همه خطاها روی یک endpoint، کاربر یا فرایند رخ می‌دهند. بررسی تعداد workerهای مشغول، timeout و وضعیت دیتابیس از افزایش تصادفی منابع مفیدتر است. اگر load balancer چند backend دارد، پاسخ هر node را جدا بسنجید؛ سالم بودن یک node خرابی node دیگر را پنهان می‌کند.
اگر صفحه سفید بعد از ارتقای هسته شروع شد، بازیابی وردپرس پس از آپدیت هسته تفاوت فایل و دیتابیس را توضیح می‌دهد. پاسخ 500 نیز در راهنمای خطای 500 وردپرس از دید وب‌سرور بررسی شده است.
کارهایی که نباید انجام دهید
- فعال کردن
display_errorsبرای کاربران production. - حذف افزونه یا قالب بدون نگه داشتن نسخه و تنظیمات.
- استفاده از
chmod 777برای پنهان کردن خطای مالکیت. - restore دیتابیس فروشگاه بدون محافظت از سفارش‌های تازه.
- نصب چند افزونه تعمیر و cache روی سایت ازکارافتاده.
پیشگیری از تکرار
تغییرات را ابتدا در staging هم‌نسخه آزمایش کنید، deployment قابل rollback داشته باشید و fatalهای PHP را مانیتور کنید. backup باید شامل فایل و دیتابیس باشد و restore آن واقعاً آزمایش شود. نگه داشتن نسخه‌ها و timestamp تغییرات، زمان تشخیص را بسیار کوتاه‌تر می‌کند.
چه زمانی کمک تخصصی لازم است؟
اگر پاسخ گاهی سفید است، فقط زیر بار رخ می‌دهد یا trace میان PHP-FPM، دیتابیس و کد سفارشی پخش شده، یک snapshot لحظه خطا لازم است. سرویس رفع مشکل فنی وردپرس برای بررسی هم‌زمان لاگ برنامه و سرور قابل استفاده است. پیام رسمی خطای بحرانی را نیز می‌توانید با راهنمای Critical Error دنبال کنید.
پرسش‌های متداول
چرا صفحه سفید فقط برای مدیر دیده می‌شود؟
صفحات مدیریت hookها، queryها و assetهای متفاوت دارند. افزونه امنیتی، داشبورد یا خطای ذخیره تنظیمات را در درخواست همان کاربر بررسی کنید.
چرا با refresh صفحه برمی‌گردد؟
worker معیوب، cache ناهماهنگ یا خطای وابسته به بار محتمل است. درخواست موفق و ناموفق را با PID، زمان و upstream مقایسه کنید.
آیا افزایش PHP memory همیشه مشکل را حل می‌کند؟
خیر. فقط وقتی workload معتبر از سقف کوچک‌تر عبور نمی‌کند مفید است؛ رشد بی‌قاعده مصرف نیازمند پیدا کردن علت است.
صفحه سفید با status 200 چه معنایی دارد؟
ممکن است خروجی پیش از render قطع یا پاسخ خالی cache شده باشد. body، header و لاگ PHP همان درخواست تعیین‌کننده‌اند.