WordPressтен белгилүү бир посттун идентификаторун кантип толугу менен чыгарып салуу жана аны Meilisearch менен синхрондоштуруу керек (Scry Search плагини иш жүзүндө)

Жакында эле WordPress веб-сайтынын үстүндө иштеп жатам жана сайт боюнча жогорку өндүрүмдүү издөө системасын кошкум келди. Көп издегенден кийин, мен Meilisearchти тандап, аны Scry Search деп аталган плагин менен жупташтырдым.

Башында баары жакшы өттү. Мен плагинди орнотуп, конфигурацияладым, ошондо индекс автоматтык түрдө түзүлдү. Издөө ылдамдыгы чагылгандай тез болду жана тажрыйба чындап эле эң сонун болду.

Бирок бул жерде маселе келип чыгат.

Вебсайтта бир нече адаттан тыш макалалар бар. Айрымдары ички сыноо үчүн, айрымдары белгилүү бир кардарлар үчүн арналган атайын баракчалар, ал эми башкалары биз жок кылгыбыз келбеген бүтпөгөн мазмун. Мага бул макалалардын идентификаторлору издөө натыйжаларынан толугу менен жок болушу керек.

Анын табылбай жатканы жетишсиз; ал тургай Meilisearch индексинде да болушу мүмкүн эмес.

Мен муну жөнөкөй деп ойлогом; жөн гана бир нече IDлерди алып салуу керек. Плагиндин документтеринде тиешелүү илгичтер болушу керек; жөн гана чыпка кошсоңуз, болду.

Көрсө, мен жаңылыптырмын.

Эмне үчүн кадимки кармоо ыкмалары натыйжасыз?

Мен алгач расмий документтерде айтылган чыпкалоочу илмекти колдонуп көрдүм. functions.php файлына бир нече сап код кошуп, сактап, серверди жаңыртып, кайра индекстедим.

Анан мен Meilisearch серверин текшердим.

Ал макалалар азыр да бар.

Мен таң калып калдым.

Мен туура эмес код жазып алдым деп ойлогом, ошондуктан аны бир нече жолу текшердим, бирок эч кандай ката жок болчу. Андан кийин плагиндин GitHub көйгөйлөрүн издеп, башка бир нече адамдар да ушул сыяктуу көйгөйлөргө туш болушканын байкадым.

Көрсө, Scry Search плагини фондо сактоо процессин жайлатпоо үчүн асинхрондуу тапшырма кезегинин механизмин колдонот экен. Бул фондо "Макаланы сактоо" баскычын басканда, маалыматтар кадимки бир макаланы чыпкалоону айланып өтүп, заматта ыңгайлаштырылган тапшырма таблицасына киргизилиши мүмкүн дегенди билдирет.

Андан да коркунучтуусу, глобалдык индексти кайра түзүү үчүн фондо "Индекс билдирүүлөрүн" чыкылдатканыңызда, плагин түздөн-түз негизги деңгээлде топтук маалымат базасынын суроо-талабын аткарат. Бул учурда, сиз мурда кошкон чыпкалоочу илмек эч качан аткарылбайт.

Башкача айтканда, кадимки бөгөттөө ыкмалары макаланы кол менен сактаган учурда гана күчүнө кирет. Бирок Scry Search'тун синхрондоштуруу логикасы сиз элестеткенден алда канча татаал.

Кош камсыздандыруу интерсепторунун негизги коду

Ойлонуп көргөндөн кийин, бул маселени ушул бойдон калтырууга болбой турганын түшүндүм.

Кадимки илгич "бир макаланы сактоо" кирүү чекитин гана башкаргандыктан, мен аны башка жерлерден да бөгөттөп салуунун жолун табышым керек.

Мен эки жол ойлоп таптым.

Биринчи маселе - тармактын өткөрүү учу. Бир макаланы синхрондоштуруубу же топтомдук синхрондоштуруубу, акыркы маалыматтар дагы эле HTTP сурамдары аркылуу Meilisearch серверине жөнөтүлүшү керек, туурабы? Андыктан, HTTP сурамын жөнөтүүдөн мурун, сурамдын негизги бөлүгүндө ошол алынып салынган макалалардын идентификаторлору бар-жогун текшеришим керек. Эгер ошондой болсо, сурамдын жөнөтүлүшүн түздөн-түз бөгөттөп коюшум керек.

Экинчи жагдай маалымат базасынын суроо-талабына тиешелүү. Плагин макалалардын тизмесин пакеттик индекстөө учурунда түз эле маалымат базасынан алгандыктан, мен маалымат базасынын суроо-талабын аткаруудан мурун ошол конкреттүү идентификаторлорду суроо-талаптын жыйынтыктарынан алып салам. Плагиндин көз карашынан алганда, бул макалалар такыр жок, ошондуктан алар алынбайт.

