Cumu escludiri cumpletamente un ID di post specificu da WordPress è sincronizallu cù Meilisearch (Plugin Scry Search in Pratica)

Aghju travagliatu pocu fà nant'à un situ web WordPress è vulia aghjunghje un mutore di ricerca d'altu rendimentu per tuttu u situ. Dopu à assai ricerche, aghju sceltu Meilisearch è l'aghju assuciatu cù un plugin chjamatu Scry Search.

À u principiu hè andatu bè. Aghju installatu u plugin, l'aghju cunfiguratu, è l'indice hè statu generatu automaticamente. A velocità di ricerca era rapida cum'è a lampa, è l'esperienza hè stata veramente eccellente.

Ma eccu u prublema.

Ci sò parechji articuli inusuali nant'à u situ web. Certi sò per testi interni, certi sò pagine di destinazione dedicate per clienti specifici, è altri sò cuntenutu incompletu chì ùn vulemu micca sguassà. Aghju bisognu chì sti ID d'articuli spariscinu cumpletamente da i risultati di ricerca.

Ùn basta micca ch'ellu ùn si pò truvà; hè chì ùn pò mancu esse in l'indice di Meilisearch.

Aghju pensatu chì questu era simplice; hè solu una questione di escludere uni pochi ID. A ducumentazione di u plugin deve avè i hooks currispondenti; basta à aghjunghje un filtru è hè fattu.

Cum'è s'hè rivelatu, aghju sbagliatu.

Perchè i metudi d'intercepzione cunvinziunali fiascanu?

Aghju prima pruvatu u filter hook mintuvatu in a ducumentazione ufficiale. Aghju aghjuntu qualchì linea di codice à functions.php, l'aghju salvatu, aghju aggiornatu u backend è l'aghju reindicizatu.

Dopu aghju verificatu u backend Meilisearch.

Quessi articuli sò sempre quì.

Era stupitu.

Aghju pensatu d'avè scrittu u codice sbagliatu, allora l'aghju verificatu parechje volte, ma ùn ci era nunda di male. Dopu aghju cercatu i prublemi di GitHub di u plugin è aghju trovu chì parechje altre persone avianu scontru prublemi simili.

Si scopre chì u plugin Scry Search usa un mecanismu di coda di attività asincrona per evità di rallentà u prucessu di salvataggio in background. Questu significa chì quandu cliccate "Salvà articulu" in background, i dati ponu esse istantaneamente spinti in una tabella di attività persunalizata, saltendu u filtraggio regulare di un solu articulu.

Ciò chì hè ancu più insidiosu hè chì quandu cliccate "Index Posts" in u fondu per rigenerà l'indice globale, u plugin esegue direttamente una query di basa di dati in batch à u livellu sottustante. À questu puntu, u ganciu di filtru chì avete aghjuntu prima ùn hà mai a pussibilità di esse eseguitu.

In altre parolle, i metudi di bloccu cunvinziunali piglianu effettu solu in u mumentu chì salvate manualmente l'articulu. Ma a logica di sincronizazione di Scry Search hè assai più cumplessa di ciò chì pudete imaginà.

Codice core di l'intercettatore di doppia assicurazione

Dopu avèci pensatu, aghju capitu chì sta materia ùn pudia esse lasciata cusì.

Siccomu u ganciu cunvinziunale cuntrolla solu u puntu d'entrata di "salvataghju di un solu articulu", devu truvà un modu per bluccallu ancu da altri lochi.

Aghju trovu duie strade.

U primu prublema hè a fine di a trasmissione in rete. Ch'ella sia a sincronizazione di un solu articulu o a sincronizazione in batch, i dati finali devenu sempre esse mandati à u servitore Meilisearch via richieste HTTP, nò ? Dunque, prima di mandà a richiesta HTTP, devu verificà se u corpu di a richiesta cuntene l'ID di l'articuli esclusi. S'ellu hè cusì, devu bluccà direttamente l'inviu di a richiesta.

U secondu puntu riguarda a dumanda di basa di dati. Siccomu u plugin recupera a lista di l'articuli direttamente da a basa di dati durante l'indicizazione in batch, elimineraghju questi ID specifici da i risultati di a dumanda prima di eseguisce a dumanda di basa di dati. Da u puntu di vista di u plugin, questi articuli ùn esistenu micca, dunque ùn saranu micca recuperati.

