بعد از یه آپدیت ساده، سایت وردپرسی‌تون بالا نمیاد یا صفحه سفید می‌بینید؟ قبل از خاموش و روشن کردن افزونه‌ها، سراغ لاگ خطای وردپرس (فایلی که اتفاق‌های سایت توش یادداشت می‌شه) برید. کافیه debug.log رو توی wp-content باز کنید، آخرین Fatal error (خطایی که جلوی ادامه اجرای کد رو می‌گیره) رو پیدا کنید و ببینید بعد از wp-content/plugins/ چه اسمی اومده. این اسم نزدیک‌ترین سرنخه، نه حکم قطعی. اینجا می‌بینید خواندن PHP Error Log در وردپرس چطور انجام می‌شه.
PHP Error Log چیست و چه کمکی به پیدا کردن افزونه مشکل‌ساز می‌کند؟
PHP Error Log یه فایل متنیه که خطاهای کدهای PHP (زبان برنامه‌نویسی وردپرس) توش ثبت می‌شه، همراه زمان و آدرس فایل مشکل‌دار.
PHP Error Log چه اطلاعاتی ثبت می‌کند؟
هر پیام خطا معمولاً پنج بخش داره:
- زمان وقوع (Timestamp): معمولاً به وقت UTC (وقت مرجع جهانی).
- نوع خطا (Error Type): مثل Fatal error یا Warning.
- شرح مشکل (Error Message): مثلاً تابع پیدا نشده.
- مسیر فایل (File Path) و شماره خط (Line Number): محل دقیق خطا.
بعضی خطاها بخش اضافه‌ای به اسم Stack Trace هم دارن.
تفاوت PHP Error Log هاست با فایل debug.log وردپرس چیست؟
لاگ هاست رو وب‌سرور (نرم‌افزاری که سایت رو به بازدیدکننده‌ها می‌رسونه) و PHP می‌سازن؛ debug.log فایل خود وردپرسه و فقط با روشن کردن حالت عیب‌یابی (Debug) ساخته می‌شه.
| ویژگی | لاگ سرور/هاست | debug.log وردپرس |
|---|---|---|
| چه کسی می‌سازه | وب‌سرور و PHP | خود وردپرس |
| محل معمول | پنل هاست یا error_log | پوشه wp-content |
| نیاز به فعال‌سازی | معمولاً نه | بله |
| ترتیب نمایش | بسته به ابزار؛ در cPanel جدید به قدیم | جدیدها پایین فایل |
| ساعت ثبت | معمولاً ساعت سرور | معمولاً UTC |
| خطای قبل از لود وردپرس | معمولاً ثبت می‌شه | ممکنه ثبت نشه |
قبل از بررسی لاگ خطا چه اقداماتی انجام دهیم؟
- بکاپ بگیرید از فایل‌ها و دیتابیس (پایگاه داده‌ای که نوشته‌ها و تنظیمات سایت توشه).
- ساعت دقیق مشکل رو یادداشت کنید.
- تغییرات ۲۴ ساعت اخیر رو مرور کنید (آپدیت افزونه، قالب یا PHP).
چرا باید پیش از عیب‌یابی بکاپ بگیریم؟
بکاپ مثل طناب ایمنیِ صخره‌نوردیه. موقع ویرایش wp-config.php (فایل تنظیمات اصلی وردپرس) یا تغییر نام پوشه‌ها، یه اشتباه کوچیک ممکنه سایت رو خراب کنه.
چگونه زمان وقوع خطا و تغییرات اخیر سایت را ثبت کنیم؟
ساعت خرابی و آخرین کارتون رو یادداشت کنید. ساعت debug.log معمولاً UTC هست، ولی لاگ سرور یا صفحه Errors در cPanel ممکنه ساعت خود سرور رو نشون بده. ایران فعلاً ساعت تابستانی نداره، پس اختلافش با UTC برابر ۳ ساعت و ۳۰ دقیقه‌ست.
چگونه PHP Error Log را در هاست و وردپرس پیدا کنیم؟
دو راه دارید: debug.log توی wp-content، یا لاگ سرور از پنل هاست. اگه از یه هاست وردپرس با cPanel یا DirectAdmin (پنل‌های مدیریت هاست) استفاده می‌کنید، معمولاً به هر دو می‌رسید.
چگونه فایل debug.log را در مسیر wp-content پیدا کنیم؟
مسیر معمول public_html/wp-content/debug.log هست. توی پنل هاست، File Manager (مدیریت فایل‌های هاست) رو باز کنید، وارد public_html و بعد wp-content بشید و روی debug.log راست‌کلیک و View بزنید. خطاهای جدید معمولاً پایین فایل اضافه می‌شن؛ برید انتهای فایل.
چگونه Error Log را از پنل هاست بررسی کنیم؟
- cPanel: از Metrics وارد Errors بشید. طبق مستندات cPanel این صفحه آخرین خطاها رو نشون می‌ده و برخلاف debug.log، از جدید به قدیم مرتبه.
- DirectAdmin: مسیر دقیق بسته به نسخه و قالب پنل فرق می‌کنه؛ معمولاً توی بخش Logs یا Error Log هست.
اگر فایل لاگ وجود نداشت یا خالی بود چه کنیم؟
ممکنه دیباگ روشن نشده باشه، وردپرس اجازه ساخت فایل نداشته باشه، مسیر لاگ فرق کنه، یا خطا قبل از فعال‌سازی رخ داده باشه. دیباگ رو فعال کنید، صفحه خراب رو رفرش کنید و سطح دسترسی (Permission) پوشه wp-content رو ببینید؛ مقدار رایجش ۷۵۵ هست.
چگونه WP_DEBUG و WP_DEBUG_LOG را فعال کنیم؟
برای فعال کردن WP_DEBUG (حالت عیب‌یابی وردپرس) چند خط به wp-config.php اضافه کنید.
هشدار: طبق مستندات رسمی دیباگ وردپرس، روی سایت زنده با احتیاط دیباگ کنید. WP_DEBUG_DISPLAY رو حتماً false بذارید، وگرنه خطاها و مسیر پوشه‌های سرور به همه نشون داده می‌شه.
اگه سایت به خطای Fatal بخوره، ممکنه وردپرس ایمیلی به مدیر بفرسته (حالت بازیابی یا Recovery Mode، از وردپرس ۵.۲). با لینک اون ایمیل می‌شه وارد پیشخوان شد و افزونه مشکل‌دار رو موقتاً متوقف کرد؛ توضیح رسمی Recovery Mode رو ببینید.
تنظیم WP_DEBUG، WP_DEBUG_LOG و WP_DEBUG_DISPLAY در wp-config.php
- توی File Manager روی wp-config.php راست‌کلیک و Edit بزنید.
- برید پایین تا خط
/* That's all, stop editing! Happy publishing. */. - اگه خطی مثل
define( 'WP_DEBUG', false );هست، جایگزینش کنید و کدهای زیر رو بالای اون خط بذارید:
php
// روشن کردن حالت عیب‌یابی وردپرس
define( 'WP_DEBUG', true );
// ذخیره تمام خطاها در فایل wp-content/debug.log
define( 'WP_DEBUG_LOG', true );
// جلوگیری از نمایش خطاها در ظاهر سایت برای بازدیدکنندگان
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
- ذخیره کنید و صفحه مشکل‌دار رو باز کنید تا debug.log ساخته بشه.
چگونه از نمایش عمومی خطاها در سایت زنده جلوگیری کنیم؟
با false بودن WP_DEBUG_DISPLAY و صفر بودن display_errors، خطاها فقط توی debug.log ثبت می‌شن.
اجزای یک پیام PHP Error Log را چگونه بخوانیم؟
هر پیام از همون پنج بخش ساخته شده؛ بعضی‌ها Stack Trace هم دارن، یعنی فهرست مرحله‌هایی که کد تا رسیدن به خطا طی کرده. نمونه زیر فرضیه، از افزونه‌ای خیالی:
[16-Oct-2025 14:32:17 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wp_enqueue_script() in /home/u123456/domains/example.com/public_html/wp-content/plugins/smart-contact-form/includes/class-form.php:84
Stack trace:
#0 .../smart-contact-form/includes/class-form.php(84): wp_enqueue_script()
...
#7 {main}
| جزء پیام | چه چیزی را نشان می‌دهد؟ | کاربرد |
|---|---|---|
| Timestamp | زمان ثبت خطا | مقایسه با زمان آپدیت |
| Error Type | نوع و شدت خطا | تشخیص توقف سایت |
| Error Message | شرح مشکل | فهمیدن ماجرا |
| File Path | فایل درگیر | پیدا کردن افزونه |
| Line Number | سطر کد | محل دقیق مشکل |
| Stack Trace (اضافه) | زنجیره فراخوانی | دیدن فایل‌های درگیر |
معنی زمان ثبت خطا (Timestamp) و نوع خطا چیست؟
ساعت 14:32:17 UTC حدود ۱۸:۰۲ به وقت ایرانه. PHP Fatal error هم یعنی PHP نتونسته از مشکل رد بشه و اجرا رو متوقف کرده.
مسیر فایل و شماره خط چه چیزی را نشان می‌دهند؟
مسیر فایل مثل آدرس ساختمونه و شماره خط مثل شماره واحد؛ توی مثال یعنی افزونه smart-contact-form، فایل class-form.php، سطر ۸۴.
چگونه Stack Trace را بخوانیم و فایل مرتبط با افزونه را پیدا کنیم؟
شماره #0 نزدیک‌ترین مرحله به خطاست و فهرست تا {main} (نقطه شروع اجرا) میره. دیدن فایل‌های وردپرس مثل wp-includes اینجا عادیه و یعنی هسته خراب نیست. برای پیدا کردن افزونه، خط اول پیام و خط thrown in رو ببینید.
تفاوت Fatal Error، Warning، Notice و Deprecated در چیست؟
تفاوت اصلی توی شدت اثرشونه؛ مثل چراغ‌های داشبورد، چراغ جوش آوردن موتور (Fatal) یعنی همین حالا توقف کنید و چراغ آب شیشه‌شور نه.
| نوع خطا | مفهوم | اثر احتمالی | اقدام پیشنهادی |
|---|---|---|---|
| Fatal Error | اجرای کد متوقف شده | صفحه سفید یا خطای بحرانی | پیدا کردن افزونه مقصر |
| Warning | اجرا ادامه داره | شاید بخش کوچکی کار نکنه | تست همون بخش |
| Notice | نقص کوچک یا استفاده نادرست از یه مقدار | معمولاً اثری نداره | بررسی بعداً |
| Deprecated | استفاده از قابلیت قدیمی | فعلاً کار می‌کنه | برنامه‌ریزی برای آپدیت |
توی نسخه‌های جدید PHP (مثل ۸)، بعضی Noticeهای قدیمی، مثل متغیر تعریف‌نشده، به Warning ارتقا پیدا کردن.
کدام خطاها ممکن است سایت را کاملاً از دسترس خارج کنند؟
معمولاً Fatal error و Parse error (اشتباه نگارشی در کد) پشت صفحه سفید یا پیام «خطای مهم» هستن؛ مشکل سرور یا دیتابیس هم ممکنه همین نتیجه رو بدن.
کدام پیام‌ها الزاماً به معنی خرابی افزونه نیستند؟
Notice و Deprecated، و خیلی وقت‌ها Warning، لزوماً یعنی افزونه خراب نیست؛ توی سایت‌های سالم هم هست.
چگونه از روی مسیر فایل، افزونه مشکل‌ساز را شناسایی کنیم؟
توی خط خطا دنبال wp-content/plugins/ بگردید؛ اولین اسم بعدش، پوشه افزونه‌ایه که خطا ازش اومده.
| الگوی مسیر | مظنون اولیه | اقدام بعدی |
|---|---|---|
.../plugins/plugin-name/... | همون افزونه | غیرفعال‌سازی موقت |
.../themes/theme-name/... | قالب یا کدهای سفارشی | بررسی کدهای قالب |
.../mu-plugins/... | افزونه ضروری (Must-Use) که خودکار لود می‌شه | پیدا کردن اضافه‌کننده |
object-cache.php یا advanced-cache.php | فایل‌های کش | بررسی تنظیمات کش |
.../wp-includes/... یا .../wp-admin/... | معمولاً هسته که افزونه صداش زده | بررسی بقیه Stack Trace |
| مسیرهای دیگه | ممکنه به تنظیمات سرور یا PHP مربوط باشه | پرسیدن از پشتیبانی |
چگونه نام افزونه را از مسیر wp-content/plugins استخراج کنیم؟
مثلاً توی /plugins/woocommerce/... مظنون ووکامرسه. اگه پیشخوان هم بالا نمیاد، راهنمای بالا نیامدن پیشخوان وردپرس بعد از آپدیت نشون می‌ده چطور با File Manager و تغییر نام پوشه جلو برید.
اگر خطا به فایل قالب یا هسته وردپرس اشاره کند چه کنیم؟
مسیر themes/ یعنی مشکل از قالبه؛ معمولاً کد اضافه‌شده به functions.php (فایل قالب برای کدهای سفارشی) یا ناسازگاری با PHP. اسم پوشه قالب فعال رو موقتاً عوض کنید تا وردپرس سراغ قالب پیش‌فرض بره (به شرط نصب بودنش). اگه مسیر به wp-includes یا wp-admin بخوره، سراغ هسته نرید؛ معمولاً یه افزونه یا قالب ورودی اشتباه بهش داده.
چگونه بفهمیم افزونه علت اصلی خطاست یا فقط در Stack Trace درگیر شده است؟
ببینید اسم افزونه توی خط اول و thrown in هست یا فقط وسط #0 و #1. گاهی ووکامرس توی Stack Trace هست، ولی یه افزونه جانبی بهش ورودی اشتباه داده؛ پس همه اسم‌های درگیر رو تست کنید.
پس از پیدا کردن افزونه مشکوک، چگونه علت خطا را تأیید کنیم؟
اسم افزونه توی لاگ مثل اثر انگشته؛ سرنخ مهمیه، ولی بدون تست نتیجه قطعی نیست.
احتیاط: به‌محض دیدن اسم افزونه، «حذف» نزنید؛ ممکنه جدول‌ها و تنظیماتش پاک بشن. برای تست فقط غیرفعالش کنید یا اسم پوشه‌اش رو عوض کنید.
چگونه خطا را با زمان ثبت‌شده در لاگ تطبیق دهیم؟
ببینید ساعت خطا با ساعت خرابی یا آپدیت می‌خونه یا نه. ساعت آخرین خطا رو انتهای debug.log ببینید (اگه UTC بود، ۳ ساعت و ۳۰ دقیقه اضافه کنید) و صفحه خراب رو رفرش کنید. اگه همون خطا با زمان تازه ثبت شد، احتمال زیادی هست مظنون درست باشه.
چگونه افزونه را در محیط آزمایشی (Staging) بررسی کنیم؟
استیجینگ (Staging) یه کپی از سایتتونه روی ساب‌دامنه جدا، برای آزمایش بی‌خطر. افزونه مشکوک رو غیرفعال کنید. اگه خطا رفت و با فعال کردن دوباره برگشت، احتمال خیلی زیادی هست که همون افزونه علت باشه.
اگر با غیرفعال‌کردن افزونه مشکل حل نشد چه چیزی را بررسی کنیم؟
ممکنه کش، تداخل چند افزونه یا نسخه PHP دخیل باشه. کش (ذخیره موقت صفحه‌ها برای سرعت بیشتر) و CDN (شبکه‌ای که نسخه کش‌شده سایت رو از سرورهای نزدیک‌تر به کاربر می‌رسونه) رو پاک کنید؛ اگه PHP تازه عوض شده، موقتاً برش گردونید.
خطاهای رایج هنگام بررسی PHP Error Log و راه‌حل آن‌ها کدامند؟
رایج‌ترین مشکل‌ها ساخته نشدن debug.log، ثبت نشدن خطای جدید و دیدن چند افزونه توی یه خطاست؛ اول مطمئن بشید خود لاگ‌گیری کار می‌کنه.
چرا لاگ خطای مرتبط با مشکل فعلی را نشان نمی‌دهد؟
ممکنه دیباگ روشن نبوده یا مسیر لاگ فرق کنه، یا مشکل بالاتر از وردپرس (وب‌سرور یا منابع هاست) پیش اومده باشه؛ توی این حالت لاگ سرور رو ببینید.
اگه سایت خطای ۵۰۴ می‌ده، عیب‌یابی خطای ۵۰۴ وردپرس کمک می‌کنه. اگه هم به سقف NPROC (سقف تعداد پردازش‌های هم‌زمان حساب هاست) شک دارید، از بررسی محدودیت منابع هاست شروع کنید.
چگونه خطاهای ناشی از ناسازگاری نسخه PHP یا تعارض چند افزونه را رفع کنیم؟
اگه خطاها بعد از تغییر نسخه PHP شروع شدن، دنبال Deprecated یا Uncaught TypeError (خطای ورودی نادرست به یه تابع) بگردید. از Select PHP Version هاست، موقتاً نسخه رو یه پله عقب ببرید، افزونه‌ها رو آپدیت کنید و بعد به نسخه پایدار برگردید. این برگشت فقط موقتیه، چون نسخه‌های قدیمی PHP از پشتیبانی رسمی خارج می‌شن و ریسک امنیتی دارن.
پس از عیب‌یابی چه کنیم و چگونه از تکرار خطا جلوگیری کنیم؟
بعد از رفع مشکل:
- خاموش کردن دیباگ: WP_DEBUG و WP_DEBUG_LOG رو false کنید.
- پاک کردن لاگ: اگه لازم دارید، اول کپی بگیرید.
- برگردوندن نام پوشه‌ها (اگه عوض کرده بودید).
- پاک کردن کش.
- تست صفحه اصلی، فرم تماس و خرید.
هشدار امنیتی: ممکنه debug.log با آدرس مستقیم توی مرورگر باز بشه و اطلاعات سرور رو نشون بده. اگه با تنظیمات هاست راحتید، مسیر لاگ رو بیرون از پوشه عمومی سایت بذارید؛ وگرنه فایل رو حذف کنید.
پس از رفع مشکل چه تنظیماتی را به حالت امن برگردانیم؟
سطح دسترسی رایج برای پوشه‌ها ۷۵۵ و برای فایل‌ها ۶۴۴ هست؛ اگه برای تست عوضشون کردید، برگردونید.
چگونه گزارش خطا را برای پشتیبانی هاست آماده کنیم؟
۵ تا ۱۰ خط آخر لاگ (شامل Fatal error و Stack Trace) رو با توضیح کاری که قبل از خطا کردید توی تیکت بفرستید. اگه بازم نشد، پشتیبانی فنی ابرینا می‌تونه لاگ‌هاتون رو بررسی کنه.
سؤالات متداول درباره خواندن لاگ ارورهای وردپرس
PHP Error Log در وردپرس چیست؟
یه فایل متنیه که پیام‌های خطای PHP رو با تاریخ و آدرس فایل مقصر ثبت می‌کنه.
فایل PHP Error Log وردپرس کجا قرار دارد؟
توی بخش Errors پنل هاست یا public_html/wp-content/debug.log.
چگونه از روی Error Log افزونه مشکل‌ساز را پیدا کنیم؟
جلوی Fatal error دنبال wp-content/plugins/plugin-name/ بگردید و افزونه رو موقتاً غیرفعال کنید.
تفاوت PHP Error Log با debug.log وردپرس چیست؟
PHP Error Log معمولاً خطاها رو در سطح وب‌سرور و موتور PHP ثبت می‌کنه، ولی debug.log فایل وردپرسه که با WP_DEBUG و WP_DEBUG_LOG ساخته می‌شه.
آیا فعال کردن WP_DEBUG برای سایت اصلی خطرناک است؟
خود ثبت خطا خطری نداره، به شرط اینکه WP_DEBUG_DISPLAY روی false باشه.
جمع‌بندی
خواندن PHP Error Log در وردپرس سریع‌ترین راه برای پیدا کردن افزونه مشکل‌ساز بدون حدس و گمانه. لاگ خطای وردپرس سرنخ می‌ده، نه حکم نهایی؛ پس با تست بسنجید و دفعه بعد که صفحه سفید دیدید، مستقیم سراغ ریشه مشکل برید:
- بکاپ بگیرید، دیباگ رو فعال کنید و WP_DEBUG_DISPLAY رو روی false بذارید.
- آخرین خطا و مسیر wp-content/plugins/ رو ببینید.
- افزونه مشکوک رو موقتاً غیرفعال کنید و تست کنید.
- دیباگ رو خاموش و لاگ رو پاک کنید.
