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

فعال‌سازی ثبت خطا

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

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

مقدارهای true و false را داخل کوتیشن نگذارید. سپس عملیاتی را که خطا می‌دهد یک بار تکرار کنید. در حالت معمول گزارش در wp-content/debug.log ثبت می‌شود؛ نبودن فایل می‌تواند به نبود خطای تازه، مجوز نوشتن یا تنظیم مسیر اختصاصی مربوط باشد.

خواندن گزارش بدون حدس عجولانه

زمان خطا، نوع پیام، مسیر فایل و شماره خط را کنار هم بخوانید. Fatal error با Deprecated یکسان نیست. اشاره گزارش به یک افزونه سرنخ بررسی است، اما به‌تنهایی علت ریشه‌ای را ثابت نمی‌کند. تغییرات اخیر را ثبت و هر بار فقط یک مورد را در محیط آزمایشی تغییر دهید.

تفاوت debug.log و error_log

debug.log خروجی سازوکار ثبت خطای وردپرس است؛ لاگ PHP یا وب‌سرور ممکن است نام و مسیر دیگری داشته باشد و خطاهایی را ثبت کند که پیش از اجرای وردپرس رخ داده‌اند. برای دسترسی به آن از ابزار Errors هاست یا پشتیبانی کمک بگیرید. در مشکلات کمبود منابع، گزارش مصرف منابع cPanel نیز مفید است.

پایان عیب‌یابی

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

آیا فعال کردن دیباگ مشکل را برطرف می‌کند؟

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