Si ta përjashtoni plotësisht një ID specifike postimi nga WordPress dhe ta sinkronizoni atë me Meilisearch (Shtojca e Kërkimit Scry në Praktikë)

Kohët e fundit kam punuar në një faqe interneti WordPress dhe doja të shtoja një motor kërkimi me performancë të lartë në të gjithë faqen. Pas shumë kërkimesh, zgjodha Meilisearch dhe e shoqërova atë me një plugin të quajtur Scry Search.

Në fillim shkoi mirë. E instalova plugin-in, e konfigurova dhe indeksi u gjenerua automatikisht. Shpejtësia e kërkimit ishte shumë e shpejtë dhe përvoja ishte vërtet e shkëlqyer.

Por këtu lind problemi.

Në faqen e internetit ka disa artikuj të pazakontë. Disa janë për testim të brendshëm, disa janë faqe destinacioni të dedikuara për klientë të caktuar dhe të tjerë janë përmbajtje e papërfunduar që nuk duam ta fshijmë. Më duhet që këto ID artikujsh të zhduken plotësisht nga rezultatet e kërkimit.

Nuk mjafton që nuk mund të gjendet; është se nuk mund të jetë as në indeksin e Meilisearch.

Mendova se kjo ishte e thjeshtë; është thjesht çështje përjashtimi i disa ID-ve. Dokumentacioni i shtojcës duhet të ketë grepat përkatës; thjesht shtoni një filtër dhe është gati.

Siç doli, gabohesha.

Pse dështojnë metodat konvencionale të përgjimit?

Së pari provova grepin e filtrit të përmendur në dokumentacionin zyrtar. Shtova disa rreshta kodi te functions.php, e ruajta, e rifreskova backend-in dhe e riindeksova.

Pastaj kontrollova backend-in e Meilisearch.

Ato artikuj janë ende aty.

U shtangova.

Mendova se kisha shkruar kodin e gabuar, kështu që e kontrollova disa herë, por nuk kishte asgjë të gabuar. Pastaj kërkova në GitHub Problems të plugin-it dhe zbulova se disa persona të tjerë kishin hasur probleme të ngjashme.

Rezulton se shtojca Scry Search përdor një mekanizëm asinkron të radhës së detyrave për të shmangur ngadalësimin e procesit të ruajtjes në sfond. Kjo do të thotë që kur klikoni "Ruaj Artikullin" në sfond, të dhënat mund të futen menjëherë në një tabelë detyrash të personalizuara, duke anashkaluar filtrimin e rregullt të artikullit të vetëm.

Ajo që është edhe më e fshehtë është se kur klikoni "Postimet e Indeksit" në sfond për të rigjeneruar indeksin global, shtojca kryen drejtpërdrejt një pyetje në bazën e të dhënave në nivelin bazë. Në këtë pikë, grepi i filtrit që shtuat më parë nuk ka kurrë mundësi të ekzekutohet.

Me fjalë të tjera, metodat konvencionale të bllokimit hyjnë në fuqi vetëm në momentin që e ruani manualisht artikullin. Por logjika e sinkronizimit të Scry Search është shumë më komplekse nga sa mund ta imagjinoni.

Kodi bazë i interceptorit të sigurimit të dyfishtë

Pasi mendova për këtë, kuptova se kjo çështje nuk mund të lihej kështu.

Meqenëse grepi konvencional kontrollon vetëm pikën e hyrjes së "ruajtjes së një artikulli të vetëm", ​​duhet të gjej një mënyrë për ta bllokuar atë edhe nga vende të tjera.

Kam dalë me dy rrugë.

Problemi i parë është fundi i transmetimit në rrjet. Qoftë sinkronizim i një artikulli të vetëm apo sinkronizim në grup, të dhënat përfundimtare duhet të dërgohen në serverin Meilisearch nëpërmjet kërkesave HTTP, apo jo? Pra, para se të dërgoj kërkesën HTTP, duhet të kontrolloj nëse trupi i kërkesës përmban ID-të e atyre artikujve të përjashtuar. Nëse po, duhet ta bllokoj drejtpërdrejt kërkesën që të mos dërgohet.

Pika e dytë ka të bëjë me pyetjen në bazën e të dhënave. Meqenëse plugin-i e merr listën e artikujve direkt nga baza e të dhënave gjatë indeksimit në grup, unë do t'i heq ato ID specifike nga rezultatet e pyetjes përpara se të ekzekutoj pyetjen në bazën e të dhënave. Nga perspektiva e plugin-it, këto artikuj nuk ekzistojnë fare, kështu që nuk do të merren.

