هوک‌های وردپرس در توسعه افزونه چه کاربردی دارند

«افزونه‌ام کار می‌کند، ولی هیچ‌جا دیده نمی‌شود» — این جمله را در سال‌های گذشته چند بار از توسعه‌دهندگانی شنیده‌ام که تازه پا به دنیای افزونه‌نویسی وردپرس گذاشته‌اند. کدشان از نظر syntax درست است، لاگ خطایی ندارد، پوشه‌اش هم سر جای خودش نشسته، ولی هیچ اتفاقی در سایت نمی‌افتد. تجربه‌ام می‌گوید در ۹۰ درصد این پرونده‌ها، مشکل در یک چیز مشترک خلاصه می‌شود: هوک‌ها. افزونه‌ای که به هوک درست متصل نشده باشد، مثل نجاری است که تمام ابزارش را دارد ولی در خانهٔ مشتری را پیدا نکرده. تفاوت بین افزونه‌ای که «فقط نصب شده» و افزونه‌ای که «کار می‌کند»، تقریباً همیشه در کیفیت این اتصال است. اگر تازه با مفهوم هوک آشنا شده‌اید، پیش از ادامه پیشنهاد می‌کنم هوک‌های وردپرس چیستند و چگونه کار می‌کنند را بخوانید؛ در این مقاله فرض می‌کنم با تعریف پایهٔ Action و Filter آشنایید و می‌خواهیم ببینیم این مفهوم در مقیاس یک افزونهٔ واقعی چه معنایی پیدا می‌کند.

چرا هوک، ستون فقرات هر افزونه است؟

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

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

افزونهٔ حرفه‌ای، کد هسته را دست نمی‌زند؛ با آن حرف می‌زند. هرجا مجبور شدید فایل هسته را ویرایش کنید، بدانید که یک هوک را پیدا نکرده‌اید.

Action یا Filter؟ تصمیم روزمرهٔ افزونه‌نویس

پیش از غرق‌شدن در جزئیات، یک بار دیگر تفاوت این دو را با تمرکز روی کاربردشان در افزونه‌نویسی مرور کنیم؛ چون تجربه نشان داده همین سؤال ساده، شایع‌ترین جای سکندری‌خوردن توسعه‌دهنده‌های تازه‌کار است. Action زمانی است که شما می‌خواهید «کاری انجام دهید» — مثلاً هنگام فعال‌سازی افزونه، یک جدول دیتابیس بسازید یا یک پیام به مدیر بفرستید. Filter زمانی است که می‌خواهید «داده‌ای را تغییر دهید» — مثلاً طول خلاصهٔ نوشته‌ها را کم کنید یا یک متن را قبل از نمایش روی صفحه جایگزین کنید. تفاوت عملی این دو، در یک جمله: Action چیزی برنمی‌گرداند، Filter همیشه باید مقدار ورودی را (تغییریافته یا دست‌نخورده) برگرداند. اگر این تفکیک برایتان تازگی دارد، مقالهٔ تفاوت Action و Filter در وردپرس چیست را کامل بخوانید؛ آنجا با مثال‌های بیشتر باز شده است.

در کار روزمرهٔ افزونه‌نویسی، این تفکیک به‌سرعت به یک بازتاب تبدیل می‌شود: هر وقت در ذهنتان جمله‌ای با «بعد از X، کار Y را انجام بده» شکل گرفت، سراغ Action می‌روید؛ و هر وقت جمله با «مقدار X را به Y تبدیل کن» شکل گرفت، سراغ Filter. برای آشنایی با پرکاربردترین‌های هر دسته، دو مقالهٔ مهم‌ترین Action Hook های وردپرس و مهم‌ترین Filter Hook های وردپرس مرجع‌های خوبی هستند؛ من هم در پروژه‌های خودم فهرست کوتاهی از آن‌ها را همیشه کنار دستم نگه می‌دارم.

چرخهٔ حیات افزونه و هوک‌هایی که واقعاً به کار می‌آیند

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

ایستگاه صفر: فعال‌سازی و غیرفعال‌سازی

