رصد خطای جاوااسکریپت در وردپرس بدون افزونهٔ سنگین
در این مقاله می‌خوانید
سایت وردپرسی شما ده افزونه دارد، هر کدام جاوااسکریپت خودش را بارگذاری می‌کند، و هیچ‌کدام به دیگری خبر نمی‌دهد. تداخل بین آن‌ها رایج‌ترین علت این است که دکمه‌ای برای بخشی از کاربران کار نمی‌کند — و WP_DEBUG هیچ‌کدامشان را نشان نمی‌دهد، چون در مرورگر کاربر رخ می‌دهند نه روی سرور. اگر هنوز با کلیات خطای مرورگر آشنا نیستید، راهنمای جامع خطاهای جاوااسکریپت را ببینید.
این مقاله راه سبک پوشش دادن آن نیمه است.
چرا افزونهٔ سنگین راه‌حل نیست
وسوسه می‌شوید افزونه‌ای برای این کار نصب کنید. برای این کار خاص، معمولاً تصمیم بدی است:
- افزونه بیشتر یعنی احتمال تداخل بیشتر — و شما دارید ابزاری اضافه می‌کنید که قرار است مشکل ناشی از تعداد زیاد افزونه را حل کند.
- سرعت. هر افزونه در هر بارگذاری صفحه اجرا می‌شود.
- سطح حمله. افزونه‌های وردپرس رایج‌ترین مسیر نفوذ به سایت‌های وردپرسی‌اند.
چیزی که واقعاً لازم دارید یک تگ اسکریپت است. آن را می‌شود با چند خط کد اضافه کرد.
روش درست: قالب فرزند
اگر کد را مستقیم در functions.php قالب اصلی بنویسید، اولین به‌روزرسانی قالب پاکش می‌کند. قالب فرزند بسازید.
یک پوشه در wp-content/themes/ بسازید، مثلاً mytheme-child، و داخلش دو فایل:
style.css
/*
Theme Name: MyTheme Child
Template: mytheme
Version: 1.0.0
*/مقدار Template باید دقیقاً نام پوشهٔ قالب اصلی باشد.
functions.php
<?php
add_action('wp_enqueue_scripts', function () {
wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css');
});حالا قالب فرزند را فعال کنید. تنظیمات و محتوای شما دست‌نخورده می‌ماند.
افزودن اسکریپت رصد
در functions.php قالب فرزند:
add_action('wp_enqueue_scripts', function () {
if (is_admin()) return; // در پیشخوان لازم نیست
wp_enqueue_script(
'error-monitor',
'https://app.bugmug.ir/bugmug.js',
array(),
null,
false // در head، تا خطاهای زودهنگام هم دیده شوند
);
$init = "BugMug.init({ publicKey: 'pk_xxxxxxxx' });";
// اگر کاربر وارد شده، هویتش را ضمیمه کن تا گزارش‌ها ناشناس نباشند
if (is_user_logged_in()) {
$u = wp_get_current_user();
$init .= sprintf(
"BugMug.setUser({ id: %s, name: %s, email: %s });",
wp_json_encode($u->ID),
wp_json_encode($u->display_name),
wp_json_encode($u->user_email)
);
}
wp_add_inline_script('error-monitor', $init);
});سه نکته در این قطعه:
آرگومان آخر false است، یعنی اسکریپت در <head> بارگذاری می‌شود نه در فوتر. برای ابزار رصد خطا این مهم است: اگر در فوتر باشد، خطاهایی که پیش از آن رخ می‌دهند از دست می‌روند.
wp_json_encode برای همهٔ مقادیر، نه چسباندن مستقیم رشته. نام کاربری که آپاستروف داشته باشد، بدون این کار جاوااسکریپت صفحه را می‌شکند — و اگر نام از ورودی کاربر بیاید، مسیر تزریق اسکریپت هم هست.
wp_add_inline_script به‌جای echo. این تضمین می‌کند کد بعد از بارگذاری کتابخانه اجرا شود، نه قبلش.
ووکامرس: نکتهٔ اضافه
در فروشگاه، ارزشمندترین اطلاعات این است که بدانید خطا در کدام مرحله رخ داده:
if (function_exists('is_checkout') && is_checkout()) {
$init .= "BugMug.addMetadata('stage', 'checkout');";
} elseif (function_exists('is_cart') && is_cart()) {
$init .= "BugMug.addMetadata('stage', 'cart');";
}حالا در داشبورد می‌توانید خطاهای صفحهٔ پرداخت را جدا ببینید — که تقریباً همیشه فوری‌ترین دسته‌اند.
کدام افزونه‌ها بیشتر تداخل می‌سازند
وقتی خطاها شروع به آمدن کردند، الگوهایی می‌بینید که در سایت‌های وردپرسی تکرار می‌شوند:
چند نسخه از jQuery. رایج‌ترین علت. افزونه‌ای نسخهٔ خودش را بارگذاری می‌کند و افزونهٔ دیگری که به نسخهٔ وردپرس تکیه کرده، می‌شکند. نشانه‌اش خطاهایی مثل $ is not a function یا x is not a function روی متدهای jQuery است.
افزونه‌های بهینه‌سازی. ادغام و کوچک‌سازی فایل‌های جاوااسکریپت، اگر ترتیب وابستگی‌ها را به‌هم بزند، خطاهایی می‌سازد که فقط روی سایت زنده رخ می‌دهند و در حالت توسعه نه. اگر خطاها درست بعد از فعال کردن افزونهٔ کش شروع شدند، اول گزینهٔ «ترکیب فایل‌های JS» را خاموش کنید.
صفحه‌سازها. جاوااسکریپت زیادی تزریق می‌کنند و با افزونه‌های فرم و اسلایدر تداخل رایجی دارند.
درگاه‌های پرداخت. کم‌تعدادترین ولی پرهزینه‌ترین، چون دقیقاً در آخرین قدم خرید رخ می‌دهند.
پیدا کردن مقصر از روی داده
وقتی خطاها ثبت می‌شوند، معمولاً لازم نیست حدس بزنید. در stack trace به مسیر فایل نگاه کنید:
at /wp-content/plugins/some-slider/js/slider.min.js:2:1843نام پوشه در مسیر plugins/، مستقیم می‌گوید کدام افزونه. این تنها تفاوت بین «سایت گاهی خراب می‌شود» و «افزونهٔ فلان روی صفحهٔ تسویه خطا می‌دهد» است.
مراقب کش باشید
افزونه‌های کش صفحات را به‌صورت HTML ثابت ذخیره می‌کنند. اگر کاربر وارد شده باشد ولی صفحهٔ کش‌شده به او داده شود، ممکن است setUser با اطلاعات کاربر دیگری اجرا شود.
بیشتر افزونه‌های کش برای کاربران وارد شده کش را غیرفعال می‌کنند و مشکلی پیش نمی‌آید. ولی اگر تنظیمات خاصی دارید، این را حتماً بررسی کنید — نشتی هویت بین کاربران، مشکل جدی‌تری از یک باگ معمولی است.
حریم خصوصی
اگر ویجت گزارش باگ با اسکرین‌شات فعال است، مسئولیت هم می‌آید:
- فیلدهای رمز عبور به‌صورت خودکار محو می‌شوند.
- فیلدهای حساس دیگر را خودتان علامت بزنید:
<input data-bug-mask>— مثلاً شمارهٔ کارت، کد ملی، شمارهٔ تماس. - در صفحهٔ حریم خصوصی سایتتان به این موضوع اشاره کنید.
آزمون نهایی
بعد از نصب، این را در کنسول مرورگر روی سایتتان اجرا کنید:
throw new Error('تست نصب');ظرف چند ثانیه باید در داشبورد ظاهر شود. اگر نشد، سه چیز را چک کنید: کلید عمومی درست است، دامنهٔ سایت در فهرست مجاز پروژه هست، و افزونهٔ کش نسخهٔ قدیمی صفحه را نمی‌دهد.
جمع‌بندی
سایت وردپرسی دو نیمه دارد و هر نیمه ابزار خودش را می‌خواهد: WP_DEBUG برای PHP، و ثبت خطای مرورگر برای جاوااسکریپت. تیم‌هایی که فقط اولی را دارند، دقیقاً همان دسته از مشکلات را نمی‌بینند که کاربر بیشتر با آن‌ها روبه‌رو می‌شود — چون تجربهٔ کاربر در وردپرس امروزی عمدتاً در مرورگر ساخته می‌شود. تنظیم امن نیمهٔ PHP را در WP_DEBUG: دیباگ حرفه‌ای وردپرس آورده‌ایم.
و برای این کار به افزونهٔ دیگری نیاز ندارید؛ چند خط در قالب فرزند کافی است.
منابع و مطالعهٔ بیشتر
- قالب فرزند در وردپرس — مستندات رسمی
- wp_enqueue_script — افزودن اسکریپت به روش استاندارد
- wp_add_inline_script — کد درون‌خطی بعد از بارگذاری کتابخانه
- Conditional Tags در ووکامرس — تشخیص صفحهٔ تسویه و سبد
باگ‌ماگ را رایگان امتحان کنید
خطاهای سایتتان را خودکار ثبت کنید و بگذارید کاربران با یک کلیک باگ گزارش دهند.
شروع رایگان