WordPress ہُکس انڈیکس

WordPress کے اُن ایکشنز اور فلٹرز کا قابلِ تلاش انڈیکس جو ڈویلپرز واقعی استعمال کرتے ہیں — بالکل درست add_action/add_filter سگنیچر، یہ کب چلتا ہے، ایک کارآمد مثال، اور وہ بات جو لوگوں کو نقصان پہنچاتی ہے، کے ساتھ۔

39 ہکس، ہر ایک کے ساتھ عین add_action / add_filter سگنیچر، یہ کب فائر ہوتا ہے، ایک چلتی ہوئی مثال، اور وہ بات جو لوگوں کو الجھا دیتی ہے۔ 1 کو غیر تصدیق شدہ نشان زد کیا گیا ہے — ہم نے WordPress سورس کے مقابلے میں ان کی آرگومنٹ گنتی نہیں جانچی، اور ہم کسی اندازے کو حقیقت کے طور پر پیش کرنے کے بجائے اس بات کی نشاندہی کرنا بہتر سمجھتے ہیں۔

یہ فہرست مکمل نہیں ہے اور نہ ہونے کا دعویٰ کرتی ہے — WordPress میں ہزاروں ہکس ہیں۔ یہ صرف انہی کا احاطہ کرتی ہے جنہیں لوگ حقیقتاً استعمال کرتے ہیں۔

39 میں سے 39

WordPress کے لوڈ مکمل ہو جانے کے بعد لیکن کوئی بھی headers بھیجے جانے سے پہلے چلتا ہے۔ کسٹم پوسٹ ٹائپس، ٹیکسانومیز اور ری رائٹ رولز رجسٹر کرنے کی معیاری جگہ۔

فائر ہوتا ہے

ہر ریکویسٹ پر — فرنٹ اینڈ اور ایڈمن دونوں — کور، پلگ انز اور تھیم لوڈ ہو جانے کے بعد۔

سگنیچر

add_action( 'init', 'my_callback' );

مثال

add_action( 'init', function () {
    register_post_type( 'book', array(
        'public'       => true,
        'label'        => 'Books',
        'show_in_rest' => true, // required for the block editor
    ) );
} );

دھیان دینے والی بات

init ہر ریکویسٹ پر چلتا ہے، بشمول AJAX، REST اور cron۔ یہاں کوئی بھی سست کام (ایک HTTP ریکویسٹ، ایک بھاری کوئری) ہر ایک صفحے کی لوڈنگ پر بوجھ ڈالتا ہے۔ نیز: موجودہ صارف یہاں دستیاب ہوتا ہے، لیکن آپ کچھ آؤٹ پٹ نہیں کر سکتے — headers ابھی بھیجے نہیں گئے، مگر بھیجے جانے والے ہیں۔

تھیم لوڈ ہو جانے پر ایک بار چلتا ہے۔ add_theme_support()، add_image_size() اور نیو مینوز رجسٹر کرنے کی درست جگہ۔

فائر ہوتا ہے

تھیم کی functions.php لوڈ ہونے کے بعد، init سے پہلے۔

سگنیچر

add_action( 'after_setup_theme', 'my_callback' );

مثال

add_action( 'after_setup_theme', function () {
    add_theme_support( 'post-thumbnails' );
    add_theme_support( 'title-tag' );
    add_image_size( 'card', 600, 400, true ); // true = hard crop
} );

دھیان دینے والی بات

امیج سائزز کو یہاں کے بجائے init پر رجسٹر کرنا زیادہ تر معاملات میں اتفاقاً کام کر جاتا ہے اور پھر کچھ میں پُراسرار طور پر ناکام ہو جاتا ہے۔ after_setup_theme استعمال کریں — یہ اسی کام کے لیے ہے۔

تمام فعال پلگ انز لوڈ ہو جانے پر ایک بار چلتا ہے۔ کسی دوسرے پلگ ان کے ساتھ تعامل کا سب سے پہلا محفوظ مقام۔

فائر ہوتا ہے

ہر پلگ ان فائل شامل ہونے کے بعد، تھیم لوڈ ہونے سے پہلے۔

سگنیچر

add_action( 'plugins_loaded', 'my_callback' );

دھیان دینے والی بات

