Debug کردن وردپرس به سبک حرفه‌ای‌ها

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

کاری که تقریباً همه در این لحظه انجام می‌دن اینه که با عجله می‌رن سراغ FTP و شروع می‌کنن به غیرفعال کردن افزونه‌ها، عوض کردن قالب و برگردوندن تغییرات. گاهی جواب می‌ده و گاهی وضع رو بدتر می‌کنه؛ چون وقتی هم‌زمان پنج تا چیز رو عوض کنید و سایت درست بشه، هیچ‌وقت نمی‌فهمید کدومش مشکل داشته و هفته‌ی بعد دوباره همون اتفاق می‌افته.

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

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

قبل از هر چیز، یک روش به شما می‌دهم

ابزارها مهمن، اما روش مهم‌تره. تقریباً هر مشکلی در وردپرس با همین چهار قدم قابل حله و ترتیبشون اهمیت داره.

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

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

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

چهار: بعد از رفع، تأیید کنید. کش رو پاک کنید، در حالت ناشناس تست کنید و مطمئن بشید واقعاً حل شده، نه اینکه فقط موقتاً پنهون شده باشه.

حالا با این ذهنیت، بریم سراغ ابزارها.

قدم صفر: چیزی را خراب‌تر نکنید

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

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

ابزار اصلی: حالت اشکال‌زدایی وردپرس

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

برای فعال کردنش فایل wp-config.php رو در پوشه‌ی اصلی وردپرس باز کنید و بالای خطی که نوشته /* That's all, stop editing! */ این خط‌ها رو اضافه کنید:

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

حالا بذارید توضیح بدم چرا این ترکیب و نه فقط خط اول.

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

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

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

یک هشدار امنیتی که تقریباً هیچ‌جا گفته نمی‌شود

فایل debug.log به‌صورت پیش‌فرض در پوشه‌ی wp-content ساخته می‌شه و این پوشه از طریق مرورگر قابل دسترسیه. یعنی هر کسی که آدرس فایل رو حدس بزنه، می‌تونه محتوای کامل لاگ خطاهای سایت شما رو بخونه؛ با تمام مسیرها و جزئیات فنی.

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

define( 'WP_DEBUG_LOG', '/home/user/private/wp-errors.log' );

وردپرس از نسخه‌ی ۵.۱ به بعد اجازه می‌ده به‌جای true، مستقیماً مسیر دلخواه بدید.

وقتی خطاها فقط در فایل‌های فشرده پنهان شده‌اند

وردپرس برای سرعت بیشتر، از نسخه‌ی فشرده‌شده‌ی فایل‌های CSS و جاوااسکریپت خودش استفاده می‌کنه. مشکل اینه که وقتی خطایی در جاوااسکریپت رخ می‌ده، کنسول مرورگر بهتون می‌گه خطا در خط ۱ ستون ۴۸۲۰۰ اتفاق افتاده که عملاً هیچ کمکی نمی‌کنه.

راه‌حل، فعال کردن این ثابته:

define( 'SCRIPT_DEBUG', true );

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

وقتی مشکل از دیتابیس است

اینجا باید یه اشتباه رایج رو تصحیح کنم. قبلا میگفتن که برای دیدن خطاهای دیتابیس باید فایل wp-includes/wp-db.php رو باز کنید و مقدار $show_errors رو دستی به true تغییر بدید.

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

راه درست اینه که در فایل wp-config.php این خط رو اضافه کنید:

define( 'SAVEQUERIES', true );

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

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

خیلی از مقالات دیباگ هنوز طوری نوشته شدن که انگار وردپرس همون نسخه‌ی چند سال پیشه. اما وردپرس مدتیه دو تا ابزار داخلی خیلی مفید اضافه کرده.

سلامت سایت

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

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

حالت بازیابی

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

با اون لینک می‌تونید وارد پیشخوان بشید (در حالی که بازدیدکننده‌ها همچنان سایت سالم رو می‌بینن)، افزونه‌ی مقصر رو ببینید و حذف یا اصلاحش کنید. یعنی دیگه لازم نیست با FTP وارد سرور بشید و پوشه‌ی افزونه‌ها رو دستی تغییر نام بدید.

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

Query Monitor؛ ابزاری که هر کسی باید بشناسد

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

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

اون ستون «کدوم افزونه» چیزیه که معمولاً کل ماجرا رو حل می‌کنه. وقتی می‌بینید یه صفحه ۸۰۰ کوئری داره و ۶۰۰ تاش از یه افزونه‌ی خاص میاد، دیگه لازم نیست حدس بزنید.

Query Monitor رو روی سایت زنده فعال بذارید مشکلی نداره چون خروجیش فقط برای مدیر نمایش داده می‌شه، اما اگه لازمش ندارید بهتره غیرفعالش کنید تا بار اضافی به سایت وارد نکنه.

و افزونه‌ی Health Check

یه افزونه‌ی رسمی دیگه هم هست به اسم Health Check & Troubleshooting که یه قابلیت فوق‌العاده داره: حالت عیب‌یابی. در این حالت، افزونه‌ها و قالب فقط برای شما غیرفعال می‌شن و بازدیدکننده‌های سایت همچنان نسخه‌ی عادی رو می‌بینن.

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

مشکل همیشه از PHP نیست

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

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

تب Network هم برای مواقعی که چیزی بارگذاری نمی‌شه عالیه؛ فایل‌هایی که با خطای ۴۰۴ یا ۵۰۰ برگشتن رو با قرمز نشون می‌ده.

و در نهایت، لاگ‌های سرور

گاهی خطا حتی به وردپرس نمی‌رسه؛ سرور قبل از اجرای وردپرس متوقف می‌شه و در این حالت debug.log خالی می‌مونه. اینجا باید سراغ لاگ خود سرور برید.

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

کش؛ دشمن پنهان عیب‌یابی

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

برای همین یه قانون ساده بذارید: بعد از هر تغییر، قبل از تست، کش رو پاک کنید. هم کش افزونه، هم کش CDN و هم کش مرورگر با Ctrl + F5. تست کردن در حالت ناشناس مرورگر هم عادت خوبیه چون خیلی از متغیرها رو حذف می‌کنه.

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

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

از کجا شروع کنیم؟ راهنمای سریع خطاهای رایج

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

کارهایی که نباید انجام بدید

چند تا اشتباه هست که در آموزش‌های قدیمی زیاد دیده می‌شن و ارزش داره صریح بگم ازشون دوری کنید.

فایل‌های هسته‌ی وردپرس رو ویرایش نکنید؛ نه wp-db.php، نه هیچ فایل دیگه‌ای در پوشه‌های wp-includes و wp-admin. هر تغییری اونجا با اولین آپدیت از بین می‌ره.

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

بعد از تموم شدن کار، ثابت‌های دیباگ رو خاموش و فایل لاگ رو حذف کنید. سایت‌های زیادی هست که سال‌هاست یه debug.log چند مگابایتی قابل دسترس عمومی دارن.

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

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

جمع‌بندی

تفاوت اصلی بین کسی که ساعت‌ها با یه خطا کلنجار می‌ره و کسی که در ده دقیقه حلش می‌کنه، دانش فنی بیشتر نیست؛ روش داشتنه. مشکل رو دوباره تولید کنید، بازه رو نصف کنید، هر بار فقط یک چیز رو عوض کنید و در آخر تأیید کنید که واقعاً حل شده.

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

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

تیم تولید محتوا

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