ورڈپریس مان هڪ مخصوص پوسٽ آئي ڊي کي مڪمل طور تي ڪيئن خارج ڪجي ۽ ان کي ميليسارچ (اسڪري سرچ پلگ ان ان پريڪٽس) سان ڪيئن هم وقت ڪجي

مان تازو ئي هڪ ورڈپریس ويب سائيٽ تي ڪم ڪري رهيو آهيان ۽ هڪ اعليٰ ڪارڪردگي واري سائيٽ وائڊ سرچ انجن شامل ڪرڻ چاهيان ٿو. گهڻي ڳولا کان پوءِ، مون ميليس سرچ چونڊيو ۽ ان کي اسڪرائي سرچ نالي هڪ پلگ ان سان جوڙيو.

پهرين ته اهو آساني سان هليو. مون پلگ ان انسٽال ڪيو، ان کي ترتيب ڏنو، ۽ انڊيڪس خودڪار طريقي سان پيدا ٿيو. ڳولا جي رفتار تمام تيز هئي، ۽ تجربو واقعي شاندار هو.

پر هتي مسئلو اچي ٿو.

ويب سائيٽ تي ڪيترائي غير معمولي مضمون آهن. ڪجهه اندروني جاچ لاءِ آهن، ڪجهه مخصوص ڪلائنٽس لاءِ وقف ٿيل لينڊنگ صفحا آهن، ۽ ٻيا اڻپورا مواد آهن جيڪي اسان ختم ڪرڻ نٿا چاهيون. مون کي انهن آرٽيڪل آئي ڊيز جي ضرورت آهي ته جيئن ڳولا جي نتيجن مان مڪمل طور تي غائب ٿي وڃن.

اهو ڪافي ناهي ته اهو نه ملي سگهي؛ اهو آهي ته اهو ميليس سرچ جي انڊيڪس ۾ به نه ٿي سگهي.

مون سوچيو ته هي سادو هو؛ اهو صرف ڪجهه آئي ڊيز کي خارج ڪرڻ جو معاملو آهي. پلگ ان دستاويزن ۾ لاڳاپيل ٿلها هجڻ گهرجن؛ صرف هڪ فلٽر شامل ڪريو ۽ اهو ٿي ويو.

جيئن اهو نڪتو، مان غلط هوس.

روايتي مداخلت جا طريقا ڇو ناڪام ٿين ٿا؟

مون پهريون ڀيرو سرڪاري دستاويزن ۾ ذڪر ڪيل فلٽر هُڪ آزمايو. مون functions.php ۾ ڪوڊ جون ڪجھ لائينون شامل ڪيون، ان کي محفوظ ڪيو، بيڪ اينڊ کي ريفريش ڪيو، ۽ ان کي ٻيهر انڊيڪس ڪيو.

پوءِ مون ميليس سرچ بيڪ اينڊ چيڪ ڪيو.

اهي مضمون اڃا تائين موجود آهن.

مان حيران ٿي ويس.

مون سوچيو ته مون غلط ڪوڊ لکيو آهي، تنهن ڪري مون ان کي ڪيترائي ڀيرا چيڪ ڪيو، پر ان ۾ ڪجهه به غلط نه هو. پوءِ مون پلگ ان جي گٽ هب مسئلن کي ڳوليو ۽ ڏٺائين ته ڪيترن ئي ٻين ماڻهن کي ساڳين مسئلن جو سامنا ٿيو هو.

اهو ظاهر ٿئي ٿو ته اسڪرائي سرچ پلگ ان پس منظر جي بچت جي عمل کي سست ڪرڻ کان بچڻ لاءِ هڪ غير مطابقت پذير ٽاسڪ قطار ميڪانيزم استعمال ڪري ٿو. ان جو مطلب اهو آهي ته جڏهن توهان پس منظر ۾ "آرٽيڪل محفوظ ڪريو" تي ڪلڪ ڪندا آهيو، ته ڊيٽا کي فوري طور تي ڪسٽم ٽاسڪ ٽيبل ۾ ڌڪيو ويندو، باقاعده سنگل آرٽيڪل فلٽرنگ کي نظرانداز ڪندي.

ان کان به وڌيڪ خراب ڳالهه اها آهي ته جڏهن توهان گلوبل انڊيڪس کي ٻيهر پيدا ڪرڻ لاءِ پس منظر ۾ "انڊيڪس پوسٽس" تي ڪلڪ ڪندا آهيو، ته پلگ ان سڌو سنئون بنيادي سطح تي بيچ ڊيٽابيس ڪوري انجام ڏيندو آهي. هن موقعي تي، فلٽر ٿلهو جيڪو توهان اڳ ۾ شامل ڪيو هو ان کي ڪڏهن به عمل ڪرڻ جو موقعو نه ملندو آهي.