موجودہ صارف یہاں ابھی دستیاب نہیں ہوتا — wp_get_current_user() قابلِ اعتماد طریقے سے کام نہیں کرے گا۔ اگر آپ کو صارف چاہیے تو init استعمال کریں۔

WordPress مکمل طور پر لوڈ ہو جانے کے بعد چلتا ہے — پلگ انز، تھیم، init، اور صارف سب تیار ہوتے ہیں۔

فائر ہوتا ہے

init کے بعد اور موجودہ صارف سیٹ ہو جانے کے بعد۔

سگنیچر

add_action( 'wp_loaded', 'my_callback' );

ہر ایڈمن ریکویسٹ کے آغاز پر چلتا ہے۔ register_setting()، اجازتوں کی جانچ، اور ایڈمن ری ڈائریکٹس کے لیے استعمال ہوتا ہے۔

فائر ہوتا ہے

ہر ایڈمن سائیڈ ریکویسٹ پر۔

سگنیچر

add_action( 'admin_init', 'my_callback' );

دھیان دینے والی بات

یہ admin-ajax.php ریکویسٹس پر بھی چلتا ہے، جو دراصل "ایڈمن اسکرینز" نہیں ہیں۔ اگر آپ کا کال بیک یہ فرض کرتا ہے کہ کوئی اسکرین موجود ہے تو اسے wp_doing_ajax() کے ساتھ محفوظ کریں۔

فرنٹ اینڈ CSS اور JavaScript کو enqueue کرنے کی واحد درست جگہ۔

فائر ہوتا ہے

فرنٹ اینڈ صفحات کی لوڈنگ پر، head رینڈر ہونے سے پہلے۔

سگنیچر

add_action( 'wp_enqueue_scripts', 'my_callback' );

مثال

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style(
        'child-style',
        get_stylesheet_uri(),
        array( 'parent-style' ),          // load AFTER the parent
        wp_get_theme()->get( 'Version' )  // cache-bust on version change
    );
} );

دھیان دینے والی بات

نام کے باوجود یہ اسکرپٹس کے ساتھ ساتھ اسٹائلز بھی سنبھالتا ہے — wp_enqueue_styles نام کا کوئی ہُک نہیں ہے، اور لوگ اسے ڈھونڈنے میں اصل وقت ضائع کرتے ہیں۔ نیز: یہ ایڈمن میں نہیں چلتا (admin_enqueue_scripts استعمال کریں) اور نہ ہی بلاک ایڈیٹر میں (enqueue_block_editor_assets استعمال کریں)۔

ایڈمن میں CSS/JS کو enqueue کریں۔ موجودہ اسکرین کا hook suffix وصول کرتا ہے تاکہ آپ صرف ایک ہی اسکرین پر اثاثے لوڈ کر سکیں۔

فائر ہوتا ہے

ایڈمن صفحات کی لوڈنگ پر۔

سگنیچر

add_action( 'admin_enqueue_scripts', 'my_callback' ); // receives $hook_suffix

مثال

add_action( 'admin_enqueue_scripts', function ( $hook ) {
    if ( 'settings_page_my-plugin' !== $hook ) {
        return; // do not load our JS on every admin screen
    }
    wp_enqueue_script( 'my-admin', plugins_url( 'admin.js', __FILE__ ), array(), '1.0', true );
} );

دھیان دینے والی بات

$hook پر جانچ نہ لگانا کسی پلگ ان کے ذریعے غیر متعلقہ ایڈمن اسکرینز کو خراب کرنے کی سب سے عام وجہ ہے۔ اپنے اثاثے وہیں لوڈ کریں جہاں ان کی ضرورت ہو اور کہیں اور نہیں۔

اثاثے صرف بلاک ایڈیٹر (Gutenberg) میں enqueue کریں — فرنٹ اینڈ میں نہیں، باقی ایڈمن میں بھی نہیں۔

فائر ہوتا ہے

جب بلاک ایڈیٹر لوڈ ہوتا ہے۔

سگنیچر

add_action( 'enqueue_block_editor_assets', 'my_callback' );

<head> میں آؤٹ پٹ پرنٹ کرتا ہے۔ میٹا ٹیگز اور inline کریٹیکل CSS کے لیے استعمال ہوتا ہے۔