دو هوک ویژه در همان لحظهٔ نصب، کارهای ساختاری افزونه را انجام می‌دهند: register_activation_hook و register_deactivation_hook. در پروژه‌هایی که جدول اختصاصی می‌سازند یا نقش کاربری جدید اضافه می‌کنند، این دو نقطهٔ شروع هستند. تجربه‌ام این است که خیلی از افزونه‌های آماتور این ایستگاه را جدی نمی‌گیرند و همان‌جا بذر مشکلات آینده را می‌کارند؛ چون در فعال‌سازی، هیچ‌وقت نباید فرض کنید وردپرس در حال آماده‌سازی صفحات است — آن‌جا فقط باید کارهای ساختاری نصب انجام شود.

ایستگاه یک: بوت‌شدن افزونه با plugins_loaded

پس از اینکه همهٔ افزونه‌های فعال خوانده شدند، وردپرس هوک plugins_loaded را صدا می‌زند. این نقطه، جای درست برای مقداردهی اولیهٔ افزونه است — بستن کلاس‌ها، ثبت hook handler‌ها، بارگذاری فایل‌های زبان. اگر افزونه‌تان وابسته به وجود افزونهٔ دیگری است (مثلاً یک افزونهٔ جانبی ووکامرس که فقط در حضور ووکامرس معنا دارد)، این هوک بهترین جای بررسی است.

ایستگاه دو: هستهٔ اجرا با init

هوک init پرکاربردترین هوک Action در افزونه‌نویسی است. در این نقطه، وردپرس کاربر جاری، تنظیمات و انواع نوشته را می‌شناسد ولی هنوز شروع به رندر خروجی نکرده. هر چیزی که به ثبت نوع نوشتهٔ سفارشی، تاکسونومی، شورت‌کد و نقطهٔ ورود REST مربوط است، جای طبیعی‌اش همین‌جاست. یکی از اشتباه‌های رایج این است که توسعه‌دهنده‌ها کارهای سنگین (مثلاً کوئری به دیتابیس برای آماری) را هم داخل init می‌گذارند؛ در حالی که این هوک در هر درخواست اجرا می‌شود و کارهای سنگین باید به هوک‌های دقیق‌تری مثل wp_loaded یا حتی رویدادهای cron منتقل شوند.

ایستگاه سه: پیشخوان و front-end

اینجا افزونه واقعاً زندگی می‌کند. برای پیشخوان، هوک‌هایی مثل admin_menu (برای افزودن منوی اختصاصی)، admin_enqueue_scripts (برای بارگذاری فایل‌های CSS/JS پیشخوان) و admin_init (برای بررسی فرم‌ها و ذخیره‌سازی تنظیمات) وارد میدان می‌شوند. برای front-end، جفت‌های wp_enqueue_scripts، wp_head و wp_footer هر روز در افزونه‌های من تکرار می‌شوند.

یک افزونهٔ کوچک با پنج هوک: پیاده‌سازی گام‌به‌گام

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

<?php
/**
 * Plugin Name: Related Post Box
 * Description: نمایش کادر مطلب مرتبط در انتهای نوشته‌ها
 * Version: 1.0.0
 * Author: WordPressKar
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit; // جلوگیری از دسترسی مستقیم فایل
}

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

هوک اول: ثبت فعال‌سازی و پیش‌فرض‌ها

register_activation_hook( __FILE__, 'wphooks_rpb_activate' );

function wphooks_rpb_activate() {
    // در آینده اینجا جدول یا ردیف‌های اولیه ساخته می‌شود
    if ( ! get_option( 'wphooks_rpb_count' ) ) {
        add_option( 'wphooks_rpb_count', 3 );
    }
}

هوک دوم: بوت‌شدن افزونه

add_action( 'plugins_loaded', 'wphooks_rpb_bootstrap' );

function wphooks_rpb_bootstrap() {
    load_plugin_textdomain(
        'wphooks-rpb',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages'
    );
}

هوک سوم: بارگذاری استایل‌ها در front-end

add_action( 'wp_enqueue_scripts', 'wphooks_rpb_assets' );

function wphooks_rpb_assets() {
    if ( ! is_singular( 'post' ) ) {
        return;
    }
    wp_enqueue_style(
        'wphooks-rpb-style',
        plugins_url( 'assets/style.css', __FILE__ ),
        array(),
        '1.0.0'
    );
}

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

هوک چهارم: افزودن محتوا با Filter روی the_content

add_filter( 'the_content', 'wphooks_rpb_append_box' );

function wphooks_rpb_append_box( $content ) {
    if ( ! is_singular( 'post' ) || ! in_the_loop() || ! is_main_query() ) {
        return $content;
    }

    $related = wphooks_rpb_get_related();
    if ( empty( $related ) ) {
        return $content;
    }

    $box  = '<aside class="rpb-box"><h3>مطالب مرتبط</h3><ul>';
    foreach ( $related as $post_obj ) {
        $box .= '<li><a href="' . esc_url( get_permalink( $post_obj ) ) . '">'
              . esc_html( get_the_title( $post_obj ) ) . '</a></li>';
    }
    $box .= '</ul></aside>';

    return $content . $box;
}

چند نکتهٔ کلیدی در همین تکهٔ کوچک: شرط‌های is_singular و in_the_loop از اجرای بی‌مورد روی آرشیوها جلوگیری می‌کنند، و استفاده از esc_url و esc_html هم بیمه‌نامهٔ امنیتی این نمایش است. اگر می‌خواهید روی چرایی این پاک‌سازی‌ها بیشتر بدانید، مبحث «خروج امن» در هوک‌های وردپرس و افزایش امنیت کد را ببینید.

هوک پنجم: تعریف هوک سفارشی برای دیگران

function wphooks_rpb_get_related() {
    $categories = wp_get_post_categories( get_the_ID() );
    $query_args = array(
        'post__not_in'   => array( get_the_ID() ),
        'posts_per_page' => (int) apply_filters( 'wphooks_rpb_count', get_option( 'wphooks_rpb_count', 3 ) ),
        'category__in'   => $categories,
    );

    /**
     * امکان بازنویسی کوئری مطلب مرتبط توسط سایر افزونه‌ها
     */
    $query_args = apply_filters( 'wphooks_rpb_query_args', $query_args );

    return get_posts( $query_args );
}