Эки жол, кош камсыздандыруу. Эгер бир жолду бөгөттөө мүмкүн болбосо, анда камдык катары дагы бири бар.

Муну түшүнгөндөн кийин, мен код жаза баштадым.

Биринчи интерсептор үчүн мен WordPressтин түпнуска версиясын колдондум.pre_http_requestФильтр. Бул илмек WordPress кандайдыр бир HTTP суроо-талаптарын жасоодон мурун ишке кирет. Менин логикам боюнча, ал суралган URLде... бар же жок экенин аныктайт...meilisearchЭгерде суроо-талаптын негизги бөлүгүндө алынып салынган макалалардын идентификаторлору камтылса, суроо-талап бөгөттөлөт.

Плагин каталар жөнүндө кабар бербеши үчүн, мен ийгиликтүү жоопту жасалма түрдө түзүшүм керек. Meilisearch үчүн стандарттуу жооп форматы...{"taskUid":0,"status":"enqueued"}Мен жөн гана муну кайтарып бердим, плагин синхрондоштуруу ийгиликтүү болду деп ойлоду.

Мен колдонгон экинчи интерсепторpre_get_postsИлмек. Бул илмек WordPress маалымат базасынын суроо-талабын аткарганга чейин ишке киргизилет. Менин логикам боюнча, администратор серверде операция жасаганда же плагин асинхрондук/синхрондук операцияларды аткарганда, чыгарылган IDлер... бириктирилиши керек.post__not_inПараметрлерде.

Аны жазып бүткөндөн кийин, мен аны сынап көрдүм.

Алгач, мен серверге өтүп, алынып салынган макалалардын бирин ачып, бир нече кичинекей өзгөртүүлөрдү киргизип, "Жаңыртуу" баскычын бастым. Ал эч кандай катасыз ийгиликтүү сакталды. Андан кийин Meilisearch серверин текшердим, макаланын индекси өзгөрүүсүз калды; жаңы эч нерсе пайда болгон жок.

Мен "Индекстеги билдирүүлөрдү" кайра басып, индексти толугу менен кайра түздүм. Бир аз күткөндөн кийин, Meilisearch серверин текшердим. Ал алынып салынган макалалар дагы эле ошол жерде экен.

Бүттү.

Терең талдоо: Кош камсыздандыруу механизми кандайча иштейт?

Чынын айтсам, бул процесс мага абдан кызыктуу нерсени эске салды.

Билесизби, 1880-жылдары, АКШда электр энергиясы жаңыдан кеңири жайылып келе жатканда, көптөгөн завод ээлери генераторлорду жана электр кыймылдаткычтарын сатып алып, аларды заводдоруна орнотууга көп акча коротушкан. Бирок, орнотулгандан кийин, көптөгөн адамдар өндүрүштүн натыйжалуулугу анчалык деле жакшырбаганын байкашкан.

неге?

Анткени алар буу кыймылдаткычын жөн гана электр кыймылдаткычы менен алмаштырышкан, бирок заводдун жалпы жайгашуусу, процесстери жана башкаруу ыкмалары өзгөрүүсүз калган. Электр энергиясы жаңы болчу, бирок аны колдонуу боюнча ой жүгүртүү эски болчу.

Электр энергиясынын кескин өсүшүнөн чындап пайда көргөндөр чындыгында "электр энергиясы эмнени билдирерин" түшүнгөн алгачкы топ болушкан. Алар жөн гана энергия булагын өзгөртпөстөн, бүтүндөй өндүрүш процессин кайрадан иштеп чыгышкан.

Ошол эле нерсе жасалма интеллект дооруна да тиешелүү . Көптөгөн адамдар жасалма интеллектти курал катары колдонушат, бирок анын кандай негизги логикага өзгөрөрүн аз эле адамдар ойлошот. Куралдын өзү жаңы, бирок аны колдонууда колдонулган ой жүгүртүү эскирген бойдон калышы мүмкүн.

Мисалы, мен WordPress издөөнү бөгөттөөнү орнотуп жатканда, плагин документтериндеги стандарттуу ыкмаларды гана аткарсам, аны иштете алмак эмесмин. Себеби Scry Search'тун синхрондоштуруу логикасы мындан ары салттуу "бир макаланы сактоо, бир макаланы синхрондоштуруу" ыкмасы эмес; анын асинхрондук кезектери, топтук иштетүүсү жана өзүнүн механизмдери бар.

Чыныгы жетишкендикти табуудан мурун, бул механизм кандайча иштээрин аныктап алышыңыз керек.

Пландын чектөөлөрү жана сактык чаралары

Бирок, ачык айтышым керек, бул план да идеалдуу эмес.

