Kiel tute ekskludi specifan afiŝan ID-on de WordPress kaj sinkronigi ĝin kun Meilisearch (Scry Search-kromprogramo en praktiko)

Mi lastatempe laboris pri WordPress- retejo kaj volis aldoni alt-efikecan tutretejan serĉilon. Post multe da serĉado, mi elektis Meilisearch kaj kunigis ĝin kun kromprogramo nomata Scry Search.

Komence ĝi iris glate. Mi instalis la kromprogramon, agordis ĝin, kaj la indekso estis generita aŭtomate. La serĉrapideco estis fulmrapida, kaj la sperto estis efektive bonega.

Sed jen venas la problemo.

Estas pluraj nekutimaj artikoloj en la retejo. Kelkaj estas por interna testado, kelkaj estas dediĉitaj surteriĝaj paĝoj por specifaj klientoj, kaj aliaj estas nefinita enhavo, kiun ni ne volas forigi. Mi bezonas, ke ĉi tiuj artikolaj identigiloj tute malaperu el serĉrezultoj.

Ne sufiĉas, ke ĝi ne troveblas; gravas, ke ĝi eĉ ne povas esti en la indekso de Meilisearch.

Mi pensis, ke ĉi tio estas simpla; temas nur pri ekskludo de kelkaj identigiloj. La dokumentaro de la kromprogramo devas havi la respondajn hokojn; nur aldonu filtrilon kaj ĝi estas preta.

Kiel montriĝis, mi eraris.

Kial konvenciaj interkaptaj metodoj malsukcesas?

Mi unue provis la filtrilan hokon menciitan en la oficiala dokumentado. Mi aldonis kelkajn liniojn de kodo al functions.php, konservis ĝin, refreŝigis la internan dosieron, kaj re-indeksis ĝin.

Poste mi kontrolis la internan servon de Meilisearch.

Tiuj artikoloj ankoraŭ estas tie.

Mi estis ŝokita.

Mi pensis, ke mi skribis la malĝustan kodon, do mi kontrolis ĝin plurfoje, sed nenio malĝustas pri ĝi. Poste mi serĉis la GitHub-problemojn de la kromprogramo kaj trovis, ke pluraj aliaj homoj renkontis similajn problemojn.

Montriĝas, ke la kromprogramo Scry Search uzas nesinkronan mekanismon de taskovicigo por eviti malrapidigon de la fona konservadprocezo. Tio signifas, ke kiam vi alklakas "Konservi Artikolon" en la fono, la datumoj povas esti tuj puŝitaj en kutiman taskotabelon, preterirante la kutiman unuopan artikolan filtradon.

Eĉ pli insida estas, ke kiam vi alklakas "Indeksajn Afiŝojn" en la fono por regeneri la tutmondan indekson, la kromprogramo rekte plenumas aron datumbazan serĉdemandon je la subesta nivelo. Ĉe tiu punkto, la filtrila hoko, kiun vi aldonis antaŭe, neniam havas ŝancon ekzekutiĝi.

Alivorte, konvenciaj blokmetodoj nur efikas en la momento kiam vi permane konservas la artikolon. Sed la sinkroniga logiko de Scry Search estas multe pli kompleksa ol vi eble imagas.

Duobla-asekura interkaptista kerna kodo

Post pripensado, mi komprenis, ke ĉi tiu afero ne povas resti tiel.

Ĉar la konvencia hoko nur kontrolas la enirejon por "konservado de unuopa artikolo", mi bezonas trovi manieron bloki ĝin ankaŭ de aliaj lokoj.

Mi elpensis du vojojn.

La unua problemo estas la fina transdono per reto. Ĉu temas pri sinkronigado de unuopa artikolo aŭ aro da sinkronigado, la finaj datumoj ankoraŭ devas esti senditaj al la servilo Meilisearch per HTTP-petoj, ĉu ne? Do, antaŭ ol sendi la HTTP-peton, mi devus kontroli ĉu la korpo de la peto enhavas la identigilojn de tiuj ekskluditaj artikoloj. Se jes, mi devus rekte bloki la sendon de la peto.

La dua punkto koncernas la datumbazan pridemandon. Ĉar la kromprogramo prenas la artikolliston rekte el la datumbazo dum aro-indeksado, mi forigos tiujn specifajn identigilojn el la rezultoj de la pridemando antaŭ ol plenumi la datumbazan pridemandon. El la perspektivo de la kromprogramo, ĉi tiuj artikoloj tute ne ekzistas, do ili ne estos prenitaj.