فائر ہوتا ہے

فرنٹ اینڈ پر، <head> کے اندر۔

سگنیچر

add_action( 'wp_head', 'my_callback' );

دھیان دینے والی بات

یہاں اسکرپٹس یا اسٹائلز کو enqueue نہ کریں — wp_enqueue_scripts استعمال کریں، جو WordPress کو dependencies اور نقل کے خاتمے کو سنبھالنے دیتا ہے۔ wp_head میں <script> ٹیگ echo کرنا اس سب کو نظرانداز کر دیتا ہے اور یہی وجہ ہے کہ اتنی ساری سائٹس jQuery کو تین بار لوڈ کرتی ہیں۔

</body> سے بالکل پہلے آؤٹ پٹ پرنٹ کرتا ہے۔ اینالٹکس اسنیپٹس اور مؤخر شدہ مارک اپ کے لیے صحیح جگہ۔

فائر ہوتا ہے

فرنٹ اینڈ صفحے کے آخر میں۔

سگنیچر

add_action( 'wp_footer', 'my_callback' );

دھیان دینے والی بات

جو تھیم wp_footer() کو کال کرنا بھول جائے وہ ایڈمن بار کو خراب کر دیتی ہے، کسی بھی ایسے پلگ ان کو خراب کر دیتی ہے جو کوئی footer اسکرپٹ enqueue کرتا ہے، اور wordpress.org تھیم ریویو میں خودکار طور پر مسترد ہو جاتی ہے۔

پوسٹ کے مواد کو دکھائے جانے سے عین پہلے فلٹر کرتا ہے۔ کسی پوسٹ میں مارک اپ آگے یا پیچھے جوڑنے کی معمول کی جگہ۔

فائر ہوتا ہے

ہر بار جب the_content() کال ہوتا ہے۔

سگنیچر

add_filter( 'the_content', 'my_callback' ); // receives $content

مثال

add_filter( 'the_content', function ( $content ) {
    if ( ! is_singular( 'post' ) || ! in_the_loop() || ! is_main_query() ) {
        return $content; // <- the guard everyone forgets
    }
    return $content . '<p class="cta">Enjoyed this? Read more.</p>';
} );

دھیان دینے والی بات

یہ آپ کے سوچنے سے کہیں زیادہ بار چلتا ہے — ویجٹس میں، REST رسپانسز میں، کچھ پلگ انز کی excerpt جنریشن میں، اور کسی آرکائیو کے loop میں ہر پوسٹ پر ایک بار۔ is_singular / in_the_loop / is_main_query کی جانچ کے بغیر، آپ کا CTA بلاگ انڈیکس پر اور RSS فیڈ کے اندر پندرہ بار ظاہر ہوتا ہے۔ یہ WordPress میں سب سے زیادہ غلط استعمال ہونے والا فلٹر ہے۔

پوسٹ کے عنوان کو دکھائے جانے سے پہلے فلٹر کرتا ہے۔

فائر ہوتا ہے

ہر بار جب the_title() یا get_the_title() کال ہوتا ہے۔

سگنیچر

add_filter( 'the_title', 'my_callback', 10, 2 ); // receives $title, $post_id

دھیان دینے والی بات

یہ ایڈمن مینو میں، نیو مینوز میں، اور دستاویز کے <title> میں عنوانات کے لیے بھی چلتا ہے۔ اسے بلا شرط فلٹر کرنا اُن جگہوں پر چیزوں کا نام بدل دے گا جہاں آپ کا ارادہ نہیں تھا۔

طے کرتا ہے کہ خودکار طور پر بننے والے excerpt میں کتنے الفاظ ہوں گے۔ ڈیفالٹ 55 ہے۔

فائر ہوتا ہے

جب WordPress کسی ایسی پوسٹ کے لیے excerpt بناتا ہے جس کا کوئی دستی excerpt نہ ہو۔

سگنیچر

add_filter( 'excerpt_length', 'my_callback' ); // receives $length (words)

مثال

add_filter( 'excerpt_length', function ( $length ) {
    return 25;
}, 999 ); // high priority: many themes set this too, and last one wins

دھیان دینے والی بات

