ساخت سیستم‌های گزارش‌دهی خطای پیشرفته و لاگینگ سفارشی در وردپرس: سئو و پرفورمنس پایدار

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

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

بچه‌ها دقت کنید، همه ما می‌دونیم که وردپرس عالیه، اما مثل هر سیستم پیچیده دیگه‌ای، ممکنه با خطاها و مشکلات پنهان دست و پنجه نرم کنه. این خطاها، چه سمت بک‌اند (PHP) باشن و چه سمت فرانت‌اند (JavaScript)، می‌تونن مستقیماً روی سئو، تجربه کاربری (UX) و سرعت سایت شما تاثیر بذارن و حتی باعث شن ربات‌های گوگل به سایت‌تون اخم کنن!

من توی پروژه‌هام بارها دیدم که یه خطای PHP کوچیک یا یه باگ جاوااسکریپت که شاید کاربر عادی اصلا متوجهش نشه، چطور می‌تونه بودجه خزش (Crawl Budget) گوگل رو هدر بده یا باعث بشه Core Web Vitals سایت به هم بریزه. اینجاست که دید فول‌استک به کار میاد و به ما یاد میده چطور از همون اول، زیرساخت سایت رو طوری بچینیم که هیچ خطایی از دیدمون پنهان نمونه.

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

چرا WP_DEBUG به تنهایی برای متخصصان فول‌استک کافی نیست؟

مطمئنم همه شما با WP_DEBUG آشنا هستید. وقتی توی فایل wp-config.php این کد رو فعال می‌کنیم، وردپرس خطاها رو روی صفحه نمایش میده یا توی فایل debug.log ثبت می‌کنه:

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

این خیلی خوبه، اما کافی نیست! WP_DEBUG فقط به شما میگه که خطا کجا اتفاق افتاده، اما معمولاً اطلاعات عمیق‌تری مثل:

• چه کاربری اون خطا رو دیده؟
• چه کوئری دیتابیسی قبلش اجرا شده؟
• چه صفحاتی تحت تاثیر قرار گرفتن؟
• آیا این خطا فقط یک بار رخ داده یا مرتباً تکرار میشه؟

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

تاثیر فول‌استک خطاهای پنهان بر سئو و پرفورمنس

رفقا، هر خطایی که روی سایت شما اتفاق میفته، حتی اگه کاربر نبینتش، می‌تونه مثل یه سُم آهسته عمل کنه:

• سئو (SEO):

  • کاهش Crawlability: ربات‌های گوگل وقتی با خطای PHP یا JS روبرو میشن، ممکنه نتونن محتوای صفحه رو درست بخونن یا اصلا صفحه رو نادیده بگیرن.
  • تجربه کاربری ضعیف: خطاهای فرانت‌اند (مثل ارورهای جاوااسکریپت) می‌تونن باعث بشن بخش‌هایی از سایت کار نکنه یا لود نشه که مستقیم روی Core Web Vitals تاثیر منفی داره. گوگل عاشق تجربه کاربری عالیه!
  • لینک‌های خراب و محتوای ناقص: خطاها می‌تونن منجر به نمایش محتوای ناقص یا شکستن لینک‌های داخلی بشن که برای سلسله مراتب محتوا و ناوبری داخلی فاجعه‌ست.

• پرفورمنس (Performance):

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

ساخت هندلر خطای سفارشی (PHP): فوت کوزه‌گری

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

کد زیر رو می‌تونید به فایل functions.php قالب یا یه افزونه اختصاصی اضافه کنید (ترجیحاً افزونه، چون با تغییر قالب از بین نمیره):

<?php