Du vojoj, duobla asekuro. Se unu vojo ne povas esti blokita, ekzistas alia kiel rezerva.

Post eltrovado de ĝi, mi komencis skribi kodon.

Por la unua interkaptilo, mi uzis la denaskan de WordPress.pre_http_requestLa filtrilo. Ĉi tiu hoko ekfunkcias antaŭ ol WordPress faras iujn ajn HTTP-petojn. Mia logiko estas, ke ĝi detektos ĉu la petita URL enhavas...meilisearchSe la peto-korpo enhavas la identigilojn de la ekskluditaj artikoloj, la peto estos blokita.

Por malhelpi la kromprogramon raporti erarojn, mi ankaŭ bezonas falsi sukcesan respondon. La norma respondformato por Meilisearch estas...{"taskUid":0,"status":"enqueued"}Mi simple redonis ĉi tion, igante la kromprogramon pensi, ke la sinkronigado sukcesis.

La dua interkaptisto, kiun mi uzispre_get_postsLa hoko. Ĉi tiu hoko estas ekigita antaŭ ol WordPress efektivigas datumbazan demandon. Mia logiko estas, ke kiam ajn administranto plenumas operacion en la servilo, aŭ kiam kromprogramo plenumas nesinkronajn/sinkronajn operaciojn, la ekskluditaj identigiloj devus esti kunfanditaj en la...post__not_inEn la parametroj.

Post kiam mi finis skribi ĝin, mi testis ĝin.

Unue, mi iris al la interna komputilo, malfermis unu el la ekskluditaj artikoloj, faris kelkajn malgrandajn ŝanĝojn, kaj alklakis ĝisdatigi. Ĝi sukcese konserviĝis sen eraroj. Poste mi kontrolis la internan komputilo de Meilisearch, kaj la indekso de la artikolo restis senŝanĝa; nenio nova aperis.

Mi denove alklakis "Indeksaj Afiŝoj" kaj rekonstruis la tutan indekson. Post iom da atendado, mi kontrolis la Meilisearch-interfacon. Tiuj ekskluditaj artikoloj ankoraŭ estis tie.

Ĝi estas farita.

Profunda analizo: Kiel funkcias la duobla asekurmekanismo?

Verdire, ĉi tiu procezo memorigis min pri io sufiĉe interesa.

Nu, en la 1880-aj jaroj, kiam elektro ĵus komencis disvastiĝi en Usono, multaj fabrikposedantoj elspezis multe da mono por aĉeti generatorojn kaj elektromotorojn kaj instali ilin en siaj fabrikoj. Tamen, post la instalado, multaj homoj trovis, ke la produktadefikeco ne pliboniĝis signife.

kial?

Ĉar ili simple anstataŭigis la vapormaŝinon per elektromotoro, sed la ĝenerala aranĝo, procezoj kaj administraj metodoj de la fabriko restis senŝanĝaj. La elektro estis nova, sed la pensmaniero pri ĝia uzado estis malnova.

Tiuj, kiuj vere profitis de la elektrohaŭso, estis fakte la unua grupo, kiu komprenis "kion elektro vere signifas." Ili ne nur ŝanĝis sian energifonton; ili restrukturis sian tutan produktadprocezon.

La samo validas por la epoko de artefarita inteligenteco . Multaj homoj uzas artefaritan inteligentecon kiel ilon, sed malmultaj konsideras, kian subestan logikon ĝi ŝanĝas. La ilo mem estas nova, sed la pensmaniero uzata por uzi ĝin eble restas malmoderna.

Ekzemple, kiam mi agordis serĉblokadon en WordPress, mi verŝajne ne povus funkcigi ĝin se mi nur sekvus la normajn metodojn en la dokumentado de la kromprogramo. Tio estas ĉar la sinkroniga logiko de Scry Search jam ne estas la tradicia aliro "konservi unu artikolon, sinkronigi unu artikolon"; ĝi havas nesinkronajn atendovicojn, aro-prilaboradon kaj sian propran aron da mekanismoj.

Vi devas eltrovi kiel ĉi tiu mekanismo funkcias antaŭ ol vi povas trovi veran sukceson.

Limigoj kaj antaŭzorgoj de la plano

Tamen, mi devas sincere diri, ke ankaŭ ĉi tiu plano ne estas perfekta.