ٻين لفظن ۾، روايتي بلاڪنگ طريقا صرف ان وقت اثر انداز ٿيندا آهن جڏهن توهان دستي طور تي مضمون محفوظ ڪندا آهيو. پر اسڪرائي سرچ جي هم وقت سازي جي منطق توهان جي تصور کان گهڻو وڌيڪ پيچيده آهي.

ڊبل انشورنس انٽرسيپٽر ڪور ڪوڊ

ان بابت سوچڻ کان پوءِ، مون کي احساس ٿيو ته هن معاملي کي هن طرح نه ٿو ڇڏي سگهجي.

جيئن ته روايتي ٿلهو صرف "سنگل آرٽيڪل سيونگ" انٽري پوائنٽ کي ڪنٽرول ڪري ٿو، مون کي ٻين هنڌن کان به ان کي بلاڪ ڪرڻ جو طريقو ڳولڻ جي ضرورت آهي.

مون ٻه رستا سوچيا آهن.

پهريون مسئلو نيٽ ورڪ ٽرانسميشن جو اختتام آهي. ڇا اهو سنگل آرٽيڪل سنڪرونائيزيشن هجي يا بيچ سنڪرونائيزيشن، آخري ڊيٽا اڃا تائين HTTP درخواستن ذريعي ميليس سرچ سرور ڏانهن موڪلڻ جي ضرورت آهي، صحيح؟ تنهن ڪري، HTTP درخواست موڪلڻ کان اڳ، مون کي چيڪ ڪرڻ گهرجي ته ڇا درخواست جي جسم ۾ انهن خارج ٿيل مضمونن جي ID شامل آهن. جيڪڏهن ائين آهي، ته مون کي سڌو سنئون درخواست کي موڪلڻ کان روڪڻ گهرجي.

ٻيو نقطو ڊيٽابيس جي سوال سان لاڳاپيل آهي. جيئن ته پلگ ان بيچ انڊيڪسنگ دوران ڊيٽابيس مان سڌو سنئون آرٽيڪل لسٽ حاصل ڪري ٿو، مان ڊيٽابيس جي سوال تي عمل ڪرڻ کان اڳ سوالن جي نتيجن مان انهن مخصوص IDs کي هٽائي ڇڏيندس. پلگ ان جي نقطي نظر کان، اهي آرٽيڪل بلڪل موجود نه آهن، تنهنڪري اهي حاصل نه ڪيا ويندا.

ٻہ رستا، ٻہ انشورنس. جيڪڏهن هڪ رستو بند نه ٿو ڪري سگهجي، ته ٻيو بيڪ اپ طور موجود آهي.

ان کي سمجهڻ کان پوءِ، مون ڪوڊ لکڻ شروع ڪيو.

پهرين انٽرسيپٽر لاءِ، مون ورڈپریس جو اصلي استعمال ڪيو.pre_http_requestفلٽر. هي ٿلهو ورڈپریس جي ڪنهن به HTTP درخواست ڪرڻ کان اڳ شروع ٿئي ٿو. منهنجو منطق اهو آهي ته اهو معلوم ڪندو ته درخواست ڪيل URL ۾ شامل آهي...meilisearchجيڪڏهن درخواست جي جسم ۾ خارج ٿيل مضمونن جون IDs شامل آهن، ته درخواست کي بلاڪ ڪيو ويندو.

پلگ ان کي غلطين جي رپورٽ ڪرڻ کان روڪڻ لاءِ، مون کي هڪ ڪامياب جواب کي جعلي بڻائڻ جي ضرورت آهي. ميليسارچ لاءِ معياري جواب فارميٽ آهي...{"taskUid":0,"status":"enqueued"}مون بس هي واپس ڪيو، پلگ ان کي اهو سوچڻ تي مجبور ڪيو ته هم وقت سازي ڪامياب ٿي وئي.

ٻيو انٽرسيپٽر جيڪو مون استعمال ڪيوpre_get_postsٿلهو. هي ٿلهو ورڈپریس جي ڊيٽابيس ڪوري تي عمل ڪرڻ کان اڳ شروع ٿئي ٿو. منهنجو منطق اهو آهي ته جڏهن به ڪو ايڊمنسٽريٽر بيڪ اينڊ ۾ ڪو آپريشن ڪندو آهي، يا جڏهن ڪو پلگ ان غير هم وقت ساز/هم وقت ساز آپريشن ڪندو آهي، ته خارج ٿيل IDs کي... ۾ ضم ڪيو وڃي.post__not_inپيرا ميٽرز ۾.