اُن پوسٹس پر اس کا کوئی اثر نہیں ہوتا جن کا دستی excerpt موجود ہو — وہ من و عن استعمال ہوتے ہیں۔ اور بہت سی تھیمیں یہ فلٹر خود سیٹ کرتی ہیں، اس لیے جیتنے کے لیے اکثر آپ کو ایک زیادہ priority نمبر کی ضرورت ہوتی ہے۔

کاٹے گئے excerpt کے آخر میں جوڑی جانے والی اسٹرنگ کو تبدیل کرتا ہے۔ ڈیفالٹ " […]" ہے۔

فائر ہوتا ہے

جب کوئی خودکار طور پر بنا excerpt کاٹا جاتا ہے۔

سگنیچر

add_filter( 'excerpt_more', 'my_callback' ); // receives $more

کسی کوئری کو اس کے چلنے سے پہلے تبدیل کرتا ہے۔ کسی آرکائیو پر جو کچھ ظاہر ہوتا ہے اسے بدلنے کا درست طریقہ — ایک دوسری WP_Query سے کہیں بہتر۔

فائر ہوتا ہے

query vars پارس ہو جانے کے بعد، SQL بننے سے پہلے۔

سگنیچر

add_action( 'pre_get_posts', 'my_callback' ); // receives WP_Query $query (by reference)

مثال

add_action( 'pre_get_posts', function ( $query ) {
    if ( is_admin() || ! $query->is_main_query() ) {
        return; // <- both guards are mandatory
    }
    if ( $query->is_category() ) {
        $query->set( 'posts_per_page', 12 );
    }
} );

دھیان دینے والی بات

یہ ایڈمن میں بھی چلتا ہے، اور ہر کوئری کے لیے چلتا ہے، بشمول مینوز، ویجٹس اور میڈیا لائبریری۔ is_admin() اور is_main_query() کی جانچ چھوڑ دیں تو آپ خاموشی سے بدل دیں گے کہ ایڈمن کی پوسٹ فہرست کیا دکھاتی ہے — ایسا بگ جسے پیچھے تک تلاش کرنا واقعی مشکل ہوتا ہے۔ یہ بھی نوٹ کریں: $query کو تبدیل کریں، کچھ return نہ کریں۔

کسی کوئری کے خام SQL WHERE کلاز کو فلٹر کرتا ہے۔

فائر ہوتا ہے

جب کوئری کی SQL ترتیب دی جا رہی ہوتی ہے۔

سگنیچر

add_filter( 'posts_where', 'my_callback', 10, 2 ); // receives $where, WP_Query $query

دھیان دینے والی بات

آپ خام SQL لکھ رہے ہیں۔ ہمیشہ $query->is_main_query() کے ساتھ جانچ لگائیں اور کسی بھی صارف ان پٹ کے لیے ہمیشہ $wpdb->prepare() استعمال کریں۔ یہ کسی WordPress سائٹ میں SQL injection داخل کرنے کا سب سے تیز طریقہ ہے۔

کسی کوئری کو ملنے والی پوسٹس کی کل تعداد کو فلٹر کرتا ہے — جس سے pagination کا حساب لگایا جاتا ہے۔

فائر ہوتا ہے

کوئری چلنے کے بعد، pagination شمار ہونے سے پہلے۔

سگنیچر

add_filter( 'found_posts', 'my_callback', 10, 2 ); // receives $found_posts, WP_Query $query

وہ پکسل سائز طے کرتا ہے جس سے اوپر WordPress کسی اپلوڈ کو چھوٹا کر دیتا ہے اور آپ کے اصل کے بجائے ایک "-scaled" کاپی فراہم کرتا ہے۔ ڈیفالٹ 2560۔

فائر ہوتا ہے

اپلوڈ کے وقت، جب WordPress فیصلہ کرتا ہے کہ کوئی تصویر "بڑی" ہے یا نہیں۔

سگنیچر

add_filter( 'big_image_size_threshold', 'my_callback' ); // receives int $threshold

مثال

// Serve originals at full resolution — no -scaled copy.
add_filter( 'big_image_size_threshold', '__return_false' );

// Or just raise the ceiling:
add_filter( 'big_image_size_threshold', function () {
    return 3840;
} );

دھیان دینے والی بات

