خطای بحرانی در این وب‌سایت رخ داده است: معنی‌اش چیست و چطور رفعش کنیم

این پیام یعنی PHP هنگام ساختن صفحه شما به یک خطای مهلک برخورده و وردپرس پیش از آنکه تبدیل به صفحه سفید شود آن را گرفته است. خطا واقعی است، مشخص است و ثبت هم شده — وردپرس فقط حاضر نیست آن را در مرورگر چاپ کند، چون نمایش ردپای خطا روی یک صفحه عمومی مسیر فایل‌ها و کد شما را در اختیار هر بازدیدکننده‌ای می‌گذارد.

پس رفع این مشکل هیچ‌وقت حدس‌وگمان نیست. مسیرش این است: خطای واقعی را بخوانید، بعد بر اساس همان چیزی که نوشته عمل کنید.

در واقع چه اتفاقی می‌افتد

از وردپرس ۵.۲ به بعد یک مدیریت‌کننده خطای مهلک در هسته وجود دارد. وقتی PHP وسط یک درخواست از کار می‌افتد، این مدیریت‌کننده وارد می‌شود، خروجی خراب را با آن جمله مؤدبانه و کلی جایگزین می‌کند و — اگر بتواند تشخیص دهد کدام افزونه یا قالب مقصر بوده — تلاش می‌کند برای مدیر سایت ایمیلی با لینک ورود به حالت بازیابی بفرستد.

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

چیزی که می‌بینید	کجا	چه چیزی به شما می‌گوید
«خطای بحرانی در این وب‌سایت رخ داده است.»	بخش عمومی سایت، در حالت خارج‌شده از حساب	خطای مهلک رخ داده، جزئیات بیشتری فاش نمی‌شود
همان جمله به‌علاوه «درباره عیب‌یابی وردپرس بیشتر بدانید»	بخش عمومی سایت یا wp-admin	همان خطا، وردپرس صفحه راهنما را به شما پیشنهاد می‌دهد
«…لطفاً صندوق ورودی ایمیل مدیر سایت را برای دریافت دستورالعمل بررسی کنید.»	بخش عمومی سایت	مدیریت‌کننده خطا گمان کرده ایمیل بازیابی را فرستاده است

حالت سوم همان حالت مفید است. یعنی وردپرس خرابی را به یک افزونه یا قالب مشخص نسبت داده و کوشیده راه ورودی به شما بدهد.

گام ۱: ایمیل حالت بازیابی را بررسی کنید

وردپرس لینک بازیابی را به نشانی ایمیل مدیر سایت می‌فرستد — همانی که در تنظیمات ← همگانی ثبت شده — که اغلب همان نشانی‌ای نیست که با آن وارد می‌شوید. آن صندوق ورودی را ببینید و اسپم را هم فراموش نکنید.

این ایمیل حاوی یک لینک بلند است که به چیزی شبیه ?action=enter_recovery_mode ختم می‌شود. با باز کردن آن در حالت بازیابی وارد wp-admin می‌شوید؛ جایی که افزونه یا قالب مقصر متوقف شده و در یک اعلان قرمز بالای صفحه مشخص شده است. از همان‌جا می‌توانید آن را به‌شکل عادی غیرفعال کنید.

دو نکته صادقانه. اول اینکه این ایمیل را همان پردازه PHP می‌سازد که همین حالا از کار افتاده، روی هاستی که ممکن است اصلاً سیستم ارسال ایمیل سالمی نداشته باشد — نرسیدن ایمیل بسیار رایج است و نبودنش هیچ چیزی درباره خطا به شما نمی‌گوید. دوم اینکه لینک بازیابی منقضی می‌شود (به‌طور پیش‌فرض تقریباً یک روز)، پس ممکن است ایمیل قدیمی توی صندوق شما دیگر کار نکند؛ با بارگذاری دوباره سایت یک خرابی تازه بسازید و منتظر ایمیل جدید بمانید.

اگر می‌خواهید این ایمیل به جایی برود که واقعاً آن را می‌خوانید، آن را صراحتاً در wp-config.php تعیین کنید:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

گام ۲: خطای واقعی را بخوانید

این همان گامی است که یک سایت خراب را به یک تعمیر پنج‌دقیقه‌ای تبدیل می‌کند. این خط‌ها را در wp-config.php و بالای خطی که می‌گوید ویرایش را متوقف کنید اضافه کنید:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

مقدار false برای WP_DEBUG_DISPLAY مهم است — خطا را از مرورگر دور نگه می‌دارد و در عین حال روی دیسک می‌نویسد، پس در حین عیب‌یابی مسیرهای سرور را در معرض دید بازدیدکننده نمی‌گذارید.

یک بار صفحه خراب را دوباره بارگذاری کنید، سپس wp-content/debug.log را باز کنید. آخرین ورودی تقریباً چنین شکلی دارد:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

مسیر فایل همان پاسخ است. اگر به wp-content/plugins/ اشاره می‌کند، همان افزونه مقصر است. اگر به wp-content/themes/ اشاره می‌کند، قالب مقصر است — که خیلی وقت‌ها چیزی است که تازه داخل functions.php جای‌گذاری شده.

اگر debug.log ساخته نشد، ممکن است پوشه قابل نوشتن نباشد یا یک افزونه امنیتی محل ثبت لاگ را جای دیگری برده باشد. در این حالت سراغ لاگ خطای PHP هاست بروید — بیشتر کنترل پنل‌ها بخشی به نام «Error Log» یا «Logs» دارند و همان خطای مهلک با زمان دقیق آنجا هست.

