رفع Critical Error وردپرس؛ مسیر امن از تشخیص تا بازیابی سایت

پیام «There has been a critical error on this website» یعنی اجرای PHP پیش از تکمیل درخواست متوقف شده است. اگر پیام درست بعد از نصب افزونه، تغییر قالب یا به‌روزرسانی ظاهر شده، همان تغییر مظنون اصلی است؛ اما کمبود حافظه، ناسازگاری نسخه PHP و خرابی فایل نیز نتیجه‌ای مشابه می‌سازند. راه امن این است که ابتدا خطای واقعی را از لاگ پیدا کنید و بعد فقط همان مؤلفه را غیرفعال یا اصلاح کنید.

پاسخ سریع: از فایل‌ها و دیتابیس نسخه پشتیبان بگیرید، ایمیل Recovery Mode مدیر را بررسی کنید، لاگ PHP و wp-content/debug.log را بخوانید و افزونه یا قالبی را که نامش در stack trace آمده موقتاً از مدار خارج کنید. بازگردانی کور همه فایل‌ها یا افزایش بی‌حد حافظه، تشخیص را دشوارتر می‌کند.

ابتدا دامنه خرابی را مشخص کنید

صفحه اصلی، یک نوشته، فروشگاه، REST API و wp-admin را جداگانه آزمایش کنید. اگر فقط یک URL خراب است، احتمال خطای داده یا کد همان مسیر بیشتر است. اگر همه صفحات حتی ورود مدیریت از کار افتاده‌اند، خطای bootstrap وردپرس، افزونه سراسری یا قالب محتمل‌تر است. پاسخ HTTP را نیز ببینید؛ پیام ظاهری ممکن است با وضعیت 500، 503 یا حتی 200 تحویل شود.

• زمان دقیق شروع خطا و آخرین تغییر را ثبت کنید.
• فضای دیسک و دسترسی به پنل هاست یا SSH را بررسی کنید.
• در فروشگاه، پیش از rollback وضعیت سفارش‌های تازه را نگه دارید.
• یک snapshot از وضعیت خراب نیز برای تحلیل بعدی ارزش دارد.

خطای واقعی را از کجا پیدا کنیم؟

Recovery Mode و ایمیل مدیر

وردپرس در بعضی fatal errorها ایمیلی با لینک حالت بازیابی می‌فرستد. پوشه Spam و صحت ایمیل مدیر را بررسی کنید. ورود از این لینک اجازه می‌دهد مؤلفه متوقف‌شده را بدون دستکاری فایل‌ها غیرفعال کنید. نبودن ایمیل به معنی نبودن خطا نیست؛ ارسال ایمیل خود سایت ممکن است مشکل داشته باشد یا خطا پیش از آن مرحله رخ داده باشد.

لاگ PHP و debug.log

لاگ PHP-FPM، Apache یا پنل میزبانی معمولاً معتبرترین منبع است. برای ثبت موقت خطا در وردپرس، پس از backup این مقادیر را پیش از خط «stop editing» در wp-config.php قرار دهید:

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

حالا درخواست خراب را یک بار تکرار و انتهای wp-content/debug.log را بررسی کنید. نام فایل، شماره خط، نوع exception و نخستین بخش مرتبط stack trace مهم‌اند. نمایش خطا روی production را فعال نکنید؛ مسیر فایل و اطلاعات داخلی ممکن است آشکار شود. پس از تشخیص نیز debug را به وضعیت عادی برگردانید.

بازیابی مرحله‌ای با کمترین ریسک

1. افزونه مظنون: اگر مدیریت باز نمی‌شود، پوشه همان افزونه را در wp-content/plugins تغییر نام دهید. تغییر نام کل پوشه plugins فقط یک آزمون کوتاه است؛ بعد افزونه‌ها را یکی‌یکی فعال کنید.
2. قالب: اگر trace به قالب اشاره دارد، از وجود یک قالب پیش‌فرض سالم مطمئن شوید و قالب فعال را موقتاً کنار بگذارید. حذف قالب بدون جایگزین راه امنی نیست.
3. نسخه PHP: نسخه‌های پشتیبانی‌شده توسط وردپرس، قالب و افزونه را مقایسه کنید. تغییر PHP را ابتدا در staging انجام دهید و extensionهای مورد نیاز پروژه را بررسی کنید.
4. حافظه: پیام Allowed memory size exhausted را با اندازه‌گیری مصرف دنبال کنید. افزایش سقف فقط وقتی درست است که workload معتبر باشد؛ memory leak یا query معیوب را پنهان نکنید.
5. هسته: checksum فایل‌های هسته را بررسی کنید. فایل‌های wp-content و wp-config.php را با بسته هسته جایگزین نکنید.