یہ "WordPress پر اپلوڈ کرنے کے بعد میری تصویر دھندلی لگتی ہے" کی سب سے عام وجہ ہے، اور تقریباً کسی کو معلوم نہیں کہ یہ موجود بھی ہے۔ آپ کا اصل ابھی بھی ڈسک پر ہوتا ہے — بس اسے کبھی فراہم نہیں کیا جاتا۔ نوٹ کریں کہ یہ سب سے لمبے کنارے پر لاگو ہوتا ہے، اور صرف اُن تصاویر پر اثر ڈالتا ہے جو فلٹر فعال ہونے کے بعد اپلوڈ کی جائیں۔

اُن امیج سائزز کی array کو فلٹر کرتا ہے جو WordPress کسی اپلوڈ کے لیے بنانے والا ہوتا ہے۔ کسی سائز کو بننے سے روکنے کے لیے اسے unset کر دیں۔

فائر ہوتا ہے

اپلوڈ کے وقت، مشتق فائلیں بننے سے پہلے۔

سگنیچر

add_filter( 'intermediate_image_sizes_advanced', 'my_callback', 10, 2 ); // receives $sizes, $metadata

مثال

add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
    unset( $sizes['1536x1536'] );
    unset( $sizes['2048x2048'] );
    return $sizes;
} );

دھیان دینے والی بات

کسی ایسے سائز کو ہٹانا جو آپ کی تھیم واقعی استعمال کرتی ہے کا مطلب ہے کہ WordPress full-size اصل پر واپس چلا جاتا ہے — جو اُس ڈسک اسپیس سے بھی بدتر ہے جو آپ نے بچائی۔ اور یہ صرف نئی فائلوں کو بننے سے روکتا ہے؛ موجودہ فائلیں تب تک رہتی ہیں جب تک آپ انہیں دوبارہ نہ بنائیں۔

وہ JPEG کوالٹی طے کرتا ہے جس پر WordPress اپلوڈ شدہ تصاویر کو دوبارہ انکوڈ کرتا ہے۔ ڈیفالٹ 82۔

فائر ہوتا ہے

جب بھی WordPress کوئی JPEG لکھتا ہے۔

سگنیچر

add_filter( 'jpeg_quality', 'my_callback', 10, 2 ); // receives $quality, $context

دھیان دینے والی بات

کوالٹی 82 تصاویر کے لیے ٹھیک ہے اور اسکرین شاٹس، لوگوز اور فلیٹ گرافکس کے لیے واضح طور پر خراب — اُن میں سخت کنارے ہوتے ہیں اور کوئی فوٹوگرافک نوائز نہیں ہوتی جس میں artefacts چھپ سکیں۔ نیز: wp_editor_set_quality زیادہ جدید فلٹر ہے اور امیج ایڈیٹر کلاسز کو براہِ راست کور کرتا ہے؛ دونوں کو سیٹ کرنا عام بات ہے۔

WP_Image_Editor کلاسز (GD اور Imagick) کے استعمال کردہ آؤٹ پٹ کوالٹی طے کرتا ہے۔

فائر ہوتا ہے

جب کوئی امیج ایڈیٹر instance اپنی کوالٹی سیٹ کرتا ہے۔

سگنیچر

add_filter( 'wp_editor_set_quality', 'my_callback', 10, 2 ); // receives $quality, $mime_type

آپ کے کسٹم امیج سائزز کو میڈیا موڈل اور بلاک ایڈیٹر میں سائز dropdown میں شامل کرتا ہے۔

فائر ہوتا ہے

جب میڈیا UI اپنا سائز سلیکٹر بناتا ہے۔

سگنیچر

add_filter( 'image_size_names_choose', 'my_callback' ); // receives $sizes

مثال

add_filter( 'image_size_names_choose', function ( $sizes ) {
    return array_merge( $sizes, array( 'card' => __( 'Card', 'textdomain' ) ) );
} );

دھیان دینے والی بات

add_image_size() سائز کو رجسٹر کرتا ہے لیکن اسے ایڈیٹر میں قابلِ انتخاب نہیں بناتا۔ "میرا کسٹم امیج سائز dropdown میں ظاہر نہیں ہوتا" کا ہر سوال اسی فلٹر کے غائب ہونے کا نتیجہ ہے۔