// تابع هندلر خطای سفارشی
function my_custom_error_handler( $errno, $errstr, $errfile, $errline ) {
 // فیلتر کردن خطاهای قابل اغماض
 if ( !( error_reporting() & $errno ) ) {
 return false; 
 }

 // ساختاردهی اطلاعات خطا
 $error_data = [
 'timestamp' => current_time( 'mysql' ),
 'type' => $errno,
 'message' => $errstr,
 'file' => $errfile,
 'line' => $errline,
 'request_uri' => $_SERVER['REQUEST_URI'] ?? 'N/A',
 'ip_address' => $_SERVER['REMOTE_ADDR'] ?? 'N/A',
 'user_agent' => $_SERVER['HTTP_USER_AGENT'] ?? 'N/A',
 'backtrace' => debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS ), // برای جزئیات بیشتر
 ];

 // تبدیل backtrace به رشته قابل ذخیره
 $error_data['backtrace'] = json_encode( $error_data['backtrace'] );

 // *فوت کوزه‌گری*: ذخیره خطا در دیتابیس یا فایل اختصاصی
 // روش 1: ذخیره در فایل لاگ اختصاصی (ساده‌تر برای شروع)
 $log_file = WP_CONTENT_DIR . '/uploads/custom-error-log.log';
 file_put_contents( $log_file, json_encode( $error_data ) . "\n", FILE_APPEND );

 // روش 2: ذخیره در دیتابیس (پیچیده‌تر اما قدرتمندتر برای تحلیل)
 // global $wpdb;
 // $wpdb->insert( $wpdb->prefix . 'custom_errors', $error_data );

 // از اجرای هندلر خطای پیش‌فرض PHP جلوگیری می‌کنیم
 return true;
}

// ثبت هندلر سفارشی ما
set_error_handler( 'my_custom_error_handler' );

// (اختیاری) ثبت هندلر استثنا (Exception Handler)
function my_custom_exception_handler( $exception ) {
 $error_data = [
 'timestamp' => current_time( 'mysql' ),
 'type' => 'Exception',
 'message' => $exception->getMessage(),
 'file' => $exception->getFile(),
 'line' => $exception->getLine(),
 'request_uri' => $_SERVER['REQUEST_URI'] ?? 'N/A',
 'ip_address' => $_SERVER['REMOTE_ADDR'] ?? 'N/A',
 'user_agent' => $_SERVER['HTTP_USER_AGENT'] ?? 'N/A',
 'backtrace' => json_encode( $exception->getTrace() ),
 ];
 $log_file = WP_CONTENT_DIR . '/uploads/custom-error-log.log';
 file_put_contents( $log_file, json_encode( $error_data ) . "\n", FILE_APPEND );
}
set_exception_handler( 'my_custom_exception_handler' );

// غیرفعال کردن نمایش خطاهای پیش‌فرض برای امنیت
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

این کد، خطاها رو با جزئیاتی مثل URI درخواستی، آدرس IP کاربر و User Agent به یه فایل لاگ اختصاصی (custom-error-log.log) اضافه می‌کنه. با این اطلاعات، می‌تونید بفهمید چه کاربرانی با چه مشکلاتی روبرو میشن و کدوم بخش از سایت بیشتر خطا میده. این دقیقا همون چیزیه که برای مانیتورینگ سئو در لحظه نیاز داریم.

لاگینگ رویدادهای خاص (Special Event Logging)

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

<?php

function my_custom_event_logger( $event_name, $data = [] ) {
 $log_data = [
 'timestamp' => current_time( 'mysql' ),
 'event' => $event_name,
 'details' => $data,
 'request_uri' => $_SERVER['REQUEST_URI'] ?? 'N/A',
 ];
 $log_file = WP_CONTENT_DIR . '/uploads/custom-event-log.log';
 file_put_contents( $log_file, json_encode( $log_data ) . "\n", FILE_APPEND );
}

// مثال استفاده: لاگ کردن زمان اجرای یک تابع
// add_action( 'init', function() {
// $start_time = microtime(true);
// // کد سنگین شما اینجا
// $end_time = microtime(true);
// my_custom_event_logger( 'heavy_function_execution', ['duration' => ($end_time - $start_time)] );
// });

با این تابع، می‌تونید هر جایی از کدتون که شک دارید ممکنه مشکلی ایجاد کنه، لاگ‌های سفارشی بذارید. مثلاً وقتی دارید معماری دیتابیس ووکامرس رو بهینه‌سازی می‌کنید، می‌تونید اجرای کوئری‌های پیچیده رو لاگ کنید تا bottlenecks رو شناسایی کنید.

اتصال خطاهای فرانت‌اند به لاگ‌های بک‌اند (JavaScript)

خطاهای جاوااسکریپت هم به اندازه خطاهای PHP خطرناکن! این خطاها می‌تونن تجربه کاربری رو نابود کنن و گوگل هم به سایت‌هایی با خطاهای JS زیاد رتبه خوبی نمیده. با یه رویکرد فول‌استک، ما این خطاها رو هم به سرور می‌فرستیم تا توی همون سیستم لاگینگ PHP ثبت بشن.