این آخرین تکه، از نظر معماری مهم‌ترین است: خودِ افزونه با apply_filters دو درِ باز برای توسعه‌دهنده‌های دیگر ایجاد کرده — یکی برای تغییر تعداد مطالب (wphooks_rpb_count) و یکی برای تغییر کل کوئری (wphooks_rpb_query_args). همین یک تصمیم کوچک، افزونه را از «قطعه‌ای بسته» به «بلوک سازنده» تبدیل می‌کند و اجازه می‌دهد در قالب پروژه، بدون دست زدن به فایل افزونه، رفتارش را سفارشی کنید. مقالهٔ ساخت قابلیت اختصاصی با هوک‌های وردپرس این الگو را در مقیاس بزرگ‌تر باز کرده است.

هر افزونه‌ای که خودش هوک سفارشی معرفی می‌کند، به مشتری و توسعه‌دهندهٔ آینده، دو هدیهٔ رایگان می‌دهد: امکان توسعهٔ بدون دست‌کاری، و امکان همکاری بدون تعارض.

مدیریت اولویت: وقتی ترتیب اجرا سرنوشت‌ساز می‌شود

تصور کنید افزونهٔ شما روی the_content چیزی اضافه می‌کند و افزونهٔ دیگری هم که در همان سایت فعال است، همان هوک را با اولویت پیش‌فرض می‌گیرد. ترتیب اجرای این دو، به‌طور پیش‌فرض بر اساس زمان اضافه‌شدن است — یعنی روی سایت مشتری ممکن است خروجی موردانتظار شما نباشد. مدیریت درست این ترتیب، تفاوت بین افزونه‌ای است که «معمولاً» کار می‌کند و افزونه‌ای که «همیشه» کار می‌کند. برای درک عمیق این موضوع، مبحث Priority در هوک‌های وردپرس چیست را ببینید؛ در پروژه‌های خودم، اولین کاری که در بازبینی افزونه‌های تعارض‌دار انجام می‌دهم، بررسی اولویت‌هاست.

قاعدهٔ سادهٔ من: اگر افزونه‌تان کار می‌کند ولی با افزونهٔ دیگری نمی‌سازد، اولویت را عوض کنید، نه هوک را. یک add_filter با اولویت پیش‌فرض ۱۰، اگر به اولویت ۲۰ یا ۵ تغییر کند، مسیر حل مشکل کوتاه می‌شود؛ درحالی‌که تغییر خود هوک معمولاً یعنی بازنویسی منطق.

حذف و بازنویسی هوک‌های افزونه‌های دیگر

