Hvernig á að útiloka tiltekið færsluauðkenni alveg úr WordPress og samstilla það við Meilisearch (Scry Search viðbótin í reynd)

Ég hef nýlega verið að vinna í WordPress vefsíðu og vildi bæta við afkastamikilli leitarvél fyrir alla síðuna. Eftir mikla leit valdi ég Meilisearch og paraði það við viðbót sem heitir Scry Search.

Þetta gekk vel í fyrstu. Ég setti upp viðbótina, stillti hana og vísitalan var búin til sjálfkrafa. Leitarhraðinn var eldingarhraður og upplifunin var sannarlega frábær.

En hér kemur vandamálið.

Það eru nokkrar óvenjulegar greinar á vefsíðunni. Sumar eru ætlaðar til innri prófana, sumar eru lendingarsíður fyrir ákveðna viðskiptavini og aðrar eru óklárað efni sem við viljum ekki eyða. Ég þarf að þessi greinarauðkenni hverfi alveg úr leitarniðurstöðum.

Það er ekki nóg að það finnist ekki; það er heldur að það er ekki einu sinni í vísitölu Meilisearch.

Ég hélt að þetta væri einfalt; það væri bara spurning um að útiloka nokkur auðkenni. Viðbótargögnin verða að hafa samsvarandi króka; bættu bara við síu og það er búið.

Eins og kom í ljós hafði ég rangt fyrir mér.

Hvers vegna mistakast hefðbundnar hlerunaraðferðir?

Ég prófaði fyrst síunarkrókann sem minnst er á í opinberu skjölunum. Ég bætti við nokkrum línum af kóða í functions.php, vistaði það, uppfærði bakgrunninn og endurskráði það.

Svo athugaði ég Meilisearch bakendann.

Þessar greinar eru enn til staðar.

Ég var agndofa.

Ég hélt að ég hefði skrifað rangan kóða, svo ég athugaði hann nokkrum sinnum, en það var ekkert að honum. Svo leitaði ég í GitHub Issues viðbótarinnar og komst að því að nokkrir aðrir höfðu lent í svipuðum vandamálum.

Það kemur í ljós að Scry Search viðbótin notar ósamstilltan verkefnaröðunarkerfi til að forðast að hægja á vistunarferlinu í bakgrunni. Þetta þýðir að þegar smellt er á „Vista grein“ í bakgrunni geta gögnin verið færð samstundis yfir í sérsniðna verkefnatöflu, án þess að nota venjulega síun fyrir hverja grein.

Það sem er enn lúmskara er að þegar þú smellir á „Vísa færslur“ í bakgrunni til að endurnýja alþjóðlegu vísitöluna, þá framkvæmir viðbótin beint hópfyrirspurn í gagnagrunninn á undirliggjandi stigi. Á þessum tímapunkti fær síukrókurinn sem þú bættir við fyrr aldrei tækifæri til að keyra.

Með öðrum orðum, hefðbundnar blokkunaraðferðir taka aðeins gildi um leið og þú vistar greinina handvirkt. En samstillingarrökfræði Scry Search er mun flóknari en þú gætir ímyndað þér.

Kjarnakóði fyrir tvöfalda tryggingu við innrásaraðila

Eftir að hafa hugsað mig um áttaði ég mig á því að þetta mál gat ekki verið svona.

Þar sem hefðbundinn krókur stjórnar aðeins aðgangspunktinum „vistun einnar greinar“ þarf ég að finna leið til að loka fyrir hann frá öðrum stöðum líka.

Ég hef komið með tvær leiðir.

Fyrsta málið er sendingarenda netsins. Hvort sem um er að ræða samstillingu á einni grein eða hópsamstillingu, þá þarf samt að senda lokagögnin til Meilisearch-þjónsins með HTTP-beiðnum, ekki satt? Áður en ég sendi HTTP-beiðnina ætti ég því að athuga hvort meginmál beiðninnar innihaldi auðkenni þessara útilokuðu greina. Ef svo er, ætti ég að loka beint fyrir að beiðnin verði send.

Annað atriðið varðar fyrirspurnina í gagnagrunninum. Þar sem viðbótin sækir greinalistann beint úr gagnagrunninum við hópavísun, mun ég fjarlægja þessi tilteknu auðkenni úr niðurstöðum fyrirspurnar áður en gagnagrunnsfyrirspurnin hefst. Frá sjónarhóli viðbótarinnar eru þessar greinar alls ekki til, þannig að þær verða ekki sóttar.