لکڻ کان پوءِ، مون ان کي آزمايو.

پهرين، مان بيڪ اينڊ ڏانهن ويس، خارج ٿيل مضمونن مان هڪ کي کوليو، ڪجهه معمولي تبديليون ڪيون، ۽ اپڊيٽ تي ڪلڪ ڪيو. اهو ڪنهن به غلطي کان سواءِ ڪاميابي سان محفوظ ٿي ويو. پوءِ مون ميليس سرچ بيڪ اينڊ چيڪ ڪيو، ۽ آرٽيڪل جو انڊيڪس تبديل نه ٿيو؛ ڪجهه به نئون ظاهر نه ٿيو.

مون ٻيهر "انڊيڪس پوسٽس" تي ڪلڪ ڪيو ۽ پوري انڊيڪس کي ٻيهر ٺاهيو. ڪجهه دير انتظار ڪرڻ کان پوءِ، مون ميليس سرچ بيڪ اينڊ چيڪ ڪيو. اهي خارج ٿيل مضمون اڃا تائين اتي هئا.

اهو ٿي چڪو آهي.

گهرو تجزيو: ٻٽي انشورنس ميڪانيزم ڪيئن ڪم ڪندو آهي؟

سچ پڇو ته، هن عمل مون کي ڪجهه دلچسپ ڳالهه ياد ڏياري ڇڏي.

توهان کي خبر آهي، 1880 جي ڏهاڪي ۾، جڏهن آمريڪا ۾ بجلي عام ٿي رهي هئي، ڪيترن ئي ڪارخانن جي مالڪن جنريٽر ۽ برقي موٽر خريد ڪرڻ ۽ انهن کي پنهنجن ڪارخانن ۾ نصب ڪرڻ لاءِ تمام گهڻو پئسو خرچ ڪيو. جڏهن ته، انسٽاليشن کان پوءِ، ڪيترن ئي ماڻهن ڏٺو ته پيداوار جي ڪارڪردگي ۾ خاص بهتري نه آئي.

ڇو؟

ڇاڪاڻ ته انهن صرف ٻاڦ واري انجڻ کي برقي موٽر سان تبديل ڪيو، پر ڪارخاني جي مجموعي ترتيب، عمل ۽ انتظام جا طريقا تبديل نه ٿيا. بجلي نئين هئي، پر ان کي استعمال ڪرڻ جو ذهنيت پراڻو هو.

بجلي جي عروج مان حقيقي طور تي فائدو حاصل ڪندڙ اصل ۾ پهريون گروهه هئا جن کي سمجهه ۾ آيو ته "بجلي جو اصل مطلب ڇا آهي." انهن صرف پنهنجو بجلي جو ذريعو تبديل نه ڪيو؛ انهن پنهنجي پوري پيداوار جي عمل کي ٻيهر ڊزائين ڪيو.

ساڳيو ئي AI دور تي لاڳو ٿئي ٿو . ڪيترائي ماڻهو AI کي هڪ اوزار طور استعمال ڪندا آهن، پر ٿورا ماڻهو غور ڪندا آهن ته اهو ڪهڙي بنيادي منطق کي تبديل ڪري ٿو. اوزار پاڻ نئون آهي، پر ان کي استعمال ڪرڻ لاءِ استعمال ٿيندڙ ذهنيت شايد پراڻي رهي.

مثال طور، جڏهن مان ورڈپریس سرچ بلاڪنگ سيٽ اپ ڪري رهيو هوس، جيڪڏهن مان صرف پلگ ان دستاويزن ۾ معياري طريقن تي عمل ڪريان ها ته شايد مان ان کي ڪم نه ڪري سگهان ها. اهو ئي سبب آهي جو اسڪرائي سرچ جو هم وقت سازي منطق هاڻي روايتي "هڪ آرٽيڪل محفوظ ڪريو، هڪ آرٽيڪل کي هم وقت ساز ڪريو" طريقو ناهي رهيو؛ ان ۾ غير هم وقت ساز قطارون، بيچ پروسيسنگ، ۽ ان جي پنهنجي ميڪانيزم جو سيٽ آهي.

توهان کي اهو سمجهڻ جي ضرورت آهي ته هي طريقو ڪيئن ڪم ڪري ٿو ان کان اڳ جو توهان هڪ حقيقي ڪاميابي ڳولي سگهو.

منصوبي جون حدون ۽ احتياطي تدبيرون

تڏهن به، مون کي صاف صاف چوڻ گهرجي ته هي منصوبو به مڪمل ناهي.

