اگر سایت دقیقاً پس از به‌روزرسانی یک افزونه از دسترس خارج شده، هدف اول بازگرداندن دسترسی است، نه ادامه آپدیت‌ها. خرابی می‌تواند از ناسازگاری PHP، تداخل با افزونه دیگر، migration ناقص دیتابیس یا قطع شدن جایگزینی فایل‌ها باشد. نام افزونه و متن خطا را ثبت کنید؛ سپس فقط همان تغییر را کنترل‌شده از مدار خارج کنید.
مسیر کوتاه: از وضعیت فعلی backup بگیرید، لاگ PHP را بخوانید، افزونه تازه‌به‌روزشده را موقتاً غیرفعال کنید و پس از بازگشت سایت علت را در staging بازتولید کنید. بازگرداندن نسخه قدیمی فایل‌ها بدون توجه به تغییرات دیتابیس همیشه امن نیست.
آیا واقعاً آپدیت افزونه عامل خرابی است؟
هم‌زمانی نشانه مهمی است، اما کافی نیست. زمان خطا را با log، تاریخ فایل‌ها و فعالیت مدیران مقایسه کنید. ممکن است در همان لحظه نسخه PHP یا قالب تغییر کرده، دیسک پر شده یا OPcache کد قبلی را نگه داشته باشد. اگر فقط مسیرهای وابسته به افزونه خراب‌اند، انتساب قوی‌تر است.
وقتی wp-admin باز نمی‌شود
- از File Manager یا SSH به
wp-content/pluginsبروید. - نام پوشه افزونه مظنون را، مثلاً از
sample-pluginبهsample-plugin.disabledتغییر دهید. - سایت و مدیریت را در پنجره ناشناس آزمایش کنید.
- اگر سایت برگشت، پوشه را حذف نکنید؛ لاگ را نگه دارید و نسخه‌ها را مقایسه کنید.
اگر افزونه معلوم نیست، تغییر نام کل پوشه plugins یک آزمون اضطراری است. پس از ورود نام پوشه را برگردانید و افزونه‌ها را تک‌تک فعال کنید. در ووکامرس اثر توقف درگاه، حمل‌ونقل، subscription و jobهای زمان‌بندی‌شده را در نظر بگیرید.
لاگ چه چیزی را روشن می‌کند؟
عبارت‌هایی مانند Uncaught Error، Call to undefined function، Class not found یا Allowed memory size مسیرهای متفاوتی دارند. نخستین فایل متعلق به افزونه در stack trace مهم‌تر از آخرین خط عمومی وردپرس است. لاگ PHP-FPM یا هاست را کنار debug.log ببینید؛ بعضی fatalها پیش از فعال شدن logger وردپرس رخ می‌دهند.
wp plugin status plugin-slug
wp plugin deactivate plugin-slug
wp plugin list --update=availableاین دستورها باید روی سایت و slug درست اجرا شوند. در multisite وضعیت network-active را هم بررسی کنید. نام افزونه را از حدس وارد نکنید و پیش از دستور تغییر‌دهنده backup داشته باشید.
Rollback چه زمانی مناسب است؟
اگر نسخه قبلی از منبع معتبر و backup در دسترس است و افزونه migration برگشت‌ناپذیر دیتابیس نداشته، بازگردانی فایل‌ها می‌تواند راه موقت باشد. ابتدا changelog و مستندات downgrade را بخوانید. برای افزونه‌های فروشگاهی و امنیتی، نسخه قدیمی ممکن است schema یا داده جدید را نشناسد.
مسیر کم‌ریسک‌تر برای تصمیم
- clone سایت را در staging بسازید.
- نسخه PHP، وردپرس و افزونه‌های فعال را مشابه production نگه دارید.
- خرابی را با همان درخواست بازتولید کنید.
- نسخه قبلی یا patch رسمی را نصب و داده‌ها را بررسی کنید.
- پس از deploy، لاگ و مسیرهای تجاری را مانیتور کنید.
اگر آپدیت نیمه‌کاره مانده باشد
قطع فرایند ممکن است فایل maintenance یا مجموعه‌ای ناقص از فایل‌های افزونه باقی بگذارد. وجود .maintenance و کامل بودن package را بررسی کنید، اما فایل را صرفاً به امید حل fatal پاک نکنید. اگر package ناقص است، همان نسخه معتبر را دوباره deploy کنید و checksum یا فهرست فایل‌ها را کنترل کنید.
چه سازگاری‌هایی باید کنترل شوند؟
| لایه | سؤال تشخیصی | شاهد قابل اتکا |
|---|---|---|
| PHP | نسخه و extensionهای لازم پشتیبانی می‌شوند؟ | نیازمندی رسمی افزونه و خطای PHP |
| WordPress | حداقل نسخه هسته رعایت شده است؟ | readme و changelog همان release |
| افزونه‌ها | hook، class یا کتابخانه مشترک تداخل دارد؟ | stack trace و آزمون فعال‌سازی مرحله‌ای |
| دیتابیس | migration کامل شده و قابل downgrade است؟ | گزارش افزونه، schema و backup پیش از تغییر |
| Cache | کد قدیمی هنوز در OPcache یا object cache است؟ | پاک‌سازی هدفمند پس از deploy سالم |
پیام «این افزونه با نسخه وردپرس شما آزمایش نشده» به‌تنهایی اثبات ناسازگاری نیست؛ همان‌طور که نبود آن نیز تضمین نمی‌دهد. تصمیم باید بر اساس نیازمندی نسخه، لاگ و تست سناریوی واقعی باشد.
آزمون پذیرش پس از بازیابی
دیدن صفحه اصلی کافی نیست. اگر افزونه فرم‌ساز است، ارسال و دریافت ایمیل را آزمایش کنید؛ اگر افزونه فروشگاهی است، یک سفارش آزمایشی با روش پرداخت امن و محیط مناسب انجام دهید؛ اگر افزونه cache یا امنیت است، login، REST API و webhookها را بررسی کنید. صف cron و خطاهای جدید لاگ نیز چند دقیقه زیر نظر بمانند.
در سایتی که deployment خودکار دارد، نسخه package و commit باید در release ثبت شود. تغییر مستقیم فایل روی سرور اگرچه ممکن است قطعی را سریع رفع کند، اما drift می‌سازد و در deploy بعدی ناپدید می‌شود. اصلاح نهایی را به منبع کد یا فرایند مدیریت‌شده برگردانید.
اشتباه‌های رایج
- جایگزینی کل
wp-contentو آسیب به uploads. - آپدیت همه افزونه‌ها برای «هماهنگ شدن» هنگام قطعی.
- پاک کردن log پیش از ثبت stack trace.
- نصب نسخه افزونه از منبع ناشناس.
- بازگردانی دیتابیس قدیمی فروشگاه بدون حفظ سفارش‌های جدید.
پیشگیری برای آپدیت بعدی
هر تغییر جداگانه همراه backup و smoke test انجام شود. تست ورود، فرم تماس، جست‌وجو، سبد خرید، checkout و cron را بر اساس نقش افزونه انتخاب کنید. مانیتورینگ status code و error rate باید پس از انتشار ادامه داشته باشد. آپدیت خودکار برای همه افزونه‌ها تصمیم یکسانی نیست؛ حساسیت، امکان rollback و staging تعیین‌کننده‌اند.
چه زمانی ادامه کار را متوقف کنیم؟
اگر پیام عمومی خطای بحرانی دیده می‌شود، راهنمای Critical Error وردپرس را برای Recovery Mode و debug دنبال کنید. پاسخ HTTP 500 نیز مسیر جداگانه‌ای دارد که در راهنمای خطای 500 توضیح داده شده است.
اگر افزونه داده تجاری نگه می‌دارد، migration دیتابیس اجرا کرده، یا پس از غیرفعال‌سازی هنوز workerهای PHP crash می‌کنند، دستکاری بیشتر روی production منطقی نیست. در رفع تخصصی مشکل وردپرس می‌توان نسخه‌ها، stack trace و تغییرات دیتابیس را کنار هم بررسی کرد.
پرسش‌های متداول
حذف افزونه بهتر است یا غیرفعال‌سازی؟
برای تشخیص، غیرفعال‌سازی کافی و قابل بازگشت است. حذف ممکن است uninstall hook اجرا کند یا داده پاک کند.
پاک کردن cache مشکل را حل می‌کند؟
اگر OPcache نسخه قبلی را نگه داشته باشد مفید است؛ cache علت یک fatal واقعی را برطرف نمی‌کند.
آیا نسخه قبلی را از backup برگردانیم؟
فقط پس از بررسی سازگاری schema و منبع backup. در سایت تراکنشی، restore دیتابیس نیازمند برنامه حفظ داده‌های جدید است.