رفع کرش وردپرس یک دستور ثابت ندارد. صفحهٔ سفید، خطای بحرانی PHP، خطای اتصال پایگاه داده و بازنشدن دامنه ممکن است ظاهراً شبیه باشند، اما از لایههای متفاوتی میآیند. ابتدا متن کامل خطا، ساعت وقوع و آخرین تغییر سایت را ثبت کنید تا اصلاح به علت واقعی مربوط باشد.
شروع رفع کرش وردپرس با تشخیص نشانه
| نشانه | بررسی اولیه |
|---|---|
| دامنه پیدا نمیشود یا خطای گواهی دارد | DNS، اعتبار دامنه و TLS؛ لزوماً وردپرس اجرا نشده است. |
| پیام خطای بحرانی یا صفحهٔ سفید | گزارش PHP، ایمیل بازیابی و آخرین تغییر افزونه یا قالب. |
| خطای اتصال پایگاه داده | دسترسی سرویس دیتابیس، اطلاعات اتصال و محدودیت منابع. |
| خطای 500، 502 یا 504 | لاگ وبسرور، PHP، پراکسی و وضعیت سرویس میزبان. |
| فقط یک بخش خراب است | همان مسیر، درخواست یا افزونهٔ مرتبط؛ از تغییر کل سایت شروع نکنید. |
صفحهٔ اصلی ممکن است از کش نمایش داده شود، در حالی که مدیریت یا فرمها خراباند. برعکس، محدودیت شبکهٔ یک کاربر نیز میتواند شبیه قطعی عمومی باشد. دامنهٔ اختلال را با یک دستگاه یا اتصال دیگر مقایسه کنید.
ورود از Recovery Mode
وردپرس در بعضی خطاهای جدی PHP، ایمیلی برای مدیر میفرستد که لینک ورود بازیابی و جزئیات خطا دارد. طبق راهنمای Recovery Mode، جزء مشکلدار برای نشست بازیابی متوقف میشود تا بتوانید وارد مدیریت شوید؛ این بهتنهایی به معنی رفع خطا برای همهٔ بازدیدکنندگان نیست.
- ایمیل بازیابی را در حساب مدیر و پوشهٔ هرزنامه بررسی کنید.
- از لینک معتبر همان سایت وارد شوید؛ آن را عمومی نکنید.
- نام افزونه یا قالب گزارششده را بخوانید.
- جزء معیوب را اصلاح یا موقتاً غیرفعال کنید.
- از حالت بازیابی خارج شوید و نتیجه را خارج از نشست مدیر ببینید.
این روش همهٔ خطاهای سرور، DNS یا کارهای پسزمینه را پوشش نمیدهد. نرسیدن ایمیل نیز بهتنهایی دلیل نبودن خطای PHP نیست.
بررسی افزونه بدون حذف اطلاعات
اگر خطا پس از بهروزرسانی یک افزونه شروع شده و لاگ همان جزء را نشان میدهد، از غیرفعالکردن همان افزونه شروع کنید. وقتی مدیریت باز نمیشود، میتوان نام پوشهٔ همان افزونه در wp-content/plugins را موقتاً تغییر داد؛ پوشه را حذف نکنید.
اگر علت مشخص نیست و به جداسازی همهٔ افزونههای معمول نیاز دارید، راهنمای عیبیابی وردپرس تغییر نام پوشهٔ plugins، مراجعه به صفحهٔ افزونهها و سپس برگرداندن نام را شرح میدهد. بعد، افزونهها را جداگانه فعال و نتیجه را بررسی کنید. این آزمایش ممکن است فروش، فرم یا ورود را موقتاً مختل کند و افزونههای اجباری mu-plugins و فایلهای drop-in را پوشش نمیدهد.
آزمون قالب و سازگاری PHP
اگر خطا به قالب یا کد سفارشی مربوط است، در محیط آزمایشی یا از مدیریت به یک قالب سالم و سازگار تغییر دهید. تغییر نام کل پوشهٔ themes روش مناسبی نیست؛ قالب جایگزین نیز از دسترس خارج میشود. جایگزینی قالب ممکن است چیدمان، ابزارکها یا بخشهای وابسته را تغییر دهد.
قالب فرزند و والد را با هم در نظر بگیرید. باقیماندن خطا پس از یک تغییر، بیتقصیربودن قطعی قالب را ثابت نمیکند. نسخهٔ PHP و افزونههای لازم آن را با نیاز نرمافزار تطبیق دهید؛ بازگشت دائمی به نسخهٔ بدون پشتیبانی راهحل نهایی نیست.
لاگ، حافظه و منابع هاست
گزارش خطا را در همان بازهٔ زمانی بخوانید. پیام کمبود حافظه با timeout یا پرشدن دیسک یکسان نیست. افزایش نامحدود حافظه، کوئری سنگین یا حلقهٔ معیوب را اصلاح نمیکند. وضعیت فضای ذخیرهسازی، پردازشهای PHP و پایگاه داده را از پنل یا پشتیبانی میزبان بررسی کنید.
در صورت نیاز به ثبت جزئیات، از راهنمای اشکالزدایی وردپرس استفاده کنید و نمایش عمومی خطا را خاموش نگه دارید. فایل گزارش ممکن است مسیرها یا اطلاعات خصوصی داشته باشد؛ آن را عمومی منتشر نکنید و ثبت اضافی را پس از تشخیص جمع کنید.
آلودگی، حمله و بازگردانی سایت
کرش بهتنهایی اثبات هک نیست. اگر فایل ناشناس، کاربر غیرمجاز یا تغییر مشکوک دارید، بررسی امنیتی جدا لازم است. اسکن بیرونی همهٔ فایلهای سرور را نمیبیند و نتیجهٔ پاک آن تضمین سلامت کامل نیست. بازیابی نسخهٔ آلوده یا برگرداندن سایت بدون بستن راه نفوذ، مشکل را تکرار میکند.
CDN یا فایروال هم تضمین رفع هر قطعی نیست؛ حملهٔ حجمی و اشباع منابع ممکن است همکاری میزبان بخواهد. اگر بازگردانی لازم شد، سازگاری فایل و دیتابیس و ازبیننرفتن سفارشهای جدید را بررسی کنید.
چه زمانی رفع خطا کامل است؟
علاوه بر صفحهٔ اصلی، ورود، جستوجو، فرم تماس و در سایت فروشگاهی سبد خرید و ثبت سفارش را بررسی کنید. علت، تغییر انجامشده و زمان رفع را ثبت کنید. هدف، بازگشت پایدار عملکرد سایت است؛ صرفاً ناپدیدشدن یک پیام خطا کافی نیست.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شدهاند.