آن ورودی را در رمزگشای لاگ خطای وردپرس جای‌گذاری کنید تا زبان فنی PHP به معنای عملی‌اش ترجمه شود و بفهمید اول باید سراغ کدام فایل بروید.

وقتی کارتان تمام شد این خط‌های دیباگ را پاک کنید. روشن ماندن WP_DEBUG روی سایت زنده دیسک را پر می‌کند و اگر WP_DEBUG_DISPLAY روزی دوباره روشن شود، مسیرهای سرور را به‌صورت عمومی چاپ می‌کند.

گام ۳: به wp-admin برگردید

اگر wp-admin هم از کار افتاده و هیچ ایمیل بازیابی‌ای نرسیده، همه افزونه‌ها را در سطح فایل سیستم غیرفعال کنید. با SFTP (یا فایل منیجر هاست) وصل شوید و نام یک پوشه را عوض کنید:

mv wp-content/plugins wp-content/plugins-off

وردپرس افزونه‌ها را پیدا نمی‌کند، پس همه را غیرفعال می‌کند و دسترسی به پیشخوان تقریباً همیشه برمی‌گردد. بعد:

1. نام پوشه را دوباره به plugins برگردانید. همه‌چیز غیرفعال می‌ماند — وردپرس آن‌ها را به‌عنوان غیرفعال ثبت کرده است.
2. افزونه‌ها را یکی‌یکی فعال کنید و بعد از هر کدام بخش عمومی سایت را باز کنید.
3. همان افزونه‌ای که خطا را برمی‌گرداند مقصر شماست.

اگر با غیرفعال بودن همه افزونه‌ها سایت هنوز خراب است، قالب مظنون است. نام پوشه قالب فعال را در wp-content/themes/ تغییر دهید تا وردپرس، در صورت نصب بودن، به یک قالب پیش‌فرض برگردد.

سه دلیلی که ارزش دانستن دارند

به‌روزرسانی افزونه یا قالبی که fatal می‌دهد. به‌مراتب رایج‌ترین حالت. لاگ مستقیماً نام فایل را می‌آورد. همان یک افزونه را به نسخه قبلی برگردانید، یا غیرفعال نگهش دارید و خط لاگ را برای توسعه‌دهنده‌اش بفرستید.

ناسازگاری نسخه PHP. هاست‌ها PHP را طبق زمان‌بندی خودشان ارتقا می‌دهند، گاهی بدون هشدار چندانی. کدی که برای PHP قدیمی نوشته شده ممکن است روی نسخه جدید اصلاً پارس نشود. نشانه‌اش این است که شما هیچ تغییری نداده‌اید و همه‌چیز یک‌باره خراب شده. برگرداندن PHP به یک نسخه فرعی پایین‌تر از پنل هاست یک روش تشخیص معتبر است — اما آن را خریدن زمان بدانید، نه راه‌حل. نسخه‌های قدیمی PHP دیگر وصله امنیتی نمی‌گیرند.

تمام‌شدن حافظه. لاگ می‌گوید «Allowed memory size of X bytes exhausted». بالا بردن این محدودیت در wp-config.php منطقی است:

define( 'WP_MEMORY_LIMIT', '256M' );

اما صادق باشیم که این کار چه می‌کند: سقف را برمی‌دارد، ولی چیزی را که برای رندر یک صفحه ۲۵۶ مگابایت مصرف کرده درست نمی‌کند. اگر مدام لازم است این عدد را بالاتر ببرید، چیزی — معمولاً یک ایمپورت، یک صفحه‌ساز یا یک کوئری بد نوشته‌شده — مشکل واقعی است.

توصیه‌هایی که با خیال راحت می‌توانید نادیده بگیرید

«فقط محدودیت حافظه را زیاد کن.» فقط وقتی مربوط است که لاگ واقعاً از تمام‌شدن حافظه بگوید. در غیر این صورت هیچ چیزی را عوض نمی‌کند و فقط پنهان می‌کند که شما اصلاً خطا را نخوانده‌اید.

«هسته وردپرس را دوباره نصب کن.» فایل‌های هسته به‌ندرت مقصرند و جایگزین کردنشان وقتی را هدر می‌دهد که می‌توانستید صرف خواندن یک خط لاگ کنید.

«مدیریت‌کننده خطای مهلک را خاموش کن.» ثابتی برای غیرفعال کردنش وجود دارد و نتیجه‌اش این است که خطای خام به‌جای خطای گرفته‌شده روی سایت عمومی شما چاپ می‌شود. این یعنی نمایش مسیر فایل‌ها به بازدیدکننده‌ها. به‌جایش از WP_DEBUG_LOG با WP_DEBUG_DISPLAY خاموش استفاده کنید — همان اطلاعات، بدون هیچ افشایی.

«کش را پاک کن.» خطای مهلک در PHP و پیش از آنکه افزونه کش بتواند چیزی سرو کند رخ می‌دهد. اگر نسخه‌ای کش‌شده از صفحه خطا سرو می‌شود، پاک کردن کش بعد از رفع علت کمک می‌کند — نه به‌جای آن.

هنوز گیر کرده‌اید؟

اگر لاگ به‌جای چیزی در wp-content به یک فایل هسته اشاره می‌کند، توضیح محتمل‌تر این است که افزونه‌ای که زودتر بارگذاری شده وضعیتی را که هسته به آن تکیه دارد خراب کرده، نه اینکه هسته خراب شده باشد. با تغییر نام پوشه همه‌چیز را خاموش کنید، مطمئن شوید سایت تمیز بالا می‌آید، بعد افزونه‌ها را یکی‌یکی برگردانید — آخرین افزونه‌ای که پیش از بازگشت خطا فعال کرده‌اید همانی است که باید گزارشش کنید، همراه با خط لاگ.