Анын олуттуу чектөөсү бар: ал келечектеги синхрондоштурууларды гана башкара алат жана Meilisearch'теги тарыхый жазууларды автоматтык түрдө өчүрө албайт. Башкача айтканда, эгер сиз ал макалаларды мурунтан эле синхрондоштурган болсоңуз, Meilisearch башкаруу панелиндеги же API буйруктарын колдонуп, эски маалыматтарды кол менен өчүрүшүңүз керек.

Бул бир жолку тапшырма; ал бүткөндөн кийин, сиз бул тууралуу кабатыр болбоңуз. Бирок мен муну алдын ала тактап алышым керек, ошондо сиз кодду жайгаштыргандан кийин, ал макалаларды издөө натыйжаларынан таппайсыз жана код күчүнө кире элек деп ойлобойсуз.

Дагы бир белгилей кетүүчү жагдай, бул ыкма WordPressтин негизги тармактык жана маалымат базасынын архитектурасына таянат. Scry Search плагининин келечектеги версиялары ушул архитектуранын негизинде иштей берсе, бул интерсептор натыйжалуу бойдон калат. Бирок, эгер ал таптакыр башка синхрондоштуруу механизмине өтсө, анда кайра адаптациялоо зарыл болушу мүмкүн.

Бирок, чынын айтсам, бул күмөн. WordPressтин бүтүндөй экосистемасы ушул архитектуранын негизинде курулган жана плагиндердин аны толугу менен айланып өтүшү дээрлик мүмкүн эмес.

Ишке ашыруу боюнча үч кадамдуу колдонмо

/**
 * 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 файлыңыздын эң төмөнкү бөлүгүнө көчүрүңүз же Code Snippets плагинин колдонуп кошуңуз. Андан кийин, жогору жагында...defineМассивге, чыгарып салгыңыз келген макаланын же барактын IDсин киргизиңиз.

Экинчи кадам - ​​тарыхый индекстерди тазалоо. Meilisearch башкаруу панелиңизге кириңиз же алынып салынган макалалардын эски индекс маалыматтарын кол менен жок кылуу үчүн API буйруктарын колдонуңуз.

Үчүнчү кадам - ​​сыноо. Серверге өтүп, чыгарылган макалага кандайдыр бир анча чоң эмес өзгөртүүлөрдү киргизиңиз, "Жаңыртуу" баскычын чыкылдатыңыз, андан кийин Meilisearch серверин текшериңиз. Эгерде жаңы индекс пайда болбосо, бөгөттөө күчүнө кирди.

Чынын айтсам, мен ушул сыяктуу техникалык макалаларды жазганым үчүн ар дайым өзүмдү бир аз күнөөлүү сезип келгем.

Мен бөлүшкөн нерселер кээ бир адамдар үчүн пайдалуу болушу мүмкүн, бирок башкалар үчүн алар жөн гана жөнөкөй операциялар болушу мүмкүн.

Бирок бул жолу WordPress издөөнү бөгөттөөнү ишке ашыруу процесси чындап эле түшүнүктүү болду. Көп учурда биз туш болгон көйгөйлөр чечимдердин жоктугунан эмес, тескерисинче, биздин ой жүгүртүүбүз учурдагы алкактар ​​менен чектелгендиктен болот.

Scry Search плагини чыпкалоочу илмекти камсыз кылат, бул бизди бул жалгыз вариант деп ишендирет. Бирок, WordPressтин бүтүндөй архитектурасы алда канча көп мүмкүнчүлүктөрдү сунуштайт. Тармактык деңгээлде кармоого болот, ошондой эле маалымат базасынын деңгээлинде да жасоого болот. Эгер сиз ойлонууга даяр болсоңуз, ар дайым жол бар.

Ошондуктан мен бул техникалык шаймандар менен иштөөнү жакшы көрөм. Бул мактануу же таасирдүү көрүнүүгө аракет кылуу эмес. Жөн гана көйгөйдү толук түшүнүү сезими укмуштуудай канааттандырарлык болгондуктан.

Дал ушул жолкудай эле, баштапкы башаламандыктан баштап, ортосундагы ой жүгүртүүгө жана акыркы чечимге чейин, бүт процесс табышмакты чечүүгө окшош болду.

Табышмак чечилди, жообу ачылды, көрсө, ал ушунчалык жөнөкөй экен.

Бирок, эгер сиз ал башаламан процесстен өтпөсөңүз, бул жөнөкөй кубанычты эч качан түшүнө албайсыз.

Эми сиз ушуга чейин окуп чыккандан кийин, эгер сизге пайдалуу болсо, жактырып, бөлүшүңүз. Эгер сиз биринчи болуп жаңылыктарды алгыңыз келсе, мени ээрчисеңиз болот.

Макаланы окуганыңыз үчүн рахмат. Кийинки жолу көрүшкөнчө.