Dui percorsi, doppia assicurazione. S'un percorsu ùn pò esse bluccatu, ci n'hè un altru cum'è salvezza.

Dopu avè capitu, aghju cuminciatu à scrive codice.

Per u primu intercettatore, aghju utilizatu quellu nativu di WordPress.pre_http_requestU filtru. Stu hook si attiva prima chì WordPress faci qualsiasi dumanda HTTP. A mo logica hè chì rileverà se l'URL dumandata cuntene...meilisearchSè u corpu di a dumanda cuntene l'ID di l'articuli esclusi, a dumanda serà bluccata.

Per impedisce à u plugin di signalà errori, devu ancu simulà una risposta riescita. U furmatu di risposta standard per Meilisearch hè...{"taskUid":0,"status":"enqueued"}Aghju simpliciamente restituitu questu, facendu chì u plugin pensi chì a sincronizazione hè stata riesciuta.

U secondu interceptore chì aghju utilizatupre_get_postsU hook. Stu hook hè attivatu prima chì WordPress esegue una query di basa di dati. A mo logica hè chì ogni volta chì un amministratore esegue una operazione in u backend, o quandu un plugin esegue operazioni asincrone/sincrone, l'ID esclusi devenu esse fusi in u...post__not_inIn i parametri.

Dopu avè finitu di scrivelu, l'aghju pruvatu.

Prima, sò andatu in u backend, aghju apertu unu di l'articuli esclusi, aghju fattu uni pochi di cambiamenti minori, è aghju cliccatu nantu à aghjurnà. Hè statu salvatu cù successu senza errori. Dopu aghju verificatu u backend Meilisearch, è l'indice di l'articulu hè restatu invariatu; ùn era apparsu nunda di novu.

Aghju cliccatu torna nant'à "Articuli di l'Indice" è aghju ricustruitu tuttu l'indice. Dopu avè aspettatu un pocu, aghju verificatu u backend Meilisearch. Quessi articuli esclusi eranu sempre quì.

Hè fattu.

Analisi approfondita: Cumu funziona u mecanismu di doppia assicurazione?

À dì a verità, stu prucessu m'hà ricurdatu qualcosa di abbastanza interessante.

Sapete, in l'anni 1880, quandu l'elettricità si stava appena diffundendu in i Stati Uniti, parechji pruprietarii di fabbriche anu spesu assai soldi per cumprà generatori è motori elettrici è installalli in e so fabbriche. Tuttavia, dopu l'installazione, parechje persone anu trovu chì l'efficienza di a pruduzzione ùn hè micca migliurata significativamente.

perchè?

Perchè anu simpliciamente rimpiazzatu a macchina à vapore cù un mutore elettricu, ma a disposizione generale, i prucessi è i metudi di gestione di a fabbrica sò rimasti invariati. L'elettricità era nova, ma a mentalità per aduprà la era vechja.

Quelli chì anu veramente prufittatu di u boom di l'elettricità sò stati in realtà u primu gruppu à capisce "ciò chì significa veramente l'elettricità". Ùn anu micca solu cambiatu a so fonte d'energia; anu ridisignatu tuttu u so prucessu di pruduzzione.

U listessu vale per l'era di l'IA . Parechje persone utilizanu l'IA cum'è strumentu, ma pochi consideranu a logica sottustante chì cambia. U strumentu stessu hè novu, ma a mentalità aduprata per aduprà lu pò esse rimasta obsoleta.

Per esempiu, quandu aghju cunfiguratu u bloccu di ricerca di WordPress, probabilmente ùn averia micca pussutu fà lu funziunà s'ellu avessi solu seguitu i metudi standard in a ducumentazione di u plugin. Questu hè perchè a logica di sincronizazione di Scry Search ùn hè più l'approcciu tradiziunale "salvà un articulu, sincronizà un articulu"; hà code asincrone, elaborazione in batch è u so propiu inseme di meccanismi.

Avete bisognu di capisce cumu funziona stu mecanismu prima di pudè truvà una vera scuperta.

