Како потпуно искључити одређени ИД објаве из WordPress-а и синхронизовати га са Meilisearch-ом (Scry Search Plugin у пракси)

Недавно сам радио на WordPress веб-сајту и желео сам да додам високо-ефикасан претраживач за цео сајт. Након много претраживања, изабрао сам Meilisearch и упарио га са додатком под називом Scry Search.

У почетку је ишло глатко. Инсталирао сам додатак, конфигурисао га и индекс је генерисан аутоматски. Брзина претраге је била муњевита, а искуство је заиста било одлично.

Али ево проблема.

На веб-сајту постоји неколико необичних чланака. Неки су за интерно тестирање, неки су наменске одредишне странице за одређене клијенте, а други су недовршени садржај који не желимо да обришемо. Потребно ми је да ови ИД-ови чланака потпуно нестану из резултата претраге.

Није довољно што се не може пронаћи; већ што се чак не може наћи ни у индексу Meilisearch-а.

Мислио сам да је ово једноставно; само је питање искључивања неколико ИД-ова. Документација додатка мора имати одговарајуће „hooks“-ове; само додајте филтер и готово је.

Како се испоставило, погрешио сам.

Зашто конвенционалне методе пресретања не успевају?

Прво сам испробао филтер хоок поменут у званичној документацији. Додао сам неколико линија кода у functions.php, сачувао га, освежио бекенд и поново га индексирао.

Онда сам проверио Меилисеарч бекенд.

Ти чланци су још увек тамо.

Био сам запрепашћен.

Мислио сам да сам написао погрешан код, па сам га неколико пута проверио, али није било ништа лоше у њему. Затим сам претражио проблеме додатка на ГитХубу и открио да је још неколико људи наишло на сличне проблеме.

Испоставило се да Scry Search додатак користи асинхрони механизам чекања задатака како би се избегло успоравање процеса чувања у позадини. То значи да када кликнете на „Сачувај чланак“ у позадини, подаци могу одмах бити пребачени у прилагођену табелу задатака, заобилазећи редовно филтрирање појединачних чланака.

Још подмуклије је то што када кликнете на „Индексирај објаве“ у позадини да бисте регенерисали глобални индекс, додатак директно извршава пакетни упит бази података на основном нивоу. У овом тренутку, филтер хоок који сте раније додали никада не добија прилику да се изврши.

Другим речима, конвенционалне методе блокирања ступају на снагу тек у тренутку када ручно сачувате чланак. Али логика синхронизације Scry Search-а је много сложенија него што бисте могли замислити.

Основни код пресретача са двоструким осигурањем

Након што сам размислио о томе, схватио сам да се ова ствар не може овако оставити.

Пошто конвенционална кука контролише само улазну тачку „чување једног чланка“, морам да пронађем начин да је блокирам и са других места.

Смислио сам два пута.

Први проблем је мрежни пренос. Било да се ради о синхронизацији појединачних чланака или групној синхронизацији, коначни подаци и даље морају бити послати на Meilisearch сервер путем HTTP захтева, зар не? Дакле, пре слања HTTP захтева, требало би да проверим да ли тело захтева садржи ИД-ове тих искључених чланака. Ако је тако, требало би директно да блокирам слање захтева.

Друга тачка се тиче упита базе података. Пошто додатак преузима листу чланака директно из базе података током пакетног индексирања, уклонићу те специфичне ИД-ове из резултата упита пре него што извршим упит базе података. Из перспективе додатка, ови чланци уопште не постоје, тако да неће бити преузети.

Два пута, двоструко осигурање. Ако један пут не може бити блокиран, постоји други као резерва.

Након што сам то схватио, почео сам да пишем код.

За први пресретач, користио сам Вордпресов изворни.pre_http_requestФилтер. Овај филтер се активира пре него што WordPress направи било какве HTTP захтеве. Моја логика је да ће детектовати да ли тражени URL садржи...meilisearchАко тело захтева садржи ИД-ове искључених чланака, захтев ће бити блокиран.

Да бих спречио да додатак пријављује грешке, такође морам да лажирам успешан одговор. Стандардни формат одговора за Meilisearch је...{"taskUid":0,"status":"enqueued"}Једноставно сам ово вратио, наводећи додатак да мисли да је синхронизација успешна.

Други пресретач који сам користиоpre_get_postsКука. Ова кука се активира пре него што WordPress изврши упит у бази података. Моја логика је да кад год администратор изврши операцију у бекенду или када додатак изврши асинхроне/синхроне операције, искључени ИД-ови треба да се споје у...post__not_inУ параметрима.

Након што сам завршио са писањем, тестирао сам га.

Прво сам отишао на бекенд, отворио један од искључених чланака, направио неколико мањих измена и кликнуо на ажурирање. Успешно је сачуван без икаквих грешака. Затим сам проверио бекенд Меилисеарча и индекс чланка је остао непромењен; ништа ново се није појавило.