یکی از کاربردهای کمتر شناخته‌شدهٔ هوک‌ها در افزونه‌نویسی، توانایی حذف رفتار افزونه‌های دیگر است. مثلاً افزونه‌ای که یک پیام تبلیغاتی به پنل کاربر اضافه می‌کند و شما می‌خواهید در پروژهٔ مشتری این پیام را حذف کنید، بدون اینکه فایل افزونه را دست بزنید. جفت توابع remove_action و remove_filter همین کار را می‌کنند، ولی یک ترفند ظریف دارند: باید بعد از آنکه افزونه مقصد hook handler خود را ثبت کرد، اجرا شوند. روش دقیق این عملیات را در مقاله‌های نحوه حذف یک Action Hook در وردپرس و نحوه حذف یک Filter Hook در وردپرس با نمونه آورده‌ام؛ در عمل، این‌جاست که یک توسعه‌دهندهٔ حرفه‌ای از یک مبتدی جدا می‌شود، چون انعطاف‌پذیری در برابر افزونه‌های جانبی بخش بزرگی از ارزش کار او است.

امنیت و هوک‌ها: نیمهٔ پنهان داستان

در میان پروژه‌هایی که بازبینی کرده‌ام، تقریباً هیچ‌کدام از افزونه‌های آماتور، بحث امنیت در هوک‌ها را جدی نگرفته بودند. سه اصل ساده اما حیاتی که در همهٔ افزونه‌های حرفه‌ای رعایت می‌کنم:

• بررسی دسترسی پیش از هر عملیاتی که قرار است داده‌ای را تغییر دهد؛ با current_user_can.
• بررسی nonce در فرم‌ها و درخواست‌های AJAX؛ بدون آن، حملهٔ CSRF باز است.
• پاک‌سازی ورودی و خروجی؛ ورودی با sanitize_* و خروجی با esc_*.

ترتیب این سه، در مقالۀ هوک‌های وردپرس و افزایش امنیت کد با مثال کد باز شده است. یک نکتهٔ ظریف از تجربهٔ شخصی: هوک init گاهی به‌عنوان نقطهٔ بررسی درخواست‌های POST استفاده می‌شود، ولی برای فرم‌های پیشخوان، admin_post_* یا admin_post_nopriv_* مسیر امن‌تری است. انتخاب درست هوک، بخشی از امنیت است، نه فقط بخشی از معماری.

دیباگ هوک‌های سفارشی در پروژه‌های واقعی

وقتی افزونه‌ای رفتار موردانتظار را نشان نمی‌دهد، سه سؤال را به‌ترتیب از خودم می‌پرسم: ۱) آیا هوک واقعاً اجرا می‌شود؟ ۲) اگر اجرا می‌شود، در چه اولویتی اجرا می‌شود؟ ۳) آیا افزونهٔ دیگری هم روی همان هوک دست گذاشته؟ ابزارِ عملی من در این موقعیت، یک قطعهٔ کوچک لاگ‌گیری است که فقط در حالت دیباگ فعال می‌شود:

add_action( 'init', 'wphooks_rpb_debug_init', 999 );

function wphooks_rpb_debug_init() {
    if ( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) {
        return;
    }
    // فقط برای دیباگ موقت
    error_log( 'wphooks_rpb: init fired at priority 999' );
}

این الگو، هم نشان می‌دهد آیا هوک اجرا می‌شود و هم اولویت اجرای نسبت‌به سایر افزونه‌ها را آشکار می‌کند. ابزارهای تکمیلی و روش گام‌به‌گام در دیباگ کردن Action و Filter در وردپرس آمده است. یک هشدارِ مهم: هیچ‌گاه چنین لاگی را در نسخهٔ نهایی افزونه رها نکنید؛ فایل لاگ روی هاست‌های اشتراکی به‌سرعت رشد می‌کند و مسائل خودش را می‌سازد.

اشتباهات رایج و درس‌های گران‌قیمت

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

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

دید مهندسی: هوک به‌مثابهٔ قرارداد

برای توسعه‌دهنده‌ای که سال‌ها با کد سر و کله زده، هوک‌های وردپرس صرفاً یک API نیستند؛ یک قرارداد معماری هستند. وردپرس در هر آپدیت، آزاد است که ساختار داخلی فایل‌ها، نام کلاس‌ها و حتی ترتیب اجرای داخلی را تغییر دهد؛ ولی هوک‌ها را به‌عنوان بخشی از سطح تماس عمومی، پایدار نگه می‌دارد. اگر از منظر مهندسی نگاه کنیم، این دقیقاً همان الگویی است که در معماری نرم‌افزارهای بزرگ به آن Dependency Inversion یا Inversion of Control می‌گویند: به‌جای اینکه ما هسته را صدا بزنیم و انتظار داشته باشیم در نقطهٔ دلخواه ما اجرا شود، هسته ما را در نقاط اعلام‌شده صدا می‌زند.