Dy shtigje, siguri e dyfishtë. Nëse një shteg nuk mund të bllokohet, ekziston një tjetër si rezervë.

Pasi e kuptova, fillova të shkruaja kod.

Për interceptorin e parë, përdora atë vendas të WordPress-it.pre_http_requestFiltri. Ky grep aktivizohet përpara se WordPress të bëjë ndonjë kërkesë HTTP. Logjika ime është se do të zbulojë nëse URL-ja e kërkuar përmban...meilisearchNëse trupi i kërkesës përmban ID-të e artikujve të përjashtuar, kërkesa do të bllokohet.

Për të parandaluar që shtojca të raportojë gabime, më duhet gjithashtu të falsifikoj një përgjigje të suksesshme. Formati standard i përgjigjes për Meilisearch është...{"taskUid":0,"status":"enqueued"}Unë thjesht e ktheva këtë, duke e bërë plugin-in të mendonte se sinkronizimi ishte i suksesshëm.

Interceptori i dytë që përdorapre_get_postsGrepi. Ky grep aktivizohet përpara se WordPress të ekzekutojë një pyetje në bazën e të dhënave. Logjika ime është që sa herë që një administrator kryen një operacion në backend, ose kur një plugin kryen operacione asinkrone/sinkrone, ID-të e përjashtuara duhet të bashkohen në...post__not_inNë parametrat.

Pasi mbarova së shkruari, e testova.

Së pari, shkova në backend, hapa një nga artikujt e përjashtuar, bëra disa ndryshime të vogla dhe klikova përditësimin. U ruajt me sukses pa asnjë gabim. Pastaj kontrollova backend-in e Meilisearch dhe indeksi i artikullit mbeti i pandryshuar; nuk ishte shfaqur asgjë e re.

Klikova përsëri te "Indeksi i Postimeve" dhe e rindërtova të gjithë indeksin. Pasi prita pak, kontrollova backend-in e Meilisearch. Ato artikuj të përjashtuar ishin ende aty.

Është bërë.

Analizë e thelluar: Si funksionon mekanizmi i sigurimit të dyfishtë?

Të them të drejtën, ky proces më kujtoi diçka mjaft interesante.

E dini, në vitet 1880, kur energjia elektrike sapo kishte filluar të përhapej në Shtetet e Bashkuara, shumë pronarë fabrikash shpenzonin shumë para për të blerë gjeneratorë dhe motorë elektrikë dhe për t'i instaluar ato në fabrikat e tyre. Megjithatë, pas instalimit, shumë njerëz zbuluan se efikasiteti i prodhimit nuk u përmirësua ndjeshëm.

为什么?

Sepse ata thjesht e zëvendësuan motorin me avull me një motor elektrik, por planimetria e përgjithshme, proceset dhe metodat e menaxhimit të fabrikës mbetën të pandryshuara. Energjia elektrike ishte e re, por mënyra e përdorimit të saj ishte e vjetër.

Ata që përfituan vërtet nga bumi i energjisë elektrike ishin në fakt grupi i parë që kuptoi "çfarë do të thotë në të vërtetë energjia elektrike". Ata jo vetëm që ndryshuan burimin e energjisë; ata ridizajnuan të gjithë procesin e tyre të prodhimit.

E njëjta gjë vlen edhe për epokën e inteligjencës artificiale . Shumë njerëz e përdorin inteligjencën artificiale si mjet, por pak veta e marrin në konsideratë logjikën themelore që ajo ndryshon. Vetë mjeti është i ri, por mënyra e të menduarit e përdorur për ta përdorur atë mund të mbetet e vjetëruar.

Për shembull, kur po konfiguroja bllokimin e kërkimit në WordPress, ndoshta nuk do të kisha qenë në gjendje ta bëja të funksiononte nëse do të ndiqja metodat standarde në dokumentacionin e shtojcës. Kjo ndodh sepse logjika e sinkronizimit të Scry Search nuk është më qasja tradicionale "ruaj një artikull, sinkronizo një artikull"; ajo ka radhë asinkrone, përpunim në grup dhe grupin e vet të mekanizmave.

Duhet të kuptosh se si funksionon ky mekanizëm përpara se të gjesh një përparim të vërtetë.

Kufizimet dhe masat paraprake të planit

Megjithatë, duhet ta them sinqerisht se as ky plan nuk është perfekt.