Tvær leiðir, tvöföld trygging. Ef ekki er hægt að loka einni leið, þá er önnur til vara.

Eftir að ég hafði fundið út úr því byrjaði ég að skrifa kóða.

Fyrir fyrsta hlerunarforritið notaði ég innbyggða útgáfuna frá WordPress.pre_http_requestSían. Þessi krókur virkjast áður en WordPress sendir HTTP beiðnir. Rökfræði mín er sú að það muni greina hvort umbeðna vefslóðin inniheldur...meilisearchEf beiðnin inniheldur auðkenni útilokaðra greina verður beiðnin lokuð.

Til að koma í veg fyrir að viðbótin tilkynni villur þarf ég líka að falsa vel heppnað svar. Staðlað svarssnið fyrir Meilisearch er...{"taskUid":0,"status":"enqueued"}Ég skilaði þessu einfaldlega, sem lét viðbótina halda að samstillingin hefði tekist.

Seinni hlerunarbúnaðurinn sem ég notaðipre_get_postsKrókinn. Þessi krókur er virkjaður áður en WordPress keyrir gagnagrunnsfyrirspurn. Rökfræði mín er sú að í hvert skipti sem stjórnandi framkvæmir aðgerð í bakendanum, eða þegar viðbót framkvæmir ósamstilltar/samstilltar aðgerðir, ætti að sameina útilokuðu auðkennin í...post__not_inÍ breytunum.

Eftir að ég var búinn að skrifa þetta prófaði ég það.

Fyrst fór ég í bakenda kerfisins, opnaði eina af útilokuðum greinum, gerði nokkrar minniháttar breytingar og smellti á uppfæra. Það vistaðist án villna. Svo athugaði ég Meilisearch bakenda kerfisins og atriðisorðaskrá greinarinnar var óbreytt; ekkert nýtt hafði birst.

Ég smellti aftur á „Vísitölu færslur“ og endurbyggði alla vísitöluna. Eftir að hafa beðið um stund athugaði ég Meilisearch bakendann. Þessar útilokuðu greinar voru enn þar.

Það er búið.

Ítarleg greining: Hvernig virkar tvöföld trygging?

Satt best að segja minnti þetta ferli mig á eitthvað ansi áhugavert.

Þú veist, á níunda áratug 1880. aldar, þegar rafmagn var rétt að verða útbreitt í Bandaríkjunum, eyddu margir verksmiðjueigendur miklum peningum í að kaupa rafalstöðvar og rafmótora og setja þá upp í verksmiðjum sínum. Hins vegar, eftir uppsetningu, komust margir að því að framleiðsluhagkvæmni batnaði ekki verulega.

为什么?

Vegna þess að þeir skiptu einfaldlega út gufuvélinni fyrir rafmótor, en heildarskipulag, ferlar og stjórnunaraðferðir verksmiðjunnar voru óbreyttar. Rafmagnið var nýtt, en hugsunarháttur við notkun þess gamall.

Þeir sem raunverulega nutu góðs af rafmagnsuppsveiflunni voru í raun fyrstur til að skilja „hvað rafmagn í raun þýðir.“ Þeir breyttu ekki bara um orkugjafa; þeir endurhönnuðu allt framleiðsluferlið sitt.

Hið sama á við um gervigreindartímabilið . Margir nota gervigreind sem verkfæri en fáir íhuga hvaða undirliggjandi rökfræði hún breytir. Verkfærið sjálft er nýtt en hugsunarháttur þess gæti verið úreltur.

Til dæmis, þegar ég var að setja upp leitarblokkun í WordPress, hefði ég líklega ekki getað fengið hana til að virka ef ég hefði bara fylgt stöðluðum aðferðum í viðbótaskjölunum. Þetta er vegna þess að samstillingarrökfræði Scry Search er ekki lengur hefðbundin „vista eina grein, samstilla eina grein“ aðferð; hún hefur ósamstilltar biðraðir, hópvinnslu og sína eigin aðferðir.

Þú þarft að átta þig á hvernig þessi aðferð virkar áður en þú getur fundið raunverulega byltingu.

Takmarkanir og varúðarráðstafanir áætlunarinnar

Hins vegar verð ég að segja hreinskilnislega að þessi áætlun er ekki heldur fullkomin.