کسی فائل کو uploads فولڈر میں منتقل کیے جانے سے پہلے جانچتا یا مسترد کرتا ہے۔

فائر ہوتا ہے

اپلوڈ کے دوران، فائل لکھے جانے سے پہلے۔

سگنیچر

add_filter( 'wp_handle_upload_prefilter', 'my_callback' ); // receives $file

دھیان دینے والی بات

کسی فائل کو مسترد کرنے کے لیے، $file['error'] کو ایک پیغام اسٹرنگ پر سیٹ کریں اور $file واپس کریں۔ false واپس کرنا یا throw کرنا وہ نہیں کرے گا جو آپ چاہتے ہیں۔

کسی attachment کے پروسیس ہونے کے بعد metadata array (بشمول بنائے گئے سائزز) کو فلٹر کرتا ہے۔

فائر ہوتا ہے

اپلوڈ پر مشتق تصاویر بننے کے بعد۔

سگنیچر

add_filter( 'wp_generate_attachment_metadata', 'my_callback', 10, 2 ); // receives $metadata, $attachment_id

دھیان دینے والی بات

یہ وہ ہُک ہے جو امیج آپٹیمائزیشن پلگ انز استعمال کرتے ہیں۔ یہ سست ہو سکتا ہے — یہ ہر امیج سائز لکھے جانے کے بعد چلتا ہے، اور یہاں ایک HTTP ریکویسٹ کرنے سے ہر اپلوڈ کو اس کا انتظار کرنا پڑتا ہے۔

اُن srcset امیدواروں کو فلٹر کرتا ہے جو WordPress کسی ریسپانسو تصویر کے لیے بناتا ہے۔

فائر ہوتا ہے

جب کوئی ریسپانسو تصویر رینڈر ہوتی ہے۔

سگنیچر

add_filter( 'wp_calculate_image_srcset', 'my_callback', 10, 5 );

دھیان دینے والی بات

کہیں اور medium_large (768w) سائز کو ہٹانا خاموشی سے srcset کو کمزور کر دیتا ہے — وہ سائز تقریباً مکمل طور پر اسی کو فراہم کرنے کے لیے موجود ہے۔

ہم نے WordPress سورس کے مقابلے میں اس ہک کی عین آرگومنٹ گنتی کی تصدیق نہیں کی۔ اس پر انحصار کرنے سے پہلے developer.wordpress.org چیک کریں۔ ہم غیر یقینی صورتحال کی نشاندہی کرنا بہتر سمجھتے ہیں بجائے اس کے کہ خاموشی سے کسی اندازے کو حقیقت کے طور پر پیش کر دیں۔

ایڈمن مینو اور سب مینو صفحات رجسٹر کرتا ہے۔

فائر ہوتا ہے

جب ایڈمن مینو بنایا جا رہا ہوتا ہے۔

سگنیچر

add_action( 'admin_menu', 'my_callback' );

مثال

add_action( 'admin_menu', function () {
    add_options_page(
        'My Plugin',
        'My Plugin',
        'manage_options',   // capability — NOT a role
        'my-plugin',
        'my_render_settings_page'
    );
} );

دھیان دینے والی بات

capability آرگیومنٹ ایک capability ہے، role نہیں۔ "administrator" پاس کرنا کام کرتا معلوم ہوتا ہے (کیونکہ کچھ سیٹ اپس میں ایڈمنز کے پاس اسی نام کی ایک capability ہوتی ہے) اور پھر خاموشی سے غلط لوگوں کو رسائی دے دیتا ہے۔ manage_options استعمال کریں۔

کسی ایڈمن اسکرین کے اوپر ایک نوٹس پرنٹ کرتا ہے۔

فائر ہوتا ہے

ایڈمن صفحہ رینڈر ہونے پر۔

سگنیچر

add_action( 'admin_notices', 'my_callback' );

دھیان دینے والی بات

یہ ہر ایڈمن اسکرین پر چلتا ہے۔ جو پلگ ان اُن سب پر بلا شرط "انسٹال کرنے کا شکریہ!" نوٹس دکھاتا ہے وہ WordPress ایڈمن میں سب سے زیادہ ناپسند کیا جانے والا طریقہ ہے۔ اسے محفوظ کریں، اور اسے قابلِ برخاست بنائیں۔