Ĝi havas gravan limigon: ĝi povas administri nur estontajn sinkronigojn kaj ne povas aŭtomate forigi ekzistantajn historiajn registrojn en Meilisearch. Alivorte, se vi jam sinkronigis tiujn artikolojn, vi ankoraŭ bezonas permane forigi la malnovajn datumojn en la Meilisearch-panelo aŭ per API-komandoj.

Ĉi tio estas unufoja tasko; post kiam ĝi estas farita, vi ne plu bezonas zorgi pri ĝi. Sed mi devas klarigi tion anticipe, por ke post kiam vi deplojos la kodon, vi ne trovu tiujn artikolojn ankoraŭ en la serĉrezultoj kaj supozu, ke la kodo ne ekvalidis.

Alia rimarkinda punkto estas, ke ĉi tiu aliro dependas de la subesta reto kaj datumbaza arkitekturo de WordPress. Tiel longe kiel estontaj versioj de la kromprogramo Scry Search daŭre funkcios surbaze de ĉi tiu arkitekturo, ĉi tiu interkaptilo restos efika. Tamen, se ĝi iam ŝanĝos al tute malsama sinkroniga mekanismo, tiam readapto povus esti necesa.

Tamen, por esti honesta, tio estas neverŝajna. La tuta WordPress-ekosistemo estas konstruita sur ĉi tiu arkitekturo, kaj estas preskaŭ neeble por kromaĵoj tute preteriri ĝin.

Tri-ŝtupa gvidilo por efektivigo

/**
 * 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));
    }
});

Fine, ni resumu la paŝojn de la operacio.

Unue, kopiu la kodon al la fundo de via functions.php dosiero, aŭ aldonu ĝin per la kromprogramo Code Snippets. Poste, supre...defineEn la tabelo, enigu la ID-on de la artikolo aŭ paĝo, kiun vi volas ekskludi.

La dua paŝo estas purigi historiajn indeksojn. Ensalutu al via Meilisearch-panelo, aŭ uzu API-komandojn por permane forigi la malnovajn indeksajn datumojn por la ekskluditaj artikoloj.

La tria paŝo estas testado. Iru al la servilo kaj faru iujn ajn malgrandajn ŝanĝojn al la ekskludita artikolo, alklaku ĝisdatigi, kaj poste kontrolu la servilon de Meilisearch. Se neniu nova indekso aperas, la blokado ekvalidis.

Verdire, mi ĉiam sentis min iom kulpa pri verkado de ĉi tiaj artikoloj pri teknika kunhavigo.

La aferoj, kiujn mi dividas, eble estos utilaj por iuj homoj, sed por aliaj ili eble estos nur bazaj operacioj.

Sed la procezo de efektivigo de serĉblokado en WordPress ĉi-foje estis vere komprenema. Ofte, la problemoj, kiujn ni renkontas, ne ŝuldiĝas al manko de solvoj, sed prefere ĉar nia pensado estas limigita de ekzistantaj kadroj.

La kromprogramo Scry Search provizas filtran hokon, kio igas nin kredi, ke ĉi tio estas la sola eblo. Tamen, la tuta arkitekturo de WordPress ofertas multe pli da eblecoj. Interkapto povas esti atingita ĉe la reta tavolo, kaj ĝi ankaŭ povas esti farita ĉe la datumbaza tavolo. Kondiĉe ke vi pretas pensi, ĉiam ekzistas maniero.

Tial mi ĝuas ludi kun ĉi tiuj teknikaj noviletoj. Ne temas pri fanfaroni aŭ provi ŝajni impona. Estas simple ĉar la sento de tute kompreni problemon estas nekredeble kontentiga.

Ĝuste kiel ĉi-foje, de la komenca konfuzo, ĝis la reflekto en la mezo, ĝis la fina solvo, la tuta procezo estis kiel solvi enigmon.

La mistero estas solvita, la respondo estas rivelita, montriĝas, ke ĝi estis tiel simpla.

Sed se vi ne trairis tiun konfuzan procezon, vi neniam komprenos ĉi tiun simplan ĝojon.

Nun kiam vi legis ĝis ĉi tie, se vi trovis ĝin utila, bonvolu ŝati kaj dividi ĝin. Se vi volas ricevi ĝisdatigojn unue, vi ankaŭ povas sekvi min.

Dankon pro legado de mia artikolo. Ĝis revido.