Debug وردپرس باید خطای واقعی را ثبت کند، نه اینکه جزئیات سرور را به بازدیدکننده نشان دهد. روی production، نمایش خطا باید خاموش باشد و بازه logging کوتاه و هدفمند بماند. همه fatalهای PHP نیز به debug.log نمی‌رسند؛ خطاهای پیش از bootstrap را باید در لاگ PHP-FPM یا هاست پیدا کرد.
پاسخ سریع: از wp-config.php backup بگیرید، ثابت‌ها را قبل از خط توقف و فقط یک بار تعریف کنید، ثبت را روشن و نمایش را خاموش کنید. سپس مشکل را یک بار بازتولید، timestamp را یادداشت و بعد از جمع‌آوری شواهد تنظیمات اضافه را برگردانید.
تنظیم مناسب برای ثبت بدون نمایش عمومی
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );این خطوط باید قبل از عبارت توقف ویرایش در wp-config.php باشند. اگر ثابت قبلاً تعریف شده، همان مقدار را تغییر دهید؛ تعریف تکراری نتیجه را مبهم می‌کند. wp-config حاوی اطلاعات حساس است و نباید در تیکت عمومی یا repository باز قرار گیرد.
هر تنظیم دقیقاً چه می‌کند؟
| تنظیم | کاربرد | ملاحظه |
|---|---|---|
WP_DEBUG | فعال کردن حالت debug | warning بیشتری تولید می‌کند |
WP_DEBUG_LOG | ثبت در فایل یا مسیر تعیین‌شده | لاگ ممکن است حساس باشد |
WP_DEBUG_DISPLAY | نمایش خطا در پاسخ | روی production خاموش بماند |
SCRIPT_DEBUG | asset توسعه‌ای هسته | برای خطای PHP معمولاً لازم نیست |
SAVEQUERIES queryها را جمع می‌کند و سربار دارد؛ تنها برای تحلیل مشخص و کوتاه در محیط کنترل‌شده مناسب است.
چطور یک نمونه قابل استفاده ثبت کنیم؟
- timezone سرور و برنامه را مشخص کنید.
- لاگ قدیمی را حذف نکنید؛ marker زمانی یا rotation داشته باشید.
- دقیقاً همان URL و ورودی خراب را یک بار اجرا کنید.
- خطوط اطراف timestamp را بخوانید، نه فقط آخرین خط.
- بعد از ثبت، debug اضافی را خاموش و فایل را محافظت کنید.
اگر debug.log ساخته نشد
ممکن است مسیر content سفارشی باشد، PHP اجازه نوشتن نداشته باشد، تعریف ثابت مؤثر نباشد یا خطا پیش از logger وردپرس رخ دهد. لاگ PHP-FPM، Apache/Nginx یا پنل را بررسی کنید. برای رفع دسترسی از chmod 777 استفاده نکنید؛ مالکیت و permission حداقلی باید با کاربر اجرای PHP هماهنگ باشد.
ثبت خطا با نمایش خطا فرق دارد
فعال کردن display_errors در PHP می‌تواند مسیر فایل، نام کلاس و داده داخلی را در HTML یا JSON آشکار کند. logging و نمایش دو تصمیم جدا هستند. روی سایت عمومی پیام مناسب کاربر حفظ و جزئیات در مقصد محافظت‌شده ثبت شود.
در Docker یا چند backend
filesystem کانتینر ممکن است موقت باشد و debug.log با recreate از بین برود یا روی node دیگری نوشته شود. volume، stdout/stderr، log driver و شناسه کانتینر را بررسی کنید. request ID کمک می‌کند یک درخواست میان proxy، PHP و برنامه دنبال شود.
Debug در staging با production چه تفاوتی دارد؟
در staging می‌توان logging پرجزئیات‌تری داشت، اما محیط باید از اینترنت عمومی، موتور جست‌وجو و سرویس‌های واقعی جدا باشد. production به retention، rotation و حداقل‌سازی داده نیاز دارد. اگر خطا فقط در production رخ می‌دهد، اختلاف نسخه، config، داده، cache، cron و ترافیک را فهرست کنید؛ انتقال کور همه داده‌ها به staging هم ریسک حریم خصوصی دارد و هم ممکن است علت را تغییر دهد.
چگونه مطمئن شویم تنظیمات مؤثر شده‌اند؟
وجود خطوط در فایل کافی نیست. ممکن است برنامه از wp-config دیگری استفاده کند، environment ثابت را override کند یا درخواست به node متفاوت برسد. مسیر root سایت را با deployment تطبیق دهید و پس از یک درخواست واقعی، timestamp مقصد logging را کنترل کنید. برای «آزمایش» عمداً روی production خطای PHP ایجاد نکنید؛ همان رخداد گزارش‌شده را بازتولید کنید.
مدیریت حجم و نگهداری لاگ
یک warning داخل loop می‌تواند فایل را سریع بزرگ کند و فضای دیسک را بگیرد. اندازه فایل و فضای آزاد را زیر نظر داشته باشید، منبع تکرار را اصلاح و rotation متناسب تعریف کنید. پاک کردن مداوم فایل بدون رفع علت، کنترل ظرفیت نیست. در محیط کانتینری نیز محدودیت log driver و retention سطح میزبان را جداگانه بررسی کنید.
Debug چه چیزی را ثابت نمی‌کند؟
فعال بودن debug به‌تنهایی علت را پیدا نمی‌کند و نبود پیام نیز سلامت کامل را ثابت نمی‌سازد. خطای frontend، timeout شبکه، kill شدن process و پاسخ cache ممکن است در debug.log دیده نشوند. نتیجه باید با status HTTP، لاگ وب‌سرور، رفتار مرورگر و در صورت نیاز وضعیت منابع سرور تطبیق داده شود. همچنین warning مربوط به یک افزونه لزوماً به معنی مقصر بودن همان افزونه در خرابی فعلی نیست؛ زمان، severity و مسیر اجرای درخواست تعیین‌کننده‌اند.
چه چیزهایی را پیش از اشتراک‌گذاری حذف کنیم؟
- cookie، nonce، token و header احراز هویت
- رمز و DSN دیتابیس
- ایمیل، تلفن و اطلاعات سفارش
- کلید API و payload کامل webhook
- مسیرهای شامل نام کاربری سیستم
بعد از تشخیص
WP_DEBUG و logging اضافه را مطابق سیاست پروژه خاموش کنید، اما logging استاندارد PHP و مانیتورینگ production را از بین نبرید. علت، نسخه‌ها، timestamp و اصلاح را ثبت کنید. اگر پیام fatal دارید، راهنمای Critical Error ادامه مسیر را توضیح می‌دهد.
چه زمانی کمک تخصصی مناسب است؟
اگر لاگ ساخته نمی‌شود، خطا متناوب است یا اطلاعات بین PHP-FPM و وب‌سرور پخش شده، سرویس رفع مشکل فنی وردپرس می‌تواند زنجیره کامل را بررسی کند.
پرسش‌های متداول
آیا WP_DEBUG سایت را کند می‌کند؟
بسته به حجم warning و I/O می‌تواند سربار بسازد؛ استفاده production باید کوتاه و هدفمند باشد.
آیا debug.log باید عمومی قابل دانلود باشد؟
خیر. این فایل ممکن است داده داخلی داشته باشد و باید با محل یا rule مناسب محافظت شود.
خاموش کردن WP_DEBUG همه logging را قطع می‌کند؟
خیر. PHP-FPM و وب‌سرور سیاست‌های مستقل دارند و logging عملیاتی آن‌ها باید حفظ شود.