اگر هنگام باز کردن سایت وردپرس با پیام There has been a critical error on this website روبه‌رو شده‌اید، احتمالا یک خطای جدی در اجرای کدهای وردپرس، افزونه‌ها، قالب یا محیط PHP رخ داده است. این خطا ممکن است باعث شود صفحه اصلی، پیشخوان یا هر دو از دسترس خارج شوند.
برای رفع خطای Critical Error وردپرس، لازم نیست سایت را از نو نصب کنید یا فایل‌های اصلی را حذف کنید. با بررسی ایمیل مدیر سایت، لاگ خطاهای PHP و غیرفعال کردن کنترل‌شده افزونه‌ها و قالب می‌توانید در بسیاری از موارد علت مشکل را پیدا کنید. در این راهنما، مراحل عیب‌یابی را از روش‌های کم‌خطر تا بررسی‌های فنی‌تر پیش می‌بریم.
خطای Critical Error در وردپرس چیست؟
خطای Critical Error یا خطای بحرانی زمانی نمایش داده می‌شود که وردپرس با مشکلی جدی در اجرای کدهای PHP روبه‌رو شود و نتواند درخواست را به شکل عادی پردازش کند. این پیام معمولا به تنهایی علت دقیق خطا را نشان نمی‌دهد و برای تشخیص مشکل باید جزئیات فنی را بررسی کنید.
برای مثال، ممکن است پس از نصب یا به‌روزرسانی یک افزونه، تغییر قالب، ارتقای نسخه PHP یا ویرایش فایل‌های سایت این خطا ظاهر شود. در بعضی موارد هم کمبود حافظه PHP یا خطای موجود در یک کد اختصاصی باعث بروز مشکل می‌شود.
علت‌های رایج خطای Critical Error وردپرس
- ناسازگاری یا خطای برنامه‌نویسی در یکی از افزونه‌ها
- وجود مشکل در قالب فعال یا کدهای اختصاصی آن
- ناسازگاری افزونه یا قالب با نسخه PHP
- کمبود حافظه اختصاص‌یافته به PHP
- خطا در فایل‌های سفارشی یا فایل‌های اصلی وردپرس
- به‌روزرسانی ناقص وردپرس، قالب یا افزونه‌ها
- اجرای کد معیوب در فایل‌هایی مانند
functions.php
اگر خطا بلافاصله پس از یک تغییر مشخص ایجاد شده است، همان تغییر را به عنوان سرنخ اصلی در نظر بگیرید. این کار می‌تواند زمان عیب‌یابی را کاهش دهد.
قبل از رفع خطا، این اقدامات را انجام دهید
پیش از تغییر فایل‌ها یا تنظیمات سرور، چند اقدام ساده انجام دهید تا از آسیب بیشتر جلوگیری شود.
- اگر به پیشخوان دسترسی دارید، از نصب افزونه جدید یا اجرای به‌روزرسانی‌های بیشتر خودداری کنید.
- اگر به فایل‌ها یا پایگاه داده دسترسی دارید، پیش از تغییرات مهم نسخه پشتیبان تهیه کنید.
- زمان شروع خطا و آخرین تغییرات سایت را یادداشت کنید.
- اگر سایت فروشگاهی است، پیش از غیرفعال کردن افزونه‌ها به پرداخت‌ها، سفارش‌ها و رزروهای فعال توجه کنید.
- از حذف مستقیم فایل‌های ناشناخته یا جایگزینی کامل فایل‌های پیکربندی خودداری کنید.
روش اول، ایمیل خطای وردپرس را بررسی کنید
در بسیاری از موارد، وردپرس پس از تشخیص یک خطای بحرانی، برای مدیر سایت ایمیلی ارسال می‌کند. این ایمیل ممکن است نام افزونه یا قالبی را که باعث خطا شده است نشان دهد و در بعضی شرایط لینک ورود به حالت بازیابی یا Recovery Mode را در اختیار شما قرار دهد.
برای بررسی این مورد، مراحل زیر را انجام دهید:
- inbox ایمیلی را که به عنوان ایمیل مدیریت وردپرس ثبت شده است بررسی کنید.
- پوشه Spam را هم بررسی کنید.
- اگر ایمیل خطای بحرانی دریافت کرده‌اید، نام افزونه یا قالب و جزئیات فنی آن را بخوانید.
- در صورت وجود لینک Recovery Mode، از آن برای ورود امن به پیشخوان و بررسی عامل خطا استفاده کنید.
حالت بازیابی می‌تواند اجرای بخش مشکل‌دار را برای مدیر محدود کند تا امکان ورود به پیشخوان فراهم شود. این قابلیت لزوما به معنی رفع کامل خطا برای بازدیدکنندگان نیست. پس از شناسایی عامل مشکل، باید آن را به شکل اصولی برطرف کنید.
روش دوم، لاگ خطاهای PHP را بررسی کنید
اگر ایمیل وردپرس علت مشکل را مشخص نکرد یا اصلا ایمیلی دریافت نکردید، لاگ خطاها یکی از مهمترین منابع عیب‌یابی است. در این گزارش‌ها ممکن است نام فایل، مسیر افزونه، شماره خط یا نوع خطای PHP ثبت شده باشد.
اگر به فایل wp-config.php دسترسی دارید، می‌توانید ثبت خطاهای وردپرس را به طور موقت فعال کنید. پیش از تغییر فایل، بکاپ تهیه کنید و تنظیمات موجود را حفظ کنید. مقادیر زیر باید پیش از خطی قرار بگیرند که پایان ویرایش تنظیمات را مشخص می‌کند:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );اگر این ثابت‌ها از قبل در فایل وجود دارند، آن‌ها را دوباره اضافه نکنید و مقادیر موجود را با دقت اصلاح کنید. پس از فعال شدن ثبت خطا، فایل wp-content/debug.log را بررسی کنید. در بعضی شرایط، به دلیل محدودیت دسترسی یا توقف زودهنگام PHP، جزئیات خطا در این فایل ثبت نمی‌شود.
اگر به سرور دسترسی دارید، لاگ PHP-FPM و وب‌سرور را هم بررسی کنید. مسیر فایل‌ها به نوع سرور و تنظیمات میزبان بستگی دارد. برای نمونه، در بعضی سرورهای لینوکس می‌توانید از دستور زیر برای مشاهده آخرین خطاهای Nginx استفاده کنید:
tail -n 100 /var/log/nginx/error.logاین مسیر برای همه سرورها یکسان نیست. در سرورهای دارای LiteSpeed یا OpenLiteSpeed و در هاست‌های اشتراکی ممکن است لاگ در مسیر دیگری ذخیره شود. در صورت نداشتن دسترسی، از پشتیبانی میزبانی بخواهید لاگ PHP را در زمان وقوع خطا بررسی کند.
نکته امنیتی: نمایش خطاهای PHP به بازدیدکنندگان می‌تواند اطلاعات فنی سایت را افشا کند. مقدار WP_DEBUG_DISPLAY را روی false نگه دارید و پس از پایان عیب‌یابی، ثبت خطا را به حالت مناسب محیط عملیاتی برگردانید. فایل لاگ را هم از دسترسی عمومی محافظت کنید.
روش سوم، افزونه‌های وردپرس را بررسی کنید
اگر خطای Critical Error پس از نصب یا به‌روزرسانی افزونه ایجاد شده است، ابتدا همان افزونه را بررسی کنید. اگر نام افزونه در ایمیل خطا یا لاگ PHP مشخص است، از همان مورد شروع کنید. در غیر این صورت، می‌توانید افزونه‌ها را به شکل کنترل‌شده غیرفعال کنید تا عامل مشکل مشخص شود.
اگر به پیشخوان وردپرس دسترسی دارید
به بخش افزونه‌ها بروید و افزونه مشکوک را غیرفعال کنید. سپس صفحه‌ای را که با خطا مواجه شده بود دوباره بررسی کنید. اگر مشکل برطرف شد، سازگاری افزونه، نسخه PHP و آخرین تغییرات آن را بررسی کنید.
اگر پیشخوان در دسترس نیست
از طریق FTP، SFTP یا File Manager هاست به مسیر wp-content بروید. پیش از تغییر نام پوشه‌ها، مطمئن شوید مسیر مربوط به همان نصب وردپرس است. برای غیرفعال کردن موقت تمام افزونه‌های عادی می‌توانید نام پوشه plugins را به شکل موقت تغییر دهید، برای مثال:
plugins -> plugins.disabledحالا سایت را دوباره بررسی کنید. اگر خطا برطرف شد، احتمال دارد یکی از افزونه‌ها عامل مشکل باشد. نام پوشه را به plugins برگردانید و افزونه‌ها را با روش مناسب و مرحله‌ای بررسی کنید. بسته به وضعیت وردپرس، ممکن است لازم باشد افزونه‌ها را دوباره از پیشخوان فعال کنید.
این روش همه افزونه‌های داخل پوشه را غیرفعال می‌کند و ممکن است عملکرد فروشگاه، فرم‌ها یا بخش‌های دیگر سایت را مختل کند. در سایت‌های حساس، ابتدا نسخه پشتیبان تهیه کنید و در صورت امکان آزمایش را در محیط staging انجام دهید.
روش چهارم، قالب فعال را بررسی کنید
اگر با غیرفعال کردن افزونه‌ها مشکل حل نشد، قالب فعال و کدهای سفارشی آن را بررسی کنید. خطاهای موجود در فایل functions.php یا ناسازگاری قالب با نسخه PHP می‌توانند باعث توقف اجرای سایت شوند.
اگر به پیشخوان دسترسی دارید، به طور موقت به یک قالب پیشفرض و سازگار وردپرس تغییر دهید. پیش از این کار مطمئن شوید قالب جایگزین نصب شده است و می‌توانید در صورت نیاز به قالب قبلی برگردید.
اگر پیشخوان در دسترس نیست، تغییر نام پوشه قالب فعال از طریق File Manager یا SFTP ممکن است باعث شود وردپرس به قالب پیشفرض نصب‌شده دیگری برگردد. با این حال، این رفتار در همه شرایط تضمین‌شده نیست. پیش از تغییر نام، از فایل‌ها نسخه پشتیبان بگیرید و نام پوشه قالب را برای بازگردانی ثبت کنید.
اگر سایت با قالب پیشفرض درست کار کرد، کدهای اختصاصی، نسخه قالب و سازگاری آن با افزونه‌ها را بررسی کنید. قالب اصلی را بدون تشخیص علت حذف نکنید.
روش پنجم، سازگاری نسخه PHP را بررسی کنید
وردپرس، قالب و افزونه‌ها باید با نسخه PHP فعال روی سایت سازگار باشند. تغییر نسخه PHP گاهی باعث بروز خطاهای جدی می‌شود، به ویژه زمانی که یک افزونه قدیمی از توابع حذف‌شده یا ناسازگار استفاده می‌کند.
اگر خطا پس از تغییر نسخه PHP رخ داده است، نسخه قبلی و جدید را با هم مقایسه کنید و لاگ خطا را بررسی کنید. در صورت نیاز، پس از تهیه نسخه پشتیبان و بررسی سازگاری، نسخه‌ای را انتخاب کنید که هم پشتیبانی می‌شود و هم با اجزای سایت سازگار است.
برای مشاهده نسخه PHP در محیط خط فرمان می‌توانید از دستور زیر استفاده کنید:
php -vتوجه داشته باشید که نسخه PHP خط فرمان ممکن است با نسخه PHP مورد استفاده وب‌سایت متفاوت باشد. نسخه فعال سایت را از پنل میزبانی یا تنظیمات PHP-FPM بررسی کنید و بدون بررسی سازگاری، نسخه PHP را در محیط عملیاتی تغییر ندهید.
روش ششم، محدودیت حافظه PHP را بررسی کنید
برخی افزونه‌ها و عملیات سنگین ممکن است به حافظه بیشتری نیاز داشته باشند. اگر خطاهای ثبت‌شده به کمبود حافظه اشاره می‌کنند، مقدار حافظه مجاز PHP و مصرف واقعی سایت را بررسی کنید.
در لاگ ممکن است پیامی مشابه Allowed memory size exhausted مشاهده کنید. این پیام نشان می‌دهد اجرای یک درخواست به سقف حافظه مجاز رسیده است، اما برای رفع پایدار مشکل باید مشخص شود کدام عملیات حافظه زیادی مصرف می‌کند.
می‌توانید مقدار WP_MEMORY_LIMIT و تنظیمات حافظه PHP را بررسی کنید. افزایش حافظه در wp-config.php یا تنظیمات سرور باید متناسب با محدودیت‌های میزبانی انجام شود و لزوما هر خطای بحرانی را رفع نمی‌کند. اگر مصرف حافظه غیرعادی است، افزونه یا کد عامل مشکل را هم بررسی کنید.
روش هفتم، فایل‌های اصلی وردپرس را بررسی کنید
اگر مشکل پس از به‌روزرسانی ناقص یا تغییر فایل‌های اصلی ایجاد شده باشد، بررسی سلامت فایل‌های هسته وردپرس اهمیت دارد. پیش از جایگزینی فایل‌ها، نسخه پشتیبان تهیه کنید و از سالم بودن نسخه‌ای که قرار است استفاده شود مطمئن شوید.
اگر WP-CLI روی سرور نصب است، می‌توانید از دستور زیر برای بررسی صحت فایل‌های هسته استفاده کنید:
wp core verify-checksumsاین دستور فایل‌های هسته را با چک‌سام‌های نسخه رسمی مقایسه می‌کند. در صورت مشاهده اختلاف، قبل از جایگزینی فایل‌ها علت را بررسی کنید. فایل‌های سفارشی، افزونه‌ها و قالب‌ها با این دستور به طور کامل بررسی نمی‌شوند. اگر به WP-CLI دسترسی ندارید، از روش به‌روزرسانی یا تعمیر معتبر وردپرس با رعایت نسخه پشتیبان استفاده کنید.
روش هشتم، تغییرات اخیر سایت را بررسی کنید
اگر هیچ‌کدام از روش‌های قبلی علت را مشخص نکرد، تغییرات اخیر سایت را مرور کنید. نصب افزونه جدید، ویرایش کد اختصاصی، تغییر قالب، ارتقای PHP، انتقال سایت یا بازیابی نسخه پشتیبان می‌تواند سرنخ مهمی باشد.
- زمان دقیق شروع خطا را مشخص کنید.
- نام افزونه‌ها و قالب‌هایی را که در همان بازه تغییر کرده‌اند ثبت کنید.
- لاگ PHP را با زمان وقوع خطا تطبیق دهید.
- اگر خطا پس از انتقال یا بازیابی سایت ایجاد شده، مسیرها، مجوز فایل‌ها و تنظیمات محیط را بررسی کنید.
- اگر نسخه پشتیبان سالم دارید، قبل از بازگردانی، اثر آن بر سفارش‌ها، نوشته‌ها و اطلاعات جدید را ارزیابی کنید.
اگر خطای Critical Error برطرف نشد، چه کنیم؟
اگر سایت همچنان از دسترس خارج است، از تغییرات تصادفی و حذف فایل‌ها خودداری کنید. برای ادامه عیب‌یابی، اطلاعات زیر را جمع‌آوری کنید:
- متن کامل خطا یا تصویر آن
- زمان شروع مشکل و آخرین تغییرات سایت
- بخش مرتبط از لاگ PHP یا وب‌سرور
- نسخه PHP فعال سایت و نوع وب‌سرور
- اینکه خطا در کل سایت رخ می‌دهد یا فقط در یک صفحه
در این شرایط، بررسی تخصصی کد، افزونه‌ها، قالب و تنظیمات سرور می‌تواند علت اصلی را مشخص کند. برای سایت‌های فروشگاهی یا پرترافیک، اولویت باید بازگرداندن سرویس با کمترین ریسک و حفظ اطلاعات کاربران باشد.
تفاوت خطای Critical Error با خطاهای 500 و 503 چیست؟
این خطاها ممکن است در ظاهر نتیجه مشابهی داشته باشند، اما همیشه علت یکسانی ندارند. خطای Critical Error معمولا به یک مشکل جدی در اجرای کدهای وردپرس یا PHP اشاره می‌کند. خطای 500 یک پاسخ عمومی از سمت سرور است و خطای 503 معمولا نشان می‌دهد سرویس در حال حاضر قادر به پاسخ‌گویی عادی نیست.
برای آشنایی با روش‌های عیب‌یابی این خطاها، مقاله‌های زیر را بخوانید:
- خطای 500 وردپرس چیست؟ ۱۰ روش رفع خطای Internal Server Error
- خطای 503 در وردپرس، ۱۰ روش کاربردی برای حل مشکل
چطور از تکرار خطای بحرانی وردپرس جلوگیری کنیم؟
- وردپرس، قالب و افزونه‌ها را با برنامه مشخص و پس از بررسی سازگاری به‌روزرسانی کنید.
- از افزونه‌ها و قالب‌های معتبر و به‌روز استفاده کنید.
- پیش از تغییرات مهم، از فایل‌ها و پایگاه داده نسخه پشتیبان تهیه کنید.
- تغییرات حساس را ابتدا در محیط آزمایشی بررسی کنید.
- لاگ‌های PHP و سرور را هنگام بروز خطا بررسی کنید.
- نسخه PHP و منابع میزبانی را متناسب با نیاز سایت نگه دارید.
- برای سایت‌های مهم، برنامه بازیابی و آزمایش دوره‌ای نسخه‌های پشتیبان داشته باشید.
جمع‌بندی
خطای Critical Error وردپرس معمولا نشانه یک مشکل جدی در اجرای کدهای سایت است، اما در بسیاری از موارد می‌توان علت آن را با بررسی ایمیل مدیر، لاگ PHP، افزونه‌ها، قالب و نسخه PHP پیدا کرد. بهتر است از روش‌های کم‌خطر شروع کنید، پیش از تغییرات مهم نسخه پشتیبان بگیرید و هر تغییر را به صورت کنترل‌شده انجام دهید.
اگر با وجود بررسی این موارد، سایت همچنان از دسترس خارج است یا رفع خطا به بررسی کد و سرور نیاز دارد، استفاده از خدمات تخصصی عیب‌یابی وردپرس می‌تواند از آزمون‌وخطاهای پرریسک جلوگیری کند. هدف، فقط باز شدن دوباره سایت نیست، بلکه شناسایی علت اصلی و کاهش احتمال تکرار مشکل است.
