فعال‌سازی و غیرفعال‌سازی نمایش خطا PHP در وردپرس

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

راه‌حل حرفه‌ای این است که نمایش خطا برای بازدیدکننده غیرفعال باشد، اما خطاها همچنان در فایل لاگ ذخیره شوند. در محیط توسعه می‌توانید خطاها را روی صفحه ببینید و هنگام انتقال سایت به محیط اصلی، این نمایش را کنترل کنید. در این راهنما دقیقاً یاد می‌گیرید چطور با تغییر فایل wp-config.php، استفاده از افزونه یا تنظیمات PHP، این فرایند را به‌درستی انجام دهید؛ بدون اینکه با ویرایش اشتباه، سایت دچار خطای اتصال یا صفحه سفید شود.

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

فعال‌سازی و غیرفعال‌سازی نمایش خطا PHP در وردپرس

در وردپرس، کنترل خطاهای PHP معمولاً با ثابت‌های دیباگ در فایل wp-config.php انجام می‌شود. این تنظیمات به شما اجازه می‌دهند خطاها را ببینید، آن‌ها را در فایل لاگ ثبت کنید یا نمایش مستقیمشان را برای کاربران ببندید.

فهرست مطالب

• • چرا خطاهای PHP در وردپرس نمایش داده می‌شوند؟
  • تنظیمات اصلی دیباگ وردپرس
  • روش فعال‌سازی نمایش خطاهای PHP
  • روش غیرفعال‌سازی نمایش خطاهای PHP
  • کنترل خطاها از طریق تنظیمات PHP
  • اشتباهات رایج و روش رفع آن‌ها
  • تأثیر نمایش خطا بر امنیت و سرعت
  • چک‌لیست عملی مدیریت خطا
  • سؤالات متداول

چرا خطاهای PHP در وردپرس نمایش داده می‌شوند؟

تفاوت خطا، هشدار و اعلان PHP

هر پیام PHP الزاماً به معنای ازکارافتادن سایت نیست. خطای Fatal error معمولاً اجرای بخشی از کد را متوقف می‌کند، اما Warning و Notice ممکن است فقط درباره یک مشکل احتمالی یا استفاده از روشی قدیمی هشدار دهند. در نسخه‌های جدید PHP، برخی کدهایی که قبلاً بدون مشکل اجرا می‌شدند، ممکن است پیام Deprecated ایجاد کنند.

• • Fatal Error: اجرای اسکریپت را متوقف می‌کند و معمولاً به صفحه سفید یا خطای جدی منجر می‌شود.
  • Warning: یک مشکل مهم را گزارش می‌کند، اما همیشه مانع ادامه اجرای کد نمی‌شود.
  • Notice: معمولاً یک هشدار توسعه‌دهنده درباره استفاده نادرست یا ناقص از متغیرهاست.
  • Deprecated: نشان می‌دهد بخشی از کد در نسخه‌های آینده PHP پشتیبانی نخواهد شد.

دلایل رایج ظاهرشدن خطاها

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

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

تنظیمات اصلی دیباگ وردپرس

WP_DEBUG چیست؟

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

WP_DEBUG_LOG و WP_DEBUG_DISPLAY

WP_DEBUG_LOG خطاها را در فایل wp-content/debug.log ثبت می‌کند. WP_DEBUG_DISPLAY نیز تعیین می‌کند پیام خطا در خروجی صفحه نمایش داده شود یا خیر. ترکیب پیشنهادی برای سایت اصلی این است که ثبت خطا فعال و نمایش آن غیرفعال باشد:

define( 'WP_DEBUG', true );

define( ‘WP_DEBUG_LOG’, true );

define( ‘WP_DEBUG_DISPLAY’, false );

@ini_set( ‘display_errors’, 0 );

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

/wp-content/debug.log

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

محل صحیح قرارگیری کد

کدهای دیباگ باید در فایل wp-config.php و قبل از خط زیر قرار بگیرند:

/* That's all, stop editing! Happy publishing. */

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