قدم اول: یه فایل JS ایجاد کنید و این کد رو بهش اضافه کنید:

// my-custom-error-reporter.js
window.onerror = function( message, source, lineno, colno, error ) {
 // ارسال اطلاعات خطا به سرور از طریق AJAX
 var xhr = new XMLHttpRequest();
 xhr.open( 'POST', ajaxurl, true ); // ajaxurl از وردپرس میاد
 xhr.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );
 xhr.send(
 'action=log_frontend_error' +
 '&message=' + encodeURIComponent( message ) +
 '&source=' + encodeURIComponent( source ) +
 '&lineno=' + encodeURIComponent( lineno ) +
 '&colno=' + encodeURIComponent( colno ) +
 (error ? '&stack=' + encodeURIComponent( error.stack ) : '')
 );
 return false; // از نمایش خطای پیش‌فرض مرورگر جلوگیری می‌کند
};

قدم دوم: این فایل JS رو توی وردپرس enqueue کنید و یه اکشن AJAX برای دریافت خطاها توی functions.php اضافه کنید:

<?php

// Enqueue کردن فایل JavaScript
function enqueue_custom_error_reporter_script() {
 wp_enqueue_script(
 'custom-error-reporter',
 get_stylesheet_directory_uri() . '/my-custom-error-reporter.js',
 array( 'jquery' ), // نیاز به jQuery اگر استفاده می‌کنید
 null, 
 true
 );
 // متغیر ajaxurl رو برای JS فراهم می‌کنیم
 wp_localize_script( 'custom-error-reporter', 'ajaxurl', admin_url( 'admin-ajax.php' ) );
}
add_action( 'wp_enqueue_scripts', 'enqueue_custom_error_reporter_script' );

// هندلر AJAX برای دریافت خطاهای فرانت‌اند
function log_frontend_error_callback() {
 $error_data = [
 'timestamp' => current_time( 'mysql' ),
 'type' => 'Frontend_JS_Error',
 'message' => sanitize_text_field( $_POST['message'] ?? '' ),
 'source' => sanitize_url( $_POST['source'] ?? '' ),
 'lineno' => intval( $_POST['lineno'] ?? 0 ),
 'colno' => intval( $_POST['colno'] ?? 0 ),
 'stack' => sanitize_textarea_field( $_POST['stack'] ?? '' ),
 'request_uri' => $_SERVER['HTTP_REFERER'] ?? 'N/A',
 'ip_address' => $_SERVER['REMOTE_ADDR'] ?? 'N/A',
 'user_agent' => $_SERVER['HTTP_USER_AGENT'] ?? 'N/A',
 ];

 $log_file = WP_CONTENT_DIR . '/uploads/custom-error-log.log'; // یا دیتابیس
 file_put_contents( $log_file, json_encode( $error_data ) . "\n", FILE_APPEND );
 
 wp_die(); // حتماً wp_die() را صدا بزنید تا درخواست AJAX بسته شود
}
add_action( 'wp_ajax_log_frontend_error', 'log_frontend_error_callback' );
add_action( 'wp_ajax_nopriv_log_frontend_error', 'log_frontend_error_callback' );

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

فوت کوزه‌گری نهایی: تحلیل و اقدام بر اساس لاگ‌ها

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

1. الگوها رو پیدا کنید: آیا خطای خاصی هست که مدام تکرار بشه؟ این نشون میده یه مشکل اساسی توی کد، افزونه یا قالب شما وجود داره.
2. تاثیر رو بسنجید: آیا خطاها روی صفحات مهم (مثلاً صفحات محصول یا لندینگ پیج‌ها) اتفاق میفتن؟ این‌ها اولویت بالاتری دارن.
3. منبع رو ردیابی کنید: با کمک backtrace و اطلاعات file و line، دقیقا می‌تونید بفهمید مشکل از کجای کدتون شروع میشه.
4. با ابزارهای مانیتورینگ ادغام کنید: می‌تونید این لاگ‌ها رو به ابزارهای مانیتورینگ خارجی مثل Kibana, Grafana یا حتی Google Data Studio وصل کنید تا داشبوردهای تصویری بسازید و آلارم‌های خودکار برای خطاهای بحرانی تنظیم کنید. این دقیقا همون چیزیه که توی مقاله ابزارهای هوش مصنوعی برای Observability و مانیتورینگ پیشرفته در وردپرس بهش اشاره شد.

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

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