اگر سایت بلافاصله بعد از به‌روزرسانی هسته وردپرس خطای بحرانی، صفحه سفید یا پاسخ 500 نشان می‌دهد، لزوماً خود هسته معیوب نیست. آپدیت ناقص، ناسازگاری افزونه یا قالب، نسخه نامناسب PHP، کمبود فضای دیسک و migration ناتمام دیتابیس می‌توانند هم‌زمان با ارتقا آشکار شوند. اول وضعیت فعلی و داده‌های تازه را حفظ کنید؛ سپس لایه‌ای را که واقعاً خطا می‌دهد جدا کنید.
پاسخ سریع: از فایل‌ها و دیتابیس backup بگیرید، زمان دقیق خرابی را با لاگ PHP تطبیق دهید، کامل بودن فایل‌های هسته و وجود .maintenance را بررسی کنید و افزونه‌ها را فقط برای آزمون کنترل‌شده کنار بگذارید. restore کامل دیتابیس فروشگاه یا نصب نسخه قدیمی هسته بدون بررسی سازگاری، ممکن است سفارش‌ها و تغییرات schema را از بین ببرد.
پیش از هر تغییر، دامنه خرابی را ثبت کنید
- صفحه اصلی، یک نوشته،
wp-admin، ورود و REST API را جداگانه باز کنید. - کد HTTP و متن آخرین خطای PHP را نگه دارید.
- نسخه قبلی و جدید وردپرس، PHP و افزونه‌های فعال را ثبت کنید.
- فضای آزاد دیسک و inode را بررسی کنید؛ جایگزینی ناقص فایل‌ها در دیسک پر رایج است.
- در ووکامرس، سفارش‌های ثبت‌شده پس از آخرین backup را مشخص کنید.
اگر فقط مدیریت خراب است ولی صفحات cacheشده باز می‌شوند، سالم بودن ظاهر سایت را به معنی سالم بودن PHP نگیرید. cache ممکن است پاسخ قدیمی را نشان دهد.
آیا آپدیت نیمه‌کاره مانده است؟
در ارتقای هسته، وردپرس موقتاً فایل .maintenance می‌سازد. اگر فرایند قطع شود، پیام maintenance باقی می‌ماند. پیش از حذف فایل مطمئن شوید هیچ ارتقای فعالی در حال اجرا نیست و فایل‌های هسته کامل‌اند. حذف .maintenance یک package ناقص را تعمیر نمی‌کند.
با WP-CLI می‌توان یکپارچگی فایل‌های توزیع رسمی هسته را بدون مقایسه دستی سنجید:
wp core version
wp core verify-checksumsفرمان checksum فایل‌های wp-content یا فایل‌های سفارشی را ارزیابی نمی‌کند. هشدار درباره فایل اضافه نیز باید با ساختار واقعی استقرار تفسیر شود. اگر هسته ناقص است، همان نسخه معتبر را مجدداً deploy کنید و به wp-content و wp-config.php دست نزنید.
خطای واقعی را از لاگ پیدا کنید
لاگ PHP-FPM، Apache/Nginx و wp-content/debug.log را در بازه زمانی خرابی بخوانید. نخستین خط مربوط به کد پروژه در stack trace معمولاً از پیام عمومی پایین trace مفیدتر است. نمایش خطا روی سایت عمومی را فعال نکنید. اگر لازم است ثبت وردپرس موقتاً فعال شود، WP_DEBUG_DISPLAY باید خاموش بماند.
نشانه‌هایی مانند Call to undefined function یا Deprecated یک معنا ندارند: اولی ممکن است fatal باشد، ولی یک warning قدیمی لزوماً علت توقف درخواست نیست. severity، timestamp و request خراب را به هم وصل کنید.
ناسازگاری افزونه و قالب را کنترل‌شده آزمایش کنید
هسته جدید ممکن است API منسوخ، signature یا رفتار PHP را آشکار کند که افزونه قبلاً به آن وابسته بوده است. اگر trace نام افزونه را نشان می‌دهد، همان افزونه را موقتاً غیرفعال کنید. وقتی عامل معلوم نیست، همه افزونه‌ها را فقط در یک بازه کوتاه کنار بگذارید و سپس یکی‌یکی فعال کنید. در فروشگاه، درگاه، webhook، subscription و jobهای زمان‌بندی‌شده را هنگام این آزمون در نظر بگیرید.
قالب را تنها وقتی آزمایش کنید که یک قالب پیش‌فرض سالم و سازگار نصب است. تعویض قالب روی production ممکن است widgetها و تنظیمات ظاهری را تغییر دهد؛ staging محل مناسب بازتولید است. برای جداسازی دقیق‌تر، راهنمای خرابی پس از آپدیت افزونه را نیز ببینید.
آیا باید نسخه قبلی وردپرس را برگردانیم؟
Rollback هسته آخرین اقدام تشخیصی نیست و نباید واکنش خودکار باشد. ابتدا release notes، حداقل PHP و سازگاری افزونه‌های حیاتی را بررسی کنید. اگر downgrade لازم شد، backup قبل از ارتقا، برنامه بازگشت و آزمون staging داشته باشید. فقط فایل‌های هسته را از منبع رسمی جایگزین کنید؛ دیتابیس را صرفاً برای هماهنگی ظاهری به نسخه قدیمی restore نکنید.
در سایتی با داده زنده، فایل و دیتابیس دو خط زمانی متفاوت دارند. بازگردانی دیتابیس می‌تواند کاربر، فرم، سفارش و تنظیمات جدید را حذف کند. قبل از هر restore باید RPO قابل قبول و راه ادغام داده تازه روشن باشد.
مراحل تأیید بعد از بازیابی
- خطای تازه PHP و status codeها را کنترل کنید.
- ورود و ذخیره نوشته یا محصول را آزمایش کنید.
- cron، REST API، فرم و ایمیل را متناسب با سایت بررسی کنید.
- در فروشگاه یک سناریوی سفارش آزمایشی ایمن اجرا کنید.
- cache و OPcache را فقط پس از استقرار نسخه سالم، هدفمند تازه کنید.
اشتباه‌هایی که بازیابی را سخت‌تر می‌کنند
- کپی کردن بسته کامل وردپرس روی
wp-content. - دادن permission عمومی مانند
777. - تغییر هم‌زمان PHP، قالب، افزونه‌ها و تنظیمات cache.
- پاک کردن لاگ‌ها پیش از ثبت علت.
- رها کردن سایت روی هسته قدیمی و آسیب‌پذیر پس از rollback موقت.
چه زمانی مداخله تخصصی لازم است؟
اگر ارتقای دیتابیس متوقف شده، خطا میان PHP-FPM و MySQL جابه‌جا می‌شود یا سایت سفارش زنده دارد، ادامه آزمون روی production ریسک دارد. در سرویس رفع مشکل فنی وردپرس می‌توان نسخه‌ها، لاگ‌ها و مسیر deploy را هماهنگ بررسی کرد. برای پیام fatal مشخص، راهنمای Critical Error وردپرس نیز مسیر تشخیص را تکمیل می‌کند.
پرسش‌های متداول
آیا پاک کردن .maintenance کافی است؟
فقط وقتی آپدیت تمام شده و فایل مانده باشد. اگر فایل‌های هسته ناقص‌اند یا PHP fatal دارد، حذف آن علت را رفع نمی‌کند.
چرا سایت عمومی باز است ولی مدیریت خراب شده؟
ممکن است page cache پاسخ قدیمی بدهد یا مسیر مدیریت hookها و queryهای متفاوتی اجرا کند. درخواست بدون cache و لاگ backend را بررسی کنید.
آیا می‌توان آپدیت خودکار را برای همیشه خاموش کرد؟
خاموشی دائمی ریسک امنیتی می‌سازد. بهتر است staging، backup قابل بازیابی و پنجره نگهداری تعریف شود.
چرا بعد از rollback هنوز خطا وجود دارد؟
ممکن است دیتابیس migrate شده، OPcache کد قبلی را نگه داشته یا علت اصلی افزونه و PHP باشد. فایل، schema و cache را جداگانه بسنجید.