روش فعال‌سازی نمایش خطاهای PHP

فعال‌سازی از طریق فایل wp-config.php

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

define( 'WP_DEBUG', true );

define( ‘WP_DEBUG_LOG’, true );

define( ‘WP_DEBUG_DISPLAY’, true );

@ini_set( ‘display_errors’, 1 );

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

فعال‌سازی موقت برای بررسی یک مشکل

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

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

فعال‌سازی از طریق افزونه

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

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

روش غیرفعال‌سازی نمایش خطاهای PHP

غیرفعال‌کردن نمایش، بدون خاموش‌کردن لاگ

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

define( 'WP_DEBUG', true );

define( ‘WP_DEBUG_LOG’, true );

define( ‘WP_DEBUG_DISPLAY’, false );

@ini_set( ‘display_errors’, 0 );

در این حالت، خطاها در debug.log ذخیره می‌شوند، اما کاربر با پیام فنی مواجه نمی‌شود. این مدل برای فروشگاه‌ها، سایت‌های شرکتی و وب‌سایت‌هایی که اطلاعات کاربران را مدیریت می‌کنند، مناسب‌تر است.

خاموش‌کردن کامل دیباگ در محیط اصلی

اگر بررسی خطا به پایان رسیده و سایت پایدار است، می‌توانید دیباگ را کاملاً خاموش کنید:

define( 'WP_DEBUG', false );

define( ‘WP_DEBUG_LOG’, false );

define( ‘WP_DEBUG_DISPLAY’, false );

@ini_set( ‘display_errors’, 0 );

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

پاک‌سازی فایل لاگ

فایل debug.log ممکن است به‌مرور بزرگ شود و فضای هاست را اشغال کند. پس از دریافت گزارش، فایل را دانلود و آرشیو کنید و سپس محتوای غیرضروری را پاک کنید. برای سایت‌های پرترافیک، بهتر است از سیستم لاگ سرور یا ابزار مانیتورینگ استفاده شود تا فایل لاگ بدون کنترل رشد نکند.

کنترل خطاها از طریق تنظیمات PHP

تفاوت تنظیمات وردپرس و PHP

وردپرس فقط یکی از لایه‌های کنترل خطاست. تنظیمات اصلی PHP نیز می‌توانند نمایش خطا را محدود یا فعال کنند. مقادیری مانند display_errors، log_errors و error_reporting در فایل‌های پیکربندی PHP یا کنترل‌پنل هاست قابل مدیریت هستند.

تنظیمکاربردپیشنهاد برای سایت اصلیdisplay_errorsنمایش مستقیم خطا در خروجی صفحهOfflog_errorsثبت خطاها در فایل لاگ سرورOnerror_reportingتعیین نوع خطاهای قابل گزارشمطابق سیاست هاست و پروژهmemory_limitحداکثر حافظه قابل استفاده PHPبر اساس نیاز واقعی سایت

تغییر تنظیمات در کنترل‌پنل هاست

در کنترل‌پنل‌هایی مانند cPanel یا DirectAdmin معمولاً بخشی با عنوان Select PHP Version، PHP Options یا MultiPHP INI Editor وجود دارد. از این بخش می‌توانید display_errors را روی Off و log_errors را روی On قرار دهید.

اگر دسترسی لازم را ندارید، از پشتیبان هاست بخواهید وضعیت نمایش خطا و مسیر لاگ PHP را بررسی کند. توجه داشته باشید که تغییر این گزینه‌ها ممکن است روی تمام سایت‌های یک حساب میزبانی اثر بگذارد؛ بنابراین در هاست اشتراکی، با احتیاط عمل کنید.

چرا افزایش memory_limit همیشه راه‌حل نیست؟

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

اشتباهات رایج در مدیریت خطاهای وردپرس

نمایش خطا در سایت زنده

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

ویرایش مستقیم فایل بدون نسخه پشتیبان