ان ۾ هڪ اهم حد آهي: اهو صرف مستقبل جي هم وقت سازي کي منظم ڪري سگهي ٿو ۽ ميليسارچ ۾ موجوده تاريخي رڪارڊ کي خودڪار طريقي سان ختم نٿو ڪري سگهي. ٻين لفظن ۾، جيڪڏهن توهان اڳ ۾ ئي انهن آرٽيڪلن کي هم وقت سازي ڪيو آهي، ته پوءِ به توهان کي ميليسارچ ڊيش بورڊ ۾ يا API ڪمانڊ استعمال ڪندي پراڻي ڊيٽا کي دستي طور تي ختم ڪرڻ جي ضرورت آهي.

هي هڪ ڀيرو ڪرڻ جو ڪم آهي؛ هڪ دفعو اهو ٿي ويو، توهان کي ان بابت وڌيڪ پريشان ٿيڻ جي ضرورت ناهي. پر مون کي اڳ ۾ ئي اهو واضح ڪرڻ جي ضرورت آهي، ته جيئن توهان ڪوڊ کي استعمال ڪرڻ کان پوءِ، توهان کي اهي مضمون اڃا تائين ڳولا جي نتيجن ۾ نه ملن ۽ فرض ڪريو ته ڪوڊ اثر انداز نه ٿيو آهي.

هڪ ٻيو نقطو نوٽ ڪرڻ گهرجي ته هي طريقو ورڈپریس جي بنيادي نيٽ ورڪ ۽ ڊيٽابيس آرڪيٽيڪچر تي ڀاڙي ٿو. جيستائين اسڪرائي سرچ پلگ ان جا مستقبل جا ورجن هن آرڪيٽيڪچر جي بنياد تي ڪم ڪندا رهندا، تيستائين هي انٽرسيپٽر اثرائتو رهندو. بهرحال، جيڪڏهن اهو ڪڏهن به مڪمل طور تي مختلف هم وقت سازي جي ميڪانيزم ڏانهن سوئچ ڪري ٿو، ته پوءِ ٻيهر موافقت ضروري ٿي سگهي ٿي.

سچ پڇو ته، اهو ممڪن ناهي. سڄو ورڈپریس ايڪو سسٽم هن فن تعمير تي ٺهيل آهي، ۽ پلگ ان لاءِ ان کي مڪمل طور تي نظرانداز ڪرڻ عملي طور تي ناممڪن آهي.

عملدرآمد لاءِ ٽي قدمي گائيڊ

/**
 * Scry Search 双保险拦截器：彻底排除指定文章 ID 同步到 Meilisearch
 */
// ==========================================
// 【配置】请在这里填写你想要排除的文章或页面 ID
// ==========================================
define('MEILI_EXCLUDED_IDS', array(1067, 1014, 1474, 34020));


/**
 * 保险一：拦截单篇保存/更新时的网络推送 (方案 A 优化版)
 * 原理：当 WordPress 发送网络请求时，如果发现是发往 meilisearch 且带有排除的 ID，直接掐断
 */
add_filter('pre_http_request', function($preempt, $parsed_args, $url) {
    // 1. 检查是不是发往 Meilisearch 的请求
    if (strpos($url, 'meilisearch') !== false && isset($parsed_args['body'])) {
        $body_content = $parsed_args['body'];

        // 2. 检查请求体里是否包含任何一个被排除的文章 ID
        foreach (MEILI_EXCLUDED_IDS as $id) {
            // 匹配格式如 "id":1067 或 字符串中的 ID
            if (strpos($body_content, (string)$id) !== false) {
                // 找到匹配，直接拦截网络请求，并向插件伪造一个标准的成功响应
                return array(
                    'response' => array('code' => 200, 'message' => 'OK'), 
                    'body'     => '{"taskUid":0,"status":"enqueued"}'
                );
            }
        }
    }
    return $preempt;
}, 10, 3);


/**
 * 保险二：拦截后台全量索引时的数据库查询 (方案 B)
 * 原理：在插件试图从数据库捞取文章列表时，直接将这几个 ID 从查询结果中剔除
 */
add_action('pre_get_posts', function($query) {
    // 仅在后台管理员操作，或者插件执行异步同步时生效
    if (is_admin() || (defined('DOING_ASYNC') && DOING_ASYNC)) {

        // 获取当前查询已经存在的排除 ID（如果有的话）
        $current_excluded = $query->get('post__not_in');
        if (!is_array($current_excluded)) {
            $current_excluded = array();
        }

        // 将我们的专属排除 ID 合并进去
        $query->set('post__not_in', array_merge($current_excluded, MEILI_EXCLUDED_IDS));
    }
});