این نگاه، سه پیامد عملی دارد که در پروژه‌های بزرگ به‌کارم آمده‌اند. اول، جداسازی مسئولیت‌ها: هر hook handler باید یک مسئولیت داشته باشد؛ اگر تابعی صد خطی روی the_content دارید، آن تابع چند مسئولیت مختلف را قاطی کرده و باید به چند تابع جدا با اولویت‌های مشخص تقسیم شود. دوم، قابلیت تست: هر hook handler را می‌توان به‌عنوان یک تابع خالص (Pure Function) طراحی کرد که ورودی می‌گیرد و خروجی می‌دهد؛ همین ویژگی، تست واحد (Unit Test) در محیط‌های CI را ممکن می‌کند، نه فقط برای افزونه‌های بزرگ بلکه برای پلاگین‌های کوچک هم. سوم، پایداری در برابر نوسان‌های اکوسیستم: افزونه‌ای که روی قرارداد هوک‌ها بنا شده، در برابر تغییر نسخه‌های PHP، به‌روزرسانی هسته، و حتی مهاجرت به یک هاست دیگر، انعطاف بیشتری نشان می‌دهد؛ چون لایهٔ نمایش و منطق آن، به‌جای درگیرشدن با جزئیات داخلی، فقط از طریق درهای رسمی گفت‌وگو می‌کند.

یک نکتهٔ عملی از جنسِ کتابخانه: اگر افزونه‌تان بیش از ۱۵ تا ۲۰ hook handler دارد، وقت آن است که ساختار را در کلاس‌ها یا ماژول‌های جدا سازمان دهید. در این حالت، هر کلاس مسئول یک دامنهٔ مشخص (مثلاً «کلاس مدیریت فرم پیشخوان»، «کلاس رندر فرانت») است و برای اتصال به هوک‌ها از یک ثبت‌کنندهٔ مرکزی استفاده می‌کنید. با این ساختار، هم بازبینی کد سریع‌تر می‌شود، هم اضافه‌کردن قابلیت تازه، ریسک شکستن بخش‌های قبلی را کمتر می‌کند.

هوک، مرز بین «کد من» و «کد هسته» است؛ هر چقدر این مرز را شفاف‌تر نگه دارید، پروژهٔ شما عمر بیشتری می‌کند.

جمع‌بندی

هوک‌های وردپرس در توسعه افزونه، نه یک امکان جانبی، بلکه زبانِ گفت‌وگوی افزونه با هسته، با قالب، و با سایر افزونه‌ها است. ایستگاه‌های اصلی این گفت‌وگو را مرور کردیم — فعال‌سازی، plugins_loaded، init، پیشخوان، front-end — و در یک نمونهٔ کوچک دیدیم که با پنج هوک چه اندازه معماری تمیزی می‌توان ساخت. مدیریت اولویت، حذف هوک‌های ناخواسته، امنیت، دیباگ هدفمند و پرهیز از اشتباهات رایج، پنج مهارتی هستند که تجربه‌ام نشان می‌دهد تفاوت بین یک افزونهٔ «کارکننده» و افزونهٔ «حرفه‌ای» را می‌سازند.

اگر می‌خواهید مسیر را عمیق‌تر دنبال کنید، گام بعدی من این است: یک افزونهٔ کوچک با ساختار استاندارد بسازید، هوک‌های سفارشی خودش را تعریف کنید، و روی یک نصب آزمایشی با یک افزونهٔ دیگر تعارض بسازید و بعد حلش کنید. تجربهٔ تعارض و رفع آن، بیش از خواندن ده مقاله به شما یاد می‌دهد. اگر افزونه‌ای دارید که روزی از کار افتاده و ریشهٔ مشکل به هوک برمی‌گشت، برای من جالب است بدانید کدام هوک بود و چه اولویتی داشت — تجربهٔ خودتان را در دیدگاه‌ها بنویسید؛ به‌ویژه اگر روش تشخیص متفاوتی استفاده کرده‌اید که می‌تواند برای خوانندهٔ بعدی راهنما باشد. 🧩