فایل wp-config.php حساس است. قبل از هر تغییری، یک نسخه روی رایانه خود ذخیره کنید. اگر سایت بعد از ذخیره‌سازی با خطای ۵۰۰ یا صفحه سفید مواجه شد، نسخه قبلی را برگردانید و سپس کد را خط‌به‌خط بررسی کنید.

نادیده‌گرفتن خطاهای Deprecated

خطاهای Deprecated ممکن است امروز سایت را از کار نیندازند، اما نشانه‌ای از قدیمی‌بودن کد هستند. با ارتقای PHP یا وردپرس، همین کد می‌تواند به Warning یا Fatal Error تبدیل شود. چنین پیام‌هایی را در برنامه به‌روزرسانی قالب و افزونه قرار دهید.

پاک‌کردن لاگ به‌جای رفع مشکل

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

تأثیر نمایش خطا بر امنیت و سرعت سایت

ریسک‌های امنیتی

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

تأثیر بر تجربه کاربری و سئو

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

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

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

چک‌لیست عملی فعال‌سازی و غیرفعال‌سازی خطا

قبل از فعال‌سازی

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

هنگام بررسی خطا

• • به‌جای فعال‌کردن دائمی نمایش خطا، آن را کوتاه‌مدت روشن کنید.
  • فایل debug.log را از نظر زمان و تکرار خطا بررسی کنید.
  • افزونه‌ها را یکی‌یکی غیرفعال کنید؛ نه اینکه همه را هم‌زمان حذف کنید.
  • شماره خط و نام فایل را با نسخه فعلی قالب یا افزونه تطبیق دهید.
  • پس از هر تغییر، کش وردپرس، افزونه کش و کش سرور را بررسی کنید.

پس از رفع مشکل

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

در پروژه‌هایی که خطا به افزونه اختصاصی، اتصال API یا منطق پیچیده فروشگاه مربوط است، استفاده از پشتیبانی وردپرس می‌تواند زمان عیب‌یابی را کم کند. پشتیبانی مؤثر فقط خاموش‌کردن پیام نیست؛ باید علت، اثر خطا و راه جلوگیری از تکرار آن نیز مشخص شود.

سؤالات متداول

آیا فعال‌کردن WP_DEBUG برای سایت ضرر دارد؟

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

فایل debug.log در وردپرس کجا قرار دارد؟

در حالت استاندارد، این فایل در مسیر wp-content/debug.log ساخته می‌شود. اگر فایل وجود ندارد، فعال‌بودن WP_DEBUG_LOG، مجوز نوشتن پوشه و محدودیت‌های هاست را بررسی کنید.

چطور بدون نمایش خطا، آن را ثبت کنیم؟

مقادیر WP_DEBUG و WP_DEBUG_LOG را روی true و مقدار WP_DEBUG_DISPLAY را روی false قرار دهید. همچنین بهتر است display_errors در تنظیمات PHP خاموش باشد.

آیا خاموش‌کردن نمایش خطا مشکل سایت را رفع می‌کند؟

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

اگر بعد از تغییر wp-config.php سایت سفید شد چه کار کنیم؟

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

بهتر است خطاهای PHP را با افزونه مدیریت کنیم یا فایل wp-config.php؟

برای کنترل پایه و پایدار، ویرایش صحیح wp-config.php انتخاب مطمئن‌تری است. افزونه‌ها برای مشاهده ساده‌تر لاگ مناسب هستند، اما در زمان بروز خطای جدی یا اختلال مدیریتی ممکن است در دسترس نباشند.

جمع‌بندی

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

بهترین ترکیب برای بیشتر سایت‌های وردپرسی این است که WP_DEBUG و WP_DEBUG_LOG فعال باشند، WP_DEBUG_DISPLAY روی false قرار بگیرد و تنظیم display_errors نیز در PHP خاموش باشد. پس از رفع علت، لاگ را بررسی و پاک‌سازی کنید و عملکرد صفحات مهم را دوباره تست کنید. با این رویکرد، هم امنیت و اعتماد کاربر حفظ می‌شود و هم امکان عیب‌یابی حرفه‌ای از بین نمی‌رود.