Það hefur verulega takmörkun: það getur aðeins stjórnað framtíðarsamstillingum og getur ekki sjálfkrafa eytt núverandi sögulegum færslum í Meilisearch. Með öðrum orðum, ef þú hefur þegar samstillt þessar greinar þarftu samt að eyða gömlu gögnunum handvirkt í Meilisearch mælaborðinu eða með API skipunum.

Þetta er einskiptisverkefni; þegar því er lokið þarftu ekki að hafa áhyggjur af því lengur. En ég þarf að gera þetta ljóst fyrirfram, svo að eftir að þú hefur sett kóðann inn, finnirðu ekki þessar greinar enn í leitarniðurstöðunum og gerir ráð fyrir að kóðinn hafi ekki tekið gildi.

Annað sem vert er að hafa í huga er að þessi aðferð byggir á undirliggjandi net- og gagnagrunnsarkitektúr WordPress. Svo lengi sem framtíðarútgáfur af Scry Search viðbótinni halda áfram að virka á grundvelli þessarar arkitektúrs, mun þessi hlerunarbúnaður halda áfram að virka. Hins vegar, ef hann skiptir yfir í allt annan samstillingarferil, gæti enduraðlögun verið nauðsynleg.

Heiðarlega sagt er þetta þó ólíklegt. Allt vistkerfið í WordPress er byggt á þessari arkitektúr og það er nánast ómögulegt fyrir viðbætur að komast alveg framhjá henni.

Þriggja þrepa leiðarvísir um innleiðingu

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

Að lokum skulum við draga saman skrefin í aðgerðinni.

Fyrst skaltu afrita kóðann alveg neðst í functions.php skrána þína, eða bæta honum við með því að nota Code Snippets viðbótina. Síðan, efst...defineÍ fylkinu skaltu slá inn auðkenni greinarinnar eða síðunnar sem þú vilt útiloka.

Annað skrefið er að hreinsa upp sögulegar vísitölur. Skráðu þig inn á Meilisearch mælaborðið þitt eða notaðu API skipanir til að eyða handvirkt gömlu vísitölugögnunum fyrir útilokaðar greinar.

Þriðja skrefið er prófun. Farðu í bakenda kerfisins og gerðu minniháttar breytingar á útilokuðu greininni, smelltu á uppfæra og athugaðu síðan Meilisearch bakenda kerfisins. Ef engin ný vísitala birtist hefur lokunin tekið gildi.

Satt best að segja hef ég alltaf fundið fyrir smá sektarkennd yfir því að skrifa þess konar tæknilegar greinar.

Það sem ég deili gæti verið gagnlegt fyrir suma, en fyrir aðra gætu þetta bara verið grunnaðgerðir.

En ferlið við að innleiða leitarblokkun á WordPress að þessu sinni var sannarlega innsæi. Oft eru vandamálin sem við lendum í ekki vegna skorts á lausnum, heldur frekar vegna þess að hugsun okkar er takmörkuð af núverandi ramma.

Scry Search viðbótin býður upp á síunarkróka, sem fær okkur til að trúa því að þetta sé eini kosturinn. Hins vegar býður öll arkitektúr WordPress upp á mun fleiri möguleika. Hægt er að ná fram hlerun á netlaginu og það er einnig hægt að gera það á gagnagrunnslaginu. Svo lengi sem þú ert tilbúinn að hugsa, þá er alltaf til leið.

Þess vegna hef ég gaman af að fikta í þessum tæknilegu græjum. Það snýst ekki um að stæra mig eða reyna að virðast áhrifamikill. Það er einfaldlega vegna þess að tilfinningin að skilja vandamál til fulls er ótrúlega ánægjuleg.

Rétt eins og í þetta skiptið, frá upphaflegu ruglingnum, til speglunar í miðjunni, til lokalausnarinnar, var allt ferlið eins og að leysa þraut.

Ráðgátan hefur verið leyst, svarið hefur verið afhjúpað, það reyndist svo einfalt var það.

En ef þú hefur ekki farið í gegnum þetta ruglingslega ferli, þá munt þú aldrei skilja þessa einföldu gleði.

Nú þegar þú hefur lesið þetta hingað til, ef þér fannst þetta gagnlegt, vinsamlegast líkaðu við og deildu því. Ef þú vilt fá uppfærslur fyrst geturðu líka fylgst með mér.

Takk fyrir að lesa greinina mína. Sjáumst næst.