learn

لاگ خطای PHP در وردپرس؛ فعال‌سازی، خواندن و حفاظت از گزارش

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

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

لاگ خطای PHP در وردپرس کجا قرار دارد؟

سه محل را از هم جدا کنید: گزارش اشکال‌زدایی وردپرس، لاگ PHP سرویس و لاگ وب‌سرور. محل دو مورد آخر را میزبان تعیین می‌کند. در حالت پیش‌فرض وردپرس، فعال‌کردن ثبت دیباگ می‌تواند فایل wp-content/debug.log را بسازد؛ نام آن debug.file نیست.

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

تنظیم موقت در محیط تست

ابتدا فایل 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-config.php محل و ترتیب این تنظیمات را شرح می‌دهد.

در سایت عمومی، ثبت خطای کنترل‌شدهٔ PHP در مسیر محافظت‌شدهٔ سرویس معمولاً مناسب‌تر از رهاکردن حالت توسعه است. در هر محیط، از قابل‌دانلودنبودن فایل گزارش برای عموم مطمئن شوید؛ به وجود نام debug.log به‌عنوان حفاظت تکیه نکنید.

چگونه یک خطا را پیدا و تفسیر کنیم؟

  1. زمان شروع آزمایش را یادداشت کنید.
  2. همان عملی را که مشکل ایجاد می‌کند یک بار تکرار کنید.
  3. پیام‌های تازهٔ گزارش را با زمان آزمایش تطبیق دهید.
  4. نوع خطا، فایل، شمارهٔ خط و زنجیرهٔ فراخوان را بخوانید.
  5. مؤلفه و نسخهٔ درگیر را برای اصلاح مشخص کنید.

Parse error معمولاً به ساختار کد اشاره می‌کند. Fatal error می‌تواند اجرای درخواست را متوقف کند. Warning، Notice یا Deprecated نیز باید در زمینهٔ خود بررسی شوند؛ همهٔ آن‌ها شدت و اثر یکسان ندارند. فایل نام‌برده ممکن است محل آشکارشدن مشکل باشد، نه تنها علت آن.

اگر فایل ساخته نشد

ابتدا مطمئن شوید رویداد قابل‌ثبت رخ داده، فایل درست را ویرایش کرده‌اید و مسیر برای فرایند PHP قابل‌نوشتن است. مجوز ۷۷۷ راه‌حل عمومی نیست. اگر خطا پیش از فعال‌شدن تنظیمات وردپرس رخ دهد، ممکن است فقط در لاگ PHP یا وب‌سرور دیده شود.

مرجع تنظیمات خطای PHP تفاوت display_errors، log_errors و error_log را توضیح می‌دهد. مقدار مؤثر وب می‌تواند با خط فرمان فرق کند و تنظیمات مدیریتی میزبان هم اثر دارند. در این حالت، زمان دقیق خطا را برای بررسی لاگ سرویس ارائه کنید.

پایان عیب‌یابی و حفاظت داده

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

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

مطالعهٔ مرتبط

بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.

مطالب مرتبط

ارسال نظر

فهرست مطالب