Поново сам кликнуо на „Индексирај објаве“ и поново направио цео индекс. Након што сам мало сачекао, проверио сам Meilisearch бекенд. Ти искључени чланци су и даље били тамо.

Готово је.

Детаљна анализа: Како функционише механизам двоструког осигурања?

Искрено, овај процес ме је подсетио на нешто прилично занимљиво.

Знате, 1880-их, када је струја тек постајала широко распрострањена у Сједињеним Државама, многи власници фабрика су трошили много новца на куповину генератора и електромотора и њихову уградњу у своје фабрике. Међутим, након инсталације, многи људи су открили да се ефикасност производње није значајно побољшала.

为什么?

Зато што су једноставно заменили парну машину електромотором, али су целокупни распоред, процеси и методе управљања фабриком остали непромењени. Електрична енергија је била нова, али је начин размишљања о њеном коришћењу био стар.

Они који су заиста имали користи од бума електричне енергије били су заправо прва група која је разумела „шта струја заиста значи“. Нису само променили извор енергије; редизајнирали су цео свој производни процес.

Исто важи и за еру вештачке интелигенције . Многи људи користе вештачку интелигенцију као алат, али мало ко размишља о томе коју основну логику она мења. Сам алат је нов, али начин размишљања који се користи за његово коришћење може остати застарео.

На пример, када сам подешавао блокирање претраге у WordPress-у, вероватно не бих могао да га покренем да сам само пратио стандардне методе у документацији додатка. То је зато што логика синхронизације Scry Search-а више није традиционални приступ „сачувај један чланак, синхронизуј један чланак“; има асинхроне редове, групну обраду и сопствени скуп механизама.

Морате схватити како овај механизам функционише пре него што можете пронаћи прави пробој.

Ограничења и мере предострожности плана

Међутим, морам искрено рећи да ни овај план није савршен.

Има значајно ограничење: може да управља само будућим синхронизацијама и не може аутоматски да брише постојеће историјске записе у Meilisearch-у. Другим речима, ако сте већ синхронизовали те чланке, и даље морате ручно да обришете старе податке у Meilisearch контролној табли или помоћу API команди.

Ово је једнократни задатак; када се заврши, више не морате да бринете о томе. Али морам ово разјаснити унапред, како након што примените код, не бисте пронашли те чланке и даље у резултатима претраге и претпоставили да код није ступио на снагу.

Још једна ствар коју треба напоменути је да се овај приступ ослања на основну мрежу и архитектуру базе података Вордпреса. Све док будуће верзије додатка Scry Search наставе да раде на основу ове архитектуре, овај пресретач ће остати ефикасан. Међутим, ако икада пређе на потпуно другачији механизам синхронизације, онда ће можда бити потребна поновна адаптација.

Искрено, међутим, ово је мало вероватно. Читав WordPress екосистем је изграђен на овој архитектури и практично је немогуће да је додаци потпуно заобиђу.

Водич за имплементацију у три корака

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

На крају, хајде да сумирамо кораке операције.

Прво, копирајте код на само дно ваше датотеке functions.php или га додајте помоћу додатка Code Snippets. Затим, на врху...defineУ низ унесите ИД чланка или странице коју желите да искључите.

Други корак је чишћење историјских индекса. Пријавите се на своју Meilisearch контролну таблу или користите API команде да бисте ручно обрисали старе податке индекса за искључене чланке.

Трећи корак је тестирање. Идите на бекенд и направите све мање измене на искљученом чланку, кликните на ажурирање, а затим проверите бекенд Меилисеарча. Ако се не појави нови индекс, блокирање је ступило на снагу.

Да будем искрен, увек сам се осећао помало кривим што пишем овакве техничке чланке са разменом информација.

Ствари које делим могу бити корисне неким људима, али за друге могу бити само основне операције.

Али процес имплементације блокирања претраге у WordPress-у овог пута је био заиста проницљив. Често проблеми са којима се сусрећемо нису последица недостатка решења, већ зато што је наше размишљање ограничено постојећим оквирима.

Додатак Scry Search пружа могућност филтрирања, што нас наводи на уверење да је ово једина опција. Међутим, цела архитектура WordPress-а нуди далеко више могућности. Пресретање се може постићи на мрежном слоју, а може се извршити и на слоју базе података. Све док сте спремни да размишљате, увек постоји начин.

Зато уживам у експериментисању са овим техничким справама. Не ради се о хвалисању или покушају да изгледам импресивно. Једноставно зато што је осећај потпуног разумевања проблема невероватно задовољавајући.

Баш као и овог пута, од почетне забуне, преко одраза у средини, до коначног решења, цео процес је био као решавање слагалице.

Мистерија је решена, одговор је откривен, испоставило се да је било тако једноставно.

Али ако нисте прошли кроз тај збуњујући процес, никада нећете разумети ову једноставну радост.

Сада када сте прочитали до овде, ако вам је било корисно, лајкујте и поделите. Ако желите први да примате новости, можете ме и пратити.

Хвала вам што сте прочитали мој чланак. Видимо се следећи пут.