Sut i eithrio ID post penodol yn llwyr o WordPress a'i gysoni â Meilisearch (Ategyn Chwilio Scry mewn Ymarfer)

Rydw i wedi bod yn gweithio ar wefan WordPress yn ddiweddar ac roeddwn i eisiau ychwanegu peiriant chwilio perfformiad uchel ar draws y wefan. Ar ôl llawer o chwilio, dewisais Meilisearch a'i baru ag ategyn o'r enw Scry Search.

Aeth yn esmwyth ar y dechrau. Gosodais yr ategyn, ei ffurfweddu, a chynhyrchwyd y mynegai yn awtomatig. Roedd cyflymder y chwilio yn gyflym fellt, ac roedd y profiad yn wir yn ardderchog.

Ond dyma'r broblem yn dod.

Mae sawl erthygl anarferol ar y wefan. Mae rhai ar gyfer profion mewnol, mae rhai yn dudalennau glanio pwrpasol ar gyfer cleientiaid penodol, ac mae eraill yn gynnwys anorffenedig nad ydym am ei ddileu. Mae angen i'r IDau erthygl hyn ddiflannu'n llwyr o ganlyniadau chwilio.

Nid yw'n ddigon na ellir dod o hyd iddo; mae'n ddigon na all hyd yn oed fod ym mynegai Meilisearch.

Roeddwn i'n meddwl bod hyn yn syml; dim ond mater o eithrio ychydig o IDau ydyw. Rhaid i ddogfennaeth yr ategyn gynnwys y bachynnau cyfatebol; dim ond ychwanegu hidlydd ac mae wedi gwneud.

Fel y digwyddodd, roeddwn i'n anghywir.

Pam mae dulliau rhyng-gipio confensiynol yn methu?

Fe wnes i roi cynnig ar y bachyn hidlo a grybwyllir yn y ddogfennaeth swyddogol yn gyntaf. Ychwanegais ychydig linellau o god at functions.php, ei gadw, adnewyddu'r backend, a'i ail-fynegeio.

Yna gwiriais gefndir Meilisearch.

Mae'r erthyglau hynny yno o hyd.

Cefais fy syfrdanu.

Roeddwn i'n meddwl fy mod i wedi ysgrifennu'r cod anghywir, felly gwiriais i ef sawl gwaith, ond doedd dim byd o'i le arno. Yna chwiliais i Problemau GitHub yr ategyn a chanfod bod sawl person arall wedi dod ar draws problemau tebyg.

Mae'n ymddangos bod yr ategyn Scry Search yn defnyddio mecanwaith ciw tasgau anghydamserol i osgoi arafu'r broses arbed yn y cefndir. Mae hyn yn golygu pan gliciwch "Arbed Erthygl" yn y cefndir, y gellir gwthio'r data ar unwaith i dabl tasgau personol, gan osgoi'r hidlo erthygl sengl arferol.

Yr hyn sydd hyd yn oed yn fwy llechwraidd yw pan gliciwch chi ar "Mynegai Postiadau" yn y cefndir i adfywio'r mynegai byd-eang, mae'r ategyn yn perfformio ymholiad cronfa ddata swp yn uniongyrchol ar y lefel sylfaenol. Ar y pwynt hwn, nid yw'r bachyn hidlo ychwanegoch chi yn gynharach byth yn cael cyfle i weithredu.

Hynny yw, dim ond y funud y byddwch chi'n cadw'r erthygl â llaw y mae dulliau blocio confensiynol yn dod i rym. Ond mae rhesymeg cydamseru Scry Search yn llawer mwy cymhleth nag y gallech chi ddychmygu.

Cod craidd rhyng-gipio yswiriant dwbl

Ar ôl meddwl amdano, sylweddolais na ellid gadael y mater hwn fel hyn.

Gan mai dim ond y pwynt mynediad "arbed erthygl sengl" y mae'r bachyn confensiynol yn ei reoli, mae angen i mi ddod o hyd i ffordd i'w rwystro o leoedd eraill hefyd.

Rydw i wedi meddwl am ddau lwybr.

Y broblem gyntaf yw pen trosglwyddo'r rhwydwaith. Boed yn gydamseru erthygl sengl neu'n gydamseru swp, mae angen anfon y data terfynol i'r gweinydd Meilisearch trwy geisiadau HTTP o hyd, iawn? Felly, cyn anfon y cais HTTP, dylwn wirio a yw corff y cais yn cynnwys IDau'r erthyglau eithriedig hynny. Os felly, dylwn rwystro'r cais rhag cael ei anfon yn uniongyrchol.

Mae'r ail bwynt yn ymwneud â'r ymholiad cronfa ddata. Gan fod yr ategyn yn adfer y rhestr erthyglau yn uniongyrchol o'r gronfa ddata yn ystod mynegeio swp, byddaf yn tynnu'r IDau penodol hynny o ganlyniadau'r ymholiad cyn gweithredu'r ymholiad cronfa ddata. O safbwynt yr ategyn, nid yw'r erthyglau hyn yn bodoli o gwbl, felly ni fyddant yn cael eu hadalw.

Dau lwybr, yswiriant dwbl. Os na ellir rhwystro un llwybr, mae un arall wrth gefn.

Ar ôl ei ddarganfod, dechreuais ysgrifennu cod.

Ar gyfer yr rhyng-gipiwr cyntaf, defnyddiais un brodorol WordPress.pre_http_requestY hidlydd. Mae'r bachyn hwn yn sbarduno cyn i WordPress wneud unrhyw geisiadau HTTP. Fy rhesymeg yw y bydd yn canfod a yw'r URL gofynnol yn cynnwys...meilisearchOs yw corff y cais yn cynnwys IDau'r erthyglau sydd wedi'u heithrio, bydd y cais yn cael ei rwystro.

Er mwyn atal yr ategyn rhag adrodd gwallau, mae angen i mi hefyd ffugio ymateb llwyddiannus. Y fformat ymateb safonol ar gyfer Meilisearch yw...{"taskUid":0,"status":"enqueued"}Dychwelais hwn yn syml, gan wneud i'r ategyn feddwl bod y cydamseru wedi bod yn llwyddiannus.

Yr ail rhyng-gipiwr a ddefnyddiaispre_get_postsY bachyn. Mae'r bachyn hwn yn cael ei sbarduno cyn i WordPress weithredu ymholiad cronfa ddata. Fy rhesymeg yw pryd bynnag y bydd gweinyddwr yn cyflawni gweithrediad yn y backend, neu pan fydd ategyn yn cyflawni gweithrediadau anghydamserol/cydamserol, dylid uno'r IDau eithriedig i'r...post__not_inYn y paramedrau.

Ar ôl i mi orffen ei ysgrifennu, fe wnes i brofi hynny.

Yn gyntaf, es i i'r backend, agorais un o'r erthyglau oedd wedi'u heithrio, gwnes i ychydig o newidiadau bach, a chliciais ar ddiweddaru. Llwyddodd i gadw heb unrhyw wallau. Yna, gwiriais backend Meilisearch, ac arhosodd mynegai'r erthygl heb ei newid; nid oedd dim byd newydd wedi ymddangos.

Cliciais "Mynegai Postiadau" eto ac ailadeiladu'r mynegai cyfan. Ar ôl aros ychydig, gwiriais gefndir Meilisearch. Roedd yr erthyglau eithriedig hynny yno o hyd.

Mae wedi'i wneud.

Dadansoddiad manwl: Sut mae'r mecanwaith yswiriant dwbl yn gweithio?

A dweud y gwir, fe wnaeth y broses hon fy atgoffa o rywbeth eithaf diddorol.

Wyddoch chi, yn y 1880au, pan oedd trydan newydd ddod yn gyffredin yn yr Unol Daleithiau, gwariodd llawer o berchnogion ffatrïoedd lawer o arian i brynu generaduron a moduron trydan a'u gosod yn eu ffatrïoedd. Fodd bynnag, ar ôl eu gosod, canfu llawer o bobl nad oedd effeithlonrwydd cynhyrchu wedi gwella'n sylweddol.

为什么?

Oherwydd eu bod nhw wedi disodli'r injan stêm gyda modur trydan yn unig, ond arhosodd cynllun, prosesau a dulliau rheoli cyffredinol y ffatri yr un fath. Roedd y trydan yn newydd, ond roedd y meddylfryd ar gyfer ei ddefnyddio yn hen.

Y rhai a elwodd yn wirioneddol o'r ffyniant trydan oedd y grŵp cyntaf i ddeall "beth mae trydan yn ei olygu mewn gwirionedd." Ni wnaethant newid eu ffynhonnell pŵer yn unig; fe wnaethant ailgynllunio eu proses gynhyrchu gyfan.

Mae'r un peth yn wir am oes AI . Mae llawer o bobl yn defnyddio AI fel offeryn, ond ychydig sy'n ystyried pa resymeg sylfaenol y mae'n ei newid. Mae'r offeryn ei hun yn newydd, ond mae'n bosibl bod y meddylfryd a ddefnyddir i'w ddefnyddio yn parhau i fod yn hen ffasiwn.

Er enghraifft, pan oeddwn i'n sefydlu blocio chwiliadau WordPress, mae'n debyg na fyddwn i wedi gallu ei gael i weithio pe bawn i wedi dilyn y dulliau safonol yn nogfennaeth yr ategyn. Mae hyn oherwydd nad yw rhesymeg cydamseru Scry Search bellach yn ddull traddodiadol "cadw un erthygl, cydamseru un erthygl"; mae ganddo giwiau anghydamserol, prosesu swp, a'i set ei hun o fecanweithiau.

Mae angen i chi ddarganfod sut mae'r mecanwaith hwn yn gweithio cyn y gallwch ddod o hyd i ddatblygiad go iawn.

Cyfyngiadau a rhagofalon y cynllun

Fodd bynnag, rhaid i mi ddweud yn blwmp ac yn blaen nad yw'r cynllun hwn yn berffaith chwaith.

Mae ganddo gyfyngiad sylweddol: dim ond cydamseriadau yn y dyfodol y gall eu rheoli ac ni all ddileu cofnodion hanesyddol presennol yn awtomatig yn Meilisearch. Mewn geiriau eraill, os ydych chi eisoes wedi cydamseru'r erthyglau hynny, mae angen i chi ddileu'r hen ddata â llaw yn dangosfwrdd Meilisearch neu ddefnyddio gorchmynion API o hyd.

Tasg untro yw hon; unwaith y bydd wedi'i gwneud, does dim angen i chi boeni amdani mwyach. Ond mae angen i mi egluro hyn ymlaen llaw, fel ar ôl i chi ddefnyddio'r cod, nad ydych chi'n dod o hyd i'r erthyglau hynny yn y canlyniadau chwilio o hyd ac yn tybio nad yw'r cod wedi dod i rym.

Pwynt arall i'w nodi yw bod y dull hwn yn dibynnu ar bensaernïaeth rhwydwaith a chronfa ddata sylfaenol WordPress. Cyn belled â bod fersiynau yn y dyfodol o'r ategyn Scry Search yn parhau i weithredu yn seiliedig ar y bensaernïaeth hon, bydd y rhyng-gipiwr hwn yn parhau i fod yn effeithiol. Fodd bynnag, os bydd byth yn newid i fecanwaith cydamseru hollol wahanol, yna efallai y bydd angen ail-addasu.

A dweud y gwir, fodd bynnag, mae hyn yn annhebygol. Mae ecosystem gyfan WordPress wedi'i adeiladu ar y bensaernïaeth hon, ac mae bron yn amhosibl i ategion ei hosgoi'n llwyr.

Canllaw Tair Cam i Weithredu

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

Yn olaf, gadewch i ni grynhoi'r camau gweithredu.

Yn gyntaf, copïwch y cod i waelod eich ffeil functions.php, neu ychwanegwch ef gan ddefnyddio'r ategyn Code Snippets. Yna, ar y brig...defineYn yr arae, nodwch ID yr erthygl neu'r dudalen rydych chi am ei heithrio.

Yr ail gam yw glanhau mynegeion hanesyddol. Mewngofnodwch i'ch dangosfwrdd Meilisearch, neu defnyddiwch orchmynion API i ddileu'r hen ddata mynegai â llaw ar gyfer yr erthyglau sydd wedi'u heithrio.

Y trydydd cam yw profi. Ewch i'r backend a gwnewch unrhyw newidiadau bach i'r erthygl sydd wedi'i heithrio, cliciwch ar ddiweddaru, ac yna gwiriwch backend Meilisearch. Os nad oes mynegai newydd yn ymddangos, mae'r blocio wedi dod i rym.

A dweud y gwir, rydw i bob amser wedi teimlo braidd yn euog am ysgrifennu'r mathau hyn o erthyglau rhannu technegol.

Efallai y bydd y pethau rwy'n eu rhannu yn ddefnyddiol i rai pobl, ond i eraill efallai mai dim ond gweithrediadau sylfaenol ydyn nhw.

Ond roedd y broses o weithredu blocio chwiliadau WordPress y tro hwn yn wirioneddol ddeallus. Yn aml, nid yw'r problemau rydyn ni'n eu hwynebu oherwydd diffyg atebion, ond yn hytrach oherwydd bod ein meddwl wedi'i gyfyngu gan fframweithiau presennol.

Mae'r ategyn Scry Search yn darparu bachyn hidlo, gan ein harwain i gredu mai dyma'r unig opsiwn. Fodd bynnag, mae pensaernïaeth gyfan WordPress yn cynnig llawer mwy o bosibiliadau. Gellir cyflawni rhyng-gipio ar yr haen rhwydwaith, a gellir ei wneud hefyd ar haen y gronfa ddata. Cyn belled â'ch bod chi'n barod i feddwl, mae yna ffordd bob amser.

Dyna pam rwy'n mwynhau chwarae gyda'r teclynnau technegol hyn. Nid yw'n ymwneud â dangos neu geisio ymddangos yn drawiadol. Mae'n syml oherwydd bod y teimlad o ddeall problem yn llwyr yn hynod foddhaol.

Yn union fel y tro hwn, o'r dryswch cychwynnol, i'r myfyrdod yn y canol, i'r ateb terfynol, roedd y broses gyfan fel datrys pos.

Mae'r dirgelwch wedi'i ddatrys, mae'r ateb wedi'i ddatgelu, mae'n ymddangos ei fod mor syml.

Ond os nad ydych chi wedi mynd trwy'r broses ddryslyd honno, fyddwch chi byth yn deall y llawenydd syml hwn.

Nawr eich bod wedi darllen hyd yma, os oeddech chi'n ei chael hi'n ddefnyddiol, hoffwch a rhannwch hi. Os ydych chi eisiau derbyn diweddariadau yn gyntaf, gallwch chi fy nilyn i hefyd.

Diolch am ddarllen fy erthygl. Hwyl fawr.