جب بھی کوئی پوسٹ بنائی یا اپڈیٹ کی جاتی ہے تب چلتا ہے۔ میٹا باکس کا ڈیٹا محفوظ کرنے کی معمول کی جگہ۔

فائر ہوتا ہے

کسی پوسٹ کے ڈیٹا بیس میں لکھے جانے کے بعد۔

سگنیچر

add_action( 'save_post', 'my_callback', 10, 3 ); // receives $post_id, $post, $update

مثال

add_action( 'save_post', function ( $post_id ) {
    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) return;
    if ( wp_is_post_revision( $post_id ) ) return;
    if ( ! current_user_can( 'edit_post', $post_id ) ) return;
    // ... now it is safe to save
}, 10, 1 );

دھیان دینے والی بات

یہ حقیقی محفوظ کرنے کے ساتھ ساتھ آٹو سیوز اور ریویژنز پر بھی چلتا ہے۔ اوپر دی گئی تین جانچوں کے بغیر، ہر بار جب ایڈیٹر آٹو سیو کرتا ہے تو آپ کا meta خالی اقدار سے اوور رائٹ ہو جاتا ہے — ایسا بگ جو ڈیٹا کے بے ترتیب طور پر غائب ہونے جیسا لگتا ہے۔

پوسٹ ایڈٹ اسکرین پر میٹا باکسز رجسٹر کرتا ہے۔

فائر ہوتا ہے

جب ایڈٹ اسکرین بنائی جاتی ہے۔

سگنیچر

add_action( 'add_meta_boxes', 'my_callback', 10, 2 ); // receives $post_type, $post

دھیان دینے والی بات

کلاسک میٹا باکسز بلاک ایڈیٹر میں ظاہر نہیں ہوتے جب تک بلاک ایڈیٹر compatibility موڈ پر واپس نہ چلا جائے۔ بلاک ایڈیٹر پر بنی سائٹ کے لیے، اس کے بجائے show_in_rest کے ساتھ post meta رجسٹر کریں اور ایک سائیڈبار پینل بنائیں۔

کسی صارف کے کامیابی سے لاگ اِن ہونے کے بعد چلتا ہے۔

فائر ہوتا ہے

کامیاب تصدیق پر۔

سگنیچر

add_action( 'wp_login', 'my_callback', 10, 2 ); // receives $user_login, WP_User $user

کوئی نیا صارف بننے کے فوراً بعد چلتا ہے۔

فائر ہوتا ہے

رجسٹریشن پر۔

سگنیچر

add_action( 'user_register', 'my_callback', 10, 2 ); // receives $user_id, $userdata

تصدیق کے نتیجے کو فلٹر کرتا ہے۔ کسی لاگ اِن کو روکنے کے لیے ایک WP_Error واپس کریں۔

فائر ہوتا ہے

لاگ اِن کی کوشش کے دوران۔

سگنیچر

add_filter( 'authenticate', 'my_callback', 30, 3 ); // receives $user, $username, $password

دھیان دینے والی بات

یہاں priority بہت اہمیت رکھتی ہے۔ WordPress کور اپنی جانچیں 20 اور 30 priority پر لگاتا ہے — بہت جلدی جوڑیں تو آپ پاس ورڈ کی جانچ ہونے سے بھی پہلے چل جاتے ہیں۔

REST روٹس اور فیلڈز رجسٹر کرتا ہے۔

فائر ہوتا ہے

جب REST API شروع ہوتا ہے۔

سگنیچر

add_action( 'rest_api_init', 'my_callback' );

مثال

add_action( 'rest_api_init', function () {
    register_rest_route( 'myplugin/v1', '/items', array(
        'methods'             => 'GET',
        'callback'            => 'my_get_items',
        'permission_callback' => '__return_true', // BE DELIBERATE ABOUT THIS
    ) );
} );

دھیان دینے والی بات

permission_callback لازمی ہے — WP 5.5 سے اسے چھوڑ دینا ایک notice پیدا کرتا ہے، اور اسے __return_true پر سیٹ کرنا endpoint کو مکمل طور پر عوامی بنا دیتا ہے۔ یہ واقعی عوامی ڈیٹا کے لیے تو ٹھیک ہے مگر باقی ہر چیز کے لیے ایک سنگین سوراخ۔ فیصلہ کریں، ڈیفالٹ پر نہ چھوڑیں۔