wp core verify-checksums
wp plugin list --status=active
wp theme list

WP-CLI باید از ریشه صحیح سایت و با کاربر مناسب اجرا شود. خروجی checksum هسته درباره افزونه و upload قضاوت نمی‌کند؛ نتیجه را دقیق تفسیر کنید.

اگر سایت برگشت، کار تمام نشده است

بازگشت صفحه پس از غیرفعال کردن افزونه فقط رابطه علت را محتمل می‌کند. نسخه‌ها، changelog، نیازمندی PHP و خطای دقیق را در staging بازتولید کنید. سپس نسخه سازگار یا patch معتبر را نصب و مسیرهای مهم مانند login، فرم، جست‌وجو، checkout و cron را متناسب با نقش مؤلفه smoke test کنید.

چگونه از تکرار Critical Error جلوگیری کنیم؟

پیشگیری به معنی متوقف کردن همه به‌روزرسانی‌ها نیست. هسته، قالب و افزونه‌ها باید به‌روز بمانند، اما انتشار تغییر باید قابل مشاهده و قابل بازگشت باشد. نسخه PHP و extensionها را در فهرست دارایی‌های سایت ثبت کنید، staging را تا حد امکان مشابه production نگه دارید و پیش از هر تغییر ناسازگاری‌های اعلام‌شده سازنده را بخوانید.

• backup زمان‌بندی‌شده بدون آزمون restore کافی نیست؛ دوره‌ای یک بازیابی آزمایشی انجام دهید.
• تغییرات را در یک بازه مشخص انجام دهید تا ارتباط خطا با release قابل تشخیص باشد.
• خطای PHP، status code و فضای دیسک را مانیتور کنید؛ فقط uptime صفحه اصلی کافی نیست.
• افزونه‌های بدون نگهداری یا هم‌پوشان را پس از ارزیابی حذف کنید، نه اینکه صرفاً غیرفعال و فراموش شوند.

کارهایی که معمولاً اوضاع را بدتر می‌کنند

• نصب چند افزونه «رفع خطا» روی سایتی که علت آن معلوم نیست.
• دادن دسترسی 777؛ این کار مشکل مالکیت را حل نمی‌کند و ریسک امنیتی می‌سازد.
• بازگردانی کامل دیتابیس فروشگاه و از دست دادن سفارش‌های پس از backup.
• ویرایش فایل vendor که در آپدیت بعدی از بین می‌رود.
• خاموش کردن WAF یا ابزار امنیتی بدون شاهد.

چه زمانی بررسی تخصصی لازم است؟

اگر خرابی بعد از ارتقا شروع شده، راهنمای بازیابی وردپرس پس از آپدیت افزونه را نیز ببینید. اگر پاسخ سرور 500 است، مسیر تشخیص خطای 500 وردپرس جزئیات لایه وب‌سرور را توضیح می‌دهد.

اگر خطا مرتب بازمی‌گردد، به PHP-FPM یا MySQL می‌رسد، یا سایت سفارش زنده دارد، آزمون بیشتر روی production پرریسک است. در این وضعیت بررسی هماهنگ لاگ وردپرس، وب‌سرور، PHP و دیتابیس می‌تواند ریشه خطا را پیش از تغییرات گسترده مشخص کند. جزئیات سرویس رفع مشکل فنی وردپرس برای همین نوع عیب‌یابی در دسترس است.

پرسش‌های متداول

آیا Critical Error یعنی سایت هک شده است؟

خیر. این پیام نتیجه یک خطای fatal در PHP است و به‌تنهایی علت را نشان نمی‌دهد. رخداد امنیتی باید با لاگ و بررسی یکپارچگی اثبات شود.

آیا WP_DEBUG را روشن نگه داریم؟

ثبت موقت در لاگ مفید است، اما نمایش خطا روی سایت عمومی مناسب نیست. پس از رفع مشکل تنظیمات debug را برگردانید.

اگر debug.log ساخته نشد چه کنیم؟

مجوز نوشتن، مسیر content و لاگ اصلی PHP را بررسی کنید. بعضی خطاها پیش از logger وردپرس رخ می‌دهند.

آیا restore کامل سریع‌ترین راه است؟

برای سایت محتوایی ساده شاید، اما در فروشگاه می‌تواند داده تازه را حذف کند. دامنه restore باید با RPO و نوع داده هماهنگ باشد.