آخر ۾، اچو ته آپريشن جي مرحلن جو خلاصو ڪريون.

پهرين، ڪوڊ کي پنهنجي functions.php فائل جي بلڪل تري ۾ ڪاپي ڪريو، يا ڪوڊ سنيپيٽس پلگ ان استعمال ڪندي ان کي شامل ڪريو. پوءِ، مٿي تي...defineصف ۾، ان مضمون يا صفحي جي ID داخل ڪريو جنهن کي توهان خارج ڪرڻ چاهيو ٿا.

ٻيو قدم تاريخي انڊيڪس کي صاف ڪرڻ آهي. پنهنجي ميليس سرچ ڊيش بورڊ ۾ لاگ ان ڪريو، يا خارج ٿيل آرٽيڪلز لاءِ پراڻي انڊيڪس ڊيٽا کي دستي طور تي ختم ڪرڻ لاءِ API ڪمانڊ استعمال ڪريو.

ٽيون قدم ٽيسٽنگ آهي. بيڪ اينڊ ڏانهن وڃو ۽ خارج ٿيل مضمون ۾ ڪا به معمولي تبديلي ڪريو، اپڊيٽ تي ڪلڪ ڪريو، ۽ پوءِ ميليس سرچ بيڪ اينڊ چيڪ ڪريو. جيڪڏهن ڪو نئون انڊيڪس ظاهر نه ٿئي ته، بلاڪنگ اثر انداز ٿي چڪي آهي.

سچ پڇو ته، مون کي هميشه هن قسم جي ٽيڪنيڪل شيئرنگ آرٽيڪل لکڻ بابت ٿورو ڏوهه محسوس ٿيو آهي.

جيڪي شيون مان شيئر ڪريان ٿو اهي ڪجهه ماڻهن لاءِ ڪارآمد ٿي سگهن ٿيون، پر ٻين لاءِ اهي صرف بنيادي ڪم ٿي سگهن ٿيون.

پر هن ڀيري ورڈپریس سرچ بلاڪنگ کي لاڳو ڪرڻ جو عمل واقعي بصيرت وارو هو. گهڻو ڪري، اسان کي جيڪي مسئلا درپيش اچن ٿا اهي حل جي کوٽ جي ڪري نه آهن، پر ان ڪري جو اسان جي سوچ موجوده فريم ورڪ جي ڪري محدود آهي.

اسڪري سرچ پلگ ان هڪ فلٽرنگ ٿلهو فراهم ڪري ٿو، جيڪو اسان کي يقين ڏياري ٿو ته هي واحد آپشن آهي. بهرحال، ورڈپریس جو پورو فن تعمير تمام گهڻو امڪان پيش ڪري ٿو. نيٽ ورڪ ليئر تي مداخلت حاصل ڪري سگهجي ٿي، ۽ اهو ڊيٽابيس ليئر تي پڻ ڪري سگهجي ٿو. جيستائين توهان سوچڻ لاءِ تيار آهيو، هميشه هڪ طريقو آهي.

انهيءَ ڪري مون کي انهن ٽيڪنيڪل گيجٽس سان ڇيڙڇاڙ ڪرڻ ۾ مزو ايندو آهي. اهو ڏيکارڻ يا متاثر ڪندڙ ظاهر ٿيڻ جي ڪوشش ڪرڻ بابت ناهي. اهو صرف ان ڪري آهي جو ڪنهن مسئلي کي مڪمل طور تي سمجهڻ جو احساس ناقابل يقين حد تائين اطمينان بخش آهي.

بلڪل هن ڀيري وانگر، شروعاتي مونجهاري کان وٺي، وچ ۾ غور ڪرڻ تائين، آخري حل تائين، سڄو عمل هڪ معما حل ڪرڻ جهڙو هو.

راز حل ٿي ويو آهي، جواب ظاهر ٿي ويو آهي، اهو ظاهر ٿيو ته اهو تمام سادو هو.

پر جيڪڏهن توهان ان مونجهاري واري عمل مان نه گذريا آهيو، ته پوءِ توهان ڪڏهن به هن سادي خوشي کي سمجهي نه سگهندا.

هاڻي جڏهن ته توهان هيستائين پڙهي چڪا آهيو، جيڪڏهن توهان کي اهو مددگار لڳو، مهرباني ڪري ان کي پسند ڪريو ۽ شيئر ڪريو. جيڪڏهن توهان پهرين اپڊيٽ حاصل ڪرڻ چاهيو ٿا، ته توهان مون کي فالو پڻ ڪري سگهو ٿا.

منهنجو مضمون پڙهڻ لاءِ مهرباني. ايندڙ ڀيري ملنداسين.