wp_schedule_event() کے لیے ایک کسٹم تکرار وقفہ شامل کرتا ہے۔

فائر ہوتا ہے

جب WordPress دستیاب schedules کی اپنی فہرست بناتا ہے۔

سگنیچر

add_filter( 'cron_schedules', 'my_callback' ); // receives $schedules

مثال

add_filter( 'cron_schedules', function ( $schedules ) {
    $schedules['every_five_minutes'] = array(
        'interval' => 300,             // seconds
        'display'  => __( 'Every 5 minutes', 'textdomain' ),
    );
    return $schedules;
} );

دھیان دینے والی بات

WP-Cron ایک حقیقی cron نہیں ہے۔ یہ صرف تب چلتا ہے جب کوئی سائٹ پر آتا ہے، اس لیے کم ٹریفک والی سائٹ پانچ منٹ کا schedule ہر پانچ منٹ بعد نہیں چلائے گی۔ اگر وقت کا واقعی فرق پڑتا ہے، تو WP-Cron کو غیر فعال کریں (DISABLE_WP_CRON) اور wp-cron.php کو کسی حقیقی سسٹم cron سے کال کریں۔

کسی تبصرے کے محفوظ ہونے کے فوراً بعد چلتا ہے۔

فائر ہوتا ہے

تبصرہ جمع کرانے پر۔

سگنیچر

add_action( 'comment_post', 'my_callback', 10, 3 ); // receives $comment_id, $approved, $commentdata

تبصرے کے ڈیٹا کو محفوظ ہونے سے پہلے فلٹر کرتا ہے۔ اسپام جانچ اور توثیق کے لیے استعمال ہوتا ہے۔

فائر ہوتا ہے

تبصرہ لکھے جانے سے پہلے۔

سگنیچر

add_filter( 'preprocess_comment', 'my_callback' ); // receives $commentdata

دھیان دینے والی بات

یہاں کسی تبصرے کو مسترد کرنے کے لیے، ایک پیغام کے ساتھ wp_die() کال کریں — false واپس کرنا اسے نہیں روکتا۔

کامیاب چیک آؤٹ کے بعد order-received صفحے پر چلتا ہے۔

فائر ہوتا ہے

جب گاہک thank-you صفحے پر پہنچتا ہے۔

سگنیچر

add_action( 'woocommerce_thankyou', 'my_callback' ); // receives $order_id

دھیان دینے والی بات

یہ fulfilment کو ٹرگر کرنے کی قابلِ اعتماد جگہ نہیں ہے۔ یہ صرف تب چلتا ہے جب گاہک واقعی thank-you صفحے تک پہنچے — اگر وہ ادائیگی کے بعد ٹیب بند کر دیں، تو یہ کبھی نہیں چلتا۔ جو کچھ ضرور ہونا چاہیے اس کے لیے woocommerce_payment_complete یا کوئی order-status transition ہُک استعمال کریں۔

پروڈکٹ صفحے پر add-to-cart بٹن سے عین پہلے مارک اپ آؤٹ پٹ کرتا ہے۔

فائر ہوتا ہے

جب پروڈکٹ صفحہ رینڈر ہوتا ہے۔

سگنیچر

add_action( 'woocommerce_before_add_to_cart_button', 'my_callback' );

کلاسک چیک آؤٹ پر فیلڈز شامل، ہٹا یا دوبارہ ترتیب دیتا ہے۔

فائر ہوتا ہے

جب چیک آؤٹ فارم بنایا جاتا ہے۔

سگنیچر

add_filter( 'woocommerce_checkout_fields', 'my_callback' ); // receives $fields

دھیان دینے والی بات

یہ صرف کلاسک (shortcode) چیک آؤٹ پر اثر ڈالتا ہے۔ نیا بلاک پر مبنی چیک آؤٹ اسے مکمل طور پر نظرانداز کرتا ہے اور JavaScript میں Slot & Fill کے ذریعے حسبِ ضرورت بنایا جاتا ہے۔ یہ پہلی بار تقریباً ہر کسی کو پھنسا دیتا ہے۔