Ka një kufizim të rëndësishëm: mund të menaxhojë vetëm sinkronizimet e ardhshme dhe nuk mund të fshijë automatikisht të dhënat ekzistuese historike në Meilisearch. Me fjalë të tjera, nëse i keni sinkronizuar tashmë ato artikuj, prapëseprapë duhet të fshini manualisht të dhënat e vjetra në panelin e Meilisearch ose duke përdorur komandat API.

Kjo është një detyrë që bëhet vetëm një herë; pasi të përfundojë, nuk keni pse të shqetësoheni më për të. Por duhet ta sqaroj këtë paraprakisht, në mënyrë që pasi të keni vendosur kodin, të mos i gjeni ato artikuj ende në rezultatet e kërkimit dhe të supozoni se kodi nuk ka hyrë në fuqi.

Një pikë tjetër për t’u theksuar është se kjo qasje mbështetet në rrjetin themelor dhe arkitekturën e bazës së të dhënave të WordPress. Për sa kohë që versionet e ardhshme të shtojcës Scry Search vazhdojnë të funksionojnë bazuar në këtë arkitekturë, ky ndërprerës do të mbetet efektiv. Megjithatë, nëse ndonjëherë kalon në një mekanizëm sinkronizimi krejtësisht të ndryshëm, atëherë mund të jetë i nevojshëm ripërshtatja.

Megjithatë, për të qenë i sinqertë, kjo është e pamundur. I gjithë ekosistemi i WordPress është ndërtuar mbi këtë arkitekturë dhe është praktikisht e pamundur që plugin-et ta anashkalojnë plotësisht atë.

Udhëzues me tre hapa për zbatimin

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

Së fundmi, le të përmbledhim hapat e operacionit.

Së pari, kopjoni kodin në fund të skedarit tuaj functions.php ose shtojeni atë duke përdorur shtojcën Code Snippets. Pastaj, në krye...defineNë varg, futni ID-në e artikullit ose faqes që dëshironi të përjashtoni.

Hapi i dytë është pastrimi i indekseve historike. Hyni në panelin tuaj të Meilisearch ose përdorni komandat API për të fshirë manualisht të dhënat e vjetra të indeksit për artikujt e përjashtuar.

Hapi i tretë është testimi. Shkoni në backend dhe bëni çdo ndryshim të vogël në artikullin e përjashtuar, klikoni përditëso dhe më pas kontrolloni backend-in e Meilisearch. Nëse nuk shfaqet ndonjë indeks i ri, bllokimi ka hyrë në fuqi.

Të them të drejtën, gjithmonë jam ndjerë pak fajtore për shkrimin e këtyre lloj artikujsh teknikë për ndarjen.

Gjërat që ndaj mund të jenë të dobishme për disa njerëz, por për të tjerët mund të jenë thjesht operacione bazë.

Por procesi i zbatimit të bllokimit të kërkimit në WordPress këtë herë ishte vërtet i dobishëm. Shpesh, problemet që hasim nuk vijnë për shkak të mungesës së zgjidhjeve, por përkundrazi sepse të menduarit tonë është i kufizuar nga kornizat ekzistuese.

Shtojca Scry Search ofron një grep filtrimi, duke na bërë të besojmë se ky është i vetmi opsion. Megjithatë, e gjithë arkitektura e WordPress ofron shumë më tepër mundësi. Ndërhyrja mund të arrihet në shtresën e rrjetit dhe mund të bëhet edhe në shtresën e bazës së të dhënave. Për sa kohë që jeni të gatshëm të mendoni, gjithmonë ka një mënyrë.

Kjo është arsyeja pse më pëlqen të eksperimentoj me këto pajisje teknike. Nuk ka të bëjë me mburrjen apo përpjekjen për t'u dukur mbresëlënës. Është thjesht sepse ndjesia e të kuptuarit të plotë të një problemi është jashtëzakonisht e kënaqshme.

Ashtu si këtë herë, që nga konfuzioni fillestar, te reflektimi në mes, e deri te zgjidhja përfundimtare, i gjithë procesi ishte si zgjidhja e një enigme.

Misteri është zgjidhur, përgjigjja është zbuluar, doli që ishte kaq e thjeshtë.

Por nëse nuk e ke kaluar atë proces konfuz, nuk do ta kuptosh kurrë këtë gëzim të thjeshtë.

Tani që e lexuat deri këtu, nëse e gjetët të dobishme, ju lutem pëlqeni dhe shpërndajeni. Nëse doni të merrni përditësime të parat, mund të më ndiqni edhe mua.

Faleminderit që lexuat artikullin tim. Shihemi herën tjetër.