Limitazioni è precauzioni di u pianu

Tuttavia, devu dì francamente chì ancu questu pianu ùn hè perfettu.

Hà una limitazione significativa: pò solu gestisce e sincronizzazioni future è ùn pò micca sguassà automaticamente i registri storichi esistenti in Meilisearch. In altre parole, sè avete digià sincronizatu questi articuli, avete sempre bisognu di sguassà manualmente i vechji dati in u dashboard Meilisearch o aduprendu cumandamenti API.

Questu hè un compitu unicu; una volta fattu, ùn avete più bisognu di preoccupassi. Ma devu chiarificà questu in anticipu, affinchì dopu avè implementatu u codice, ùn truviate micca questi articuli sempre in i risultati di ricerca è supponite chì u codice ùn hà micca pigliatu effettu.

Un altru puntu da nutà hè chì questu approcciu si basa nantu à l'architettura di rete è di basa di dati sottostante di WordPress. Finu à chì e versioni future di u plugin Scry Search cuntinueghjanu à funziunà basatu annantu à sta architettura, questu intercettatore resterà efficace. Tuttavia, s'ellu passa mai à un mecanismu di sincronizazione cumpletamente differente, allora una riadattazione puderia esse necessaria.

À esse onestu, però, questu hè improbabile. Tuttu l'ecosistema WordPress hè custruitu annantu à sta architettura, è hè praticamente impussibile per i plugins di bypassalla cumpletamente.

Guida in trè tappe per l'implementazione

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

Infine, riassumemu i passi di l'operazione.

Prima, cupiate u codice in fondu à u vostru schedariu functions.php, o aghjunghjitelu cù u plugin Code Snippets. Dopu, in cima...defineIn l'array, inserite l'ID di l'articulu o di a pagina chì vulete escludiri.

U secondu passu hè di pulisce l'indici storichi. Cunnettatevi à u vostru pannellu di cuntrollu Meilisearch, o aduprate i cumandamenti API per sguassà manualmente i vechji dati di l'indice per l'articuli esclusi.

U terzu passu hè a prova. Andate à u backend è fate qualsiasi piccula mudificazione à l'articulu esclusu, cliccate nant'à aghjurnà, è dopu verificate u backend Meilisearch. S'ellu ùn appare micca un novu indice, u bloccu hè entratu in vigore.

À dì a verità, mi sò sempre sentitu un pocu culpevule di scrive stu tipu d'articuli di spartera tecnica.

E cose chì sparteghju ponu esse utili per certi persone, ma per altri ponu esse solu operazioni basiche.

Ma u prucessu di implementazione di u bloccu di ricerca di WordPress sta volta hè statu veramente perspicace. Spessu, i prublemi chì scuntremu ùn sò micca dovuti à una mancanza di suluzioni, ma piuttostu perchè u nostru pensamentu hè limitatu da i quadri esistenti.

U plugin Scry Search furnisce un ganciu di filtrazione, chì ci porta à crede chì questu hè l'unica opzione. Tuttavia, tutta l'architettura di WordPress offre assai più pussibilità. L'intercettazione pò esse ottenuta à u stratu di rete, è pò ancu esse fatta à u stratu di basa di dati. Basta chì site dispostu à pensà, ci hè sempre un modu.

Hè per quessa chì mi piace à armeghjà cù sti gadgets tecnichi. Ùn si tratta micca di mustrà si o di pruvà à parè impressiunante. Hè simplicemente perchè a sensazione di capisce cumpletamente un prublema hè incredibilmente soddisfacente.

Cum'è sta volta, da a cunfusione iniziale, à u riflessu in mezu, à a suluzione finale, tuttu u prucessu hè statu cum'è risolve un puzzle.

U misteru hè statu risoltu, a risposta hè stata rivelata, si scopre chì era cusì simplice.

Ma s'è vo ùn avete micca passatu per quellu prucessu cunfusu, ùn capirete mai sta gioia simplice.

Avà chì avete lettu finu à quì, sè l'avete trovu utile, per piacè lasciate un "mi piace" è spartitelu. Sè vo vulete riceve prima l'aghjurnamenti, pudete ancu seguità mi.

Grazie per avè lettu u mo articulu. À a prossima volta.