WordPress မှ သတ်မှတ်ထားသော post ID တစ်ခုကို လုံးဝဖယ်ထုတ်ပြီး Meilisearch (လက်တွေ့တွင် Scry Search Plugin) နှင့် မည်သို့ထပ်တူပြုရမည်နည်း။

မကြာသေးခင်က WordPress ဝက်ဘ်ဆိုက် တစ်ခုမှာ အလုပ်လုပ်နေပြီး စွမ်းဆောင်ရည်မြင့် ရှာဖွေရေးအင်ဂျင်တစ်ခု ထည့်သွင်းချင်ခဲ့ပါတယ်။ အများကြီးရှာဖွေပြီးတဲ့နောက် Meilisearch ကို ရွေးချယ်ပြီး Scry Search လို့ခေါ်တဲ့ plugin နဲ့ တွဲဖက်အသုံးပြုခဲ့ပါတယ်။

အစပိုင်းမှာတော့ အဆင်ပြေပါတယ်။ plugin ကို install လုပ်ပြီး configure လုပ်လိုက်တော့ index ကို အလိုအလျောက်ထုတ်ပေးပါတယ်။ ရှာဖွေမှုအမြန်နှုန်းက မိုးကြိုးပစ်သလို အတွေ့အကြုံကလည်း အရမ်းကောင်းပါတယ်။

ဒါပေမယ့် ဒီမှာ ပြဿနာရှိတယ်။

ဝက်ဘ်ဆိုက်မှာ ထူးခြားတဲ့ ဆောင်းပါးတွေ အများကြီးရှိပါတယ်။ တချို့က အတွင်းပိုင်းစမ်းသပ်ဖို့အတွက်ဖြစ်ပြီး၊ တချို့က သတ်မှတ်ထားတဲ့ client တွေအတွက် သီးသန့် landing page တွေဖြစ်ပြီး၊ တချို့ကတော့ ကျွန်တော်တို့ မဖျက်ချင်တဲ့ မပြီးပြတ်သေးတဲ့ အကြောင်းအရာတွေပါ။ ဒီဆောင်းပါး ID တွေကို ရှာဖွေမှုရလဒ်တွေကနေ လုံးဝပျောက်ကွယ်သွားစေချင်ပါတယ်။

ရှာမတွေ့နိုင်ဘူးဆိုတာ မလုံလောက်ပါဘူး၊ Meilisearch ရဲ့ အညွှန်းမှာတောင် မပါနိုင်ဘူးဆိုတာပါပဲ။

ဒါက ရိုးရှင်းတယ်လို့ ကျွန်တော်ထင်ခဲ့တယ်။ ID အနည်းငယ်ကို ဖယ်ထုတ်လိုက်ရုံပါပဲ။ plugin စာရွက်စာတမ်းမှာ သက်ဆိုင်ရာ hook တွေ ပါဝင်ရမယ်။ filter တစ်ခုထည့်လိုက်ရုံနဲ့ ပြီးပါပြီ။

ကျွန်တော် မှားသွားတယ်ဆိုတာ ပေါ်လွင်လာပါတယ်။

ရိုးရာကြားဖြတ်နည်းလမ်းများ အဘယ်ကြောင့် မအောင်မြင်သနည်း။

တရားဝင်စာရွက်စာတမ်းမှာ ဖော်ပြထားတဲ့ filter hook ကို ကျွန်တော် ပထမဆုံး စမ်းကြည့်ခဲ့ပါတယ်။ functions.php မှာ code အနည်းငယ်ထည့်ပြီး save လုပ်၊ backend ကို refresh လုပ်ပြီး re-index လုပ်ခဲ့ပါတယ်။

ပြီးတော့ Meilisearch backend ကို စစ်ဆေးကြည့်တယ်။

အဲဒီဆောင်းပါးတွေက အခုထိ ရှိနေတုန်းပဲ။

ကျွန်တော် အံ့အားသင့်သွားတယ်။

ကျွန်တော် ကုဒ်မှားရေးမိတယ်လို့ ထင်လို့ အကြိမ်ပေါင်းများစွာ စစ်ဆေးကြည့်ပေမယ့် ဘာမှ မှားယွင်းတာ မတွေ့ပါဘူး။ ပြီးတော့ plugin ရဲ့ GitHub Issues မှာ ရှာကြည့်တော့ တခြားလူတွေလည်း အလားတူပြဿနာတွေ ကြုံခဲ့ရတယ်ဆိုတာ တွေ့လိုက်ရတယ်။

Scry Search plugin သည် နောက်ခံသိမ်းဆည်းခြင်းလုပ်ငန်းစဉ်ကို နှေးကွေးစေခြင်းမှ ရှောင်ရှားရန် asynchronous task queue ယန္တရားကို အသုံးပြုကြောင်း တွေ့ရှိရသည်။ ဆိုလိုသည်မှာ နောက်ခံတွင် "Save Article" ကို နှိပ်လိုက်သောအခါ၊ ပုံမှန် single-article filtering ကို ကျော်လွှား၍ data ကို custom task table ထဲသို့ ချက်ချင်းထည့်သွင်းနိုင်သည်။

ပိုပြီး လျှို့ဝှက်ဆန်းကြယ်တာက global index ကို ပြန်လည်ဖန်တီးဖို့ background မှာ "Index Posts" ကို နှိပ်လိုက်တဲ့အခါ plugin က underlying level မှာ batch database query ကို တိုက်ရိုက်လုပ်ဆောင်ပါတယ်။ ဒီအချိန်မှာ အစောပိုင်းက ထည့်ထားတဲ့ filter hook ကို execute လုပ်ခွင့် မရတော့ပါဘူး။

တစ်နည်းအားဖြင့် ရိုးရာပိတ်ဆို့ခြင်းနည်းလမ်းများသည် ဆောင်းပါးကို ကိုယ်တိုင်သိမ်းဆည်းသည့်အချိန်တွင်သာ အကျိုးသက်ရောက်မှုရှိသည်။ သို့သော် Scry Search ၏ ထပ်တူပြုခြင်းယုတ္တိဗေဒသည် သင်ထင်ထားသည်ထက် များစွာပိုရှုပ်ထွေးပါသည်။

နှစ်ထပ်အာမခံကြားဖြတ်ကိရိယာအဓိကကုဒ်

စဉ်းစားပြီးတဲ့နောက် ဒီကိစ္စကို ဒီအတိုင်း ထားခဲ့လို့မရဘူးဆိုတာ သဘောပေါက်လာတယ်။

ရိုးရာ hook က "single-article saving" entry point ကိုပဲ ထိန်းချုပ်တဲ့အတွက် တခြားနေရာတွေကနေလည်း block လုပ်ဖို့ နည်းလမ်းရှာရမယ်။

ကျွန်တော် လမ်းကြောင်းနှစ်ခု စဉ်းစားမိပါပြီ။

ပထမပြဿနာက network transmission end ပါ။ single-article synchronization ဖြစ်စေ၊ batch synchronization ဖြစ်စေ နောက်ဆုံး data ကို HTTP request တွေကနေတစ်ဆင့် Meilisearch server ကို ပို့ဖို့ လိုပါသေးတယ်၊ မဟုတ်လား။ ဒါကြောင့် HTTP request မပို့ခင် request body မှာ အဲဒီဖယ်ထုတ်ထားတဲ့ article တွေရဲ့ ID တွေ ပါမပါ စစ်ဆေးသင့်ပါတယ်။ ပါရင် request ပို့တာကို တိုက်ရိုက် block လုပ်သင့်ပါတယ်။

ဒုတိယအချက်ကတော့ database query နဲ့ ပတ်သက်ပါတယ်။ plugin က batch indexing လုပ်နေချိန်မှာ database ကနေ article list ကို တိုက်ရိုက်ရယူတဲ့အတွက် database query ကို execute မလုပ်ခင်မှာ query result တွေကနေ အဲဒီ ID တွေကို ဖယ်ရှားပါမယ်။ plugin ရဲ့ ရှုထောင့်ကနေကြည့်ရင် ဒီ article တွေက လုံးဝမရှိတာကြောင့် ပြန်ယူမှာ မဟုတ်ပါဘူး။

လမ်းကြောင်းနှစ်ခု၊ အာမခံနှစ်ထပ်။ လမ်းကြောင်းတစ်ခုကို ပိတ်ဆို့၍မရပါက အရန်အဖြစ် နောက်တစ်ခုရှိသည်။

နားလည်သွားပြီးနောက်မှာ ကျွန်တော် ကုဒ်ရေးဖို့ စတင်ခဲ့ပါတယ်။

ပထမဆုံး interceptor အတွက် WordPress ရဲ့ native တစ်ခုကို ကျွန်တော်သုံးခဲ့ပါတယ်။pre_http_requestfilter။ WordPress သည် HTTP request များ မပြုလုပ်မီ ဤ hook ကို trigger လုပ်သည်။ ကျွန်ုပ်၏ယုတ္တိဗေဒမှာ တောင်းဆိုထားသော URL တွင်... ရှိမရှိကို သိရှိနိုင်စေရန်ဖြစ်သည်။meilisearchတောင်းဆိုချက်တွင် ဖယ်ထုတ်ထားသော ဆောင်းပါးများ၏ ID များပါရှိပါက တောင်းဆိုချက်ကို ပိတ်ဆို့ပါမည်။

ပလပ်အင်က အမှားအယွင်းတွေ မတင်ပြနိုင်အောင်၊ အောင်မြင်တဲ့ တုံ့ပြန်မှုကို အတုအယောင် လုပ်ဖို့လည်း လိုပါတယ်။ Meilisearch အတွက် စံတုံ့ပြန်မှုပုံစံက...{"taskUid":0,"status":"enqueued"}ကျွန်တော်က ဒါကို ပြန်ပေးလိုက်တာကြောင့် plugin ကို synchronization အောင်မြင်ပြီလို့ ထင်စေခဲ့ပါတယ်။

ကျွန်တော်သုံးခဲ့တဲ့ ဒုတိယ interceptorpre_get_postsချိတ်။ WordPress သည် ဒေတာဘေ့စ် query တစ်ခုကို လုပ်ဆောင်ခြင်းမပြုမီ ဤချိတ်ကို လှုံ့ဆော်ပေးသည်။ ကျွန်ုပ်၏ယုတ္တိဗေဒမှာ administrator တစ်ဦးက backend တွင် လုပ်ဆောင်ချက်တစ်ခုကို လုပ်ဆောင်တိုင်း သို့မဟုတ် plugin တစ်ခုက asynchronous/synchronous လုပ်ဆောင်ချက်များကို လုပ်ဆောင်သည့်အခါတိုင်း ဖယ်ထုတ်ထားသော ID များကို... ထဲသို့ ပေါင်းစည်းသင့်သည်။post__not_inကန့်သတ်ချက်များတွင်။

ရေးပြီးသွားတော့ ကျွန်တော် စမ်းသပ်ကြည့်တယ်။

အရင်ဆုံး backend ကိုသွားပြီး ချန်လှပ်ထားတဲ့ ဆောင်းပါးတစ်ခုကို ဖွင့်ပြီး အသေးစားပြောင်းလဲမှုအနည်းငယ်ပြုလုပ်ကာ update ကို နှိပ်လိုက်ပါတယ်။ အမှားအယွင်းမရှိဘဲ အောင်မြင်စွာ သိမ်းဆည်းနိုင်ခဲ့ပါတယ်။ ပြီးတော့ Meilisearch backend ကို စစ်ဆေးကြည့်တော့ ဆောင်းပါးရဲ့ index က မပြောင်းလဲဘဲ ရှိနေပါတယ်။ အသစ်ဘာမှ မပေါ်လာပါဘူး။

"Index Posts" ကို ပြန်နှိပ်ပြီး index တစ်ခုလုံးကို ပြန်တည်ဆောက်လိုက်တယ်။ ခဏစောင့်ပြီးတဲ့နောက် Meilisearch backend ကို စစ်ဆေးကြည့်တယ်။ အဲဒီချန်လှပ်ထားတဲ့ ဆောင်းပါးတွေက အဲဒီမှာပဲ ရှိနေတုန်းပဲ။

ပြီးပါပြီ။

နက်ရှိုင်းသော ခွဲခြမ်းစိတ်ဖြာမှု- နှစ်ထပ်အာမခံယန္တရားက ဘယ်လိုအလုပ်လုပ်သလဲ။

အမှန်အတိုင်းပြောရရင် ဒီဖြစ်စဉ်က ကျွန်တော့်ကို အတော်လေးစိတ်ဝင်စားစရာကောင်းတဲ့ အရာတစ်ခုကို သတိရစေခဲ့တယ်။

၁၈၈၀ ပြည့်လွန်နှစ်တွေတုန်းက အမေရိကန်မှာ လျှပ်စစ်ဓာတ်အား ကျယ်ကျယ်ပြန့်ပြန့် သုံးစွဲလာတဲ့အချိန်မှာ စက်ရုံပိုင်ရှင်တော်တော်များများက ဂျင်နရေတာတွေနဲ့ လျှပ်စစ်မော်တာတွေ ဝယ်ယူပြီး သူတို့ရဲ့စက်ရုံတွေမှာ တပ်ဆင်ဖို့ ငွေအများကြီး သုံးစွဲခဲ့ကြပါတယ်။ ဒါပေမယ့် တပ်ဆင်ပြီးတဲ့နောက်မှာတော့ ထုတ်လုပ်မှုထိရောက်မှုက သိသိသာသာ မတိုးတက်လာဘူးဆိုတာကို လူအတော်များများ တွေ့ရှိခဲ့ကြပါတယ်။

အဘယ်ကြောင့်?

အဘယ်ကြောင့်ဆိုသော် ၎င်းတို့သည် ရေနွေးငွေ့အင်ဂျင်ကို လျှပ်စစ်မော်တာဖြင့် အစားထိုးလိုက်ရုံသာဖြစ်သော်လည်း စက်ရုံ၏ အလုံးစုံအပြင်အဆင်၊ လုပ်ငန်းစဉ်များနှင့် စီမံခန့်ခွဲမှုနည်းလမ်းများမှာ မပြောင်းလဲဘဲ ရှိနေသောကြောင့်ဖြစ်သည်။ လျှပ်စစ်ဓာတ်အားသည် အသစ်အဆန်းဖြစ်သော်လည်း ၎င်းကိုအသုံးပြုခြင်းဆိုင်ရာ အတွေးအခေါ်မှာ ရှေးရိုးစွဲဖြစ်သည်။

လျှပ်စစ်ဓာတ်အားတိုးတက်မှုမှ အမှန်တကယ် အကျိုးကျေးဇူးရရှိသူများသည် "လျှပ်စစ်ဓာတ်အား၏ အဓိပ္ပာယ်" ကို နားလည်သော ပထမဆုံးအုပ်စုဖြစ်သည်။ သူတို့သည် ၎င်းတို့၏ ဓာတ်အားအရင်းအမြစ်ကို ပြောင်းလဲရုံသာမက ၎င်းတို့၏ ထုတ်လုပ်မှုလုပ်ငန်းစဉ်တစ်ခုလုံးကို ပြန်လည်ဒီဇိုင်းထုတ်ခဲ့ကြသည်။

AI ခေတ် အတွက်လည်း အတူတူပါပဲ ။ လူအများစုက AI ကို ကိရိယာတစ်ခုအဖြစ် အသုံးပြုကြပေမယ့် အခြေခံယုတ္တိဗေဒက ဘာကိုပြောင်းလဲစေလဲဆိုတာ အနည်းငယ်သာ စဉ်းစားကြပါတယ်။ ကိရိယာကိုယ်တိုင်က အသစ်ဖြစ်ပေမယ့် အသုံးပြုခဲ့တဲ့ အတွေးအခေါ်ကတော့ ခေတ်နောက်ကျနေနိုင်ပါတယ်။

ဥပမာအားဖြင့် WordPress search blocking ကို setup လုပ်နေတုန်း plugin documentation ထဲက standard method တွေကိုပဲ လိုက်နာမယ်ဆိုရင် အလုပ်လုပ်နိုင်မှာ မဟုတ်ပါဘူး။ အကြောင်းကတော့ Scry Search ရဲ့ synchronization logic ဟာ ရိုးရာ "save one article, synchronize one article" approach မဟုတ်တော့ဘဲ asynchronous queues, batch processing နဲ့ သူ့ရဲ့ကိုယ်ပိုင် mechanisms တွေ ပါဝင်လို့ပါ။

တကယ့် ထိုးဖောက်အောင်မြင်မှုကို ရှာတွေ့နိုင်ဖို့ ဒီယန္တရား ဘယ်လိုအလုပ်လုပ်လဲဆိုတာကို နားလည်ဖို့ လိုပါတယ်။

အစီအစဉ်၏ ကန့်သတ်ချက်များနှင့် ကြိုတင်ကာကွယ်မှုများ

ဒါပေမယ့် ဒီအစီအစဉ်ကလည်း ပြီးပြည့်စုံတယ်လို့ ပွင့်ပွင့်လင်းလင်း ပြောရမယ်။

၎င်းတွင် သိသာထင်ရှားသော ကန့်သတ်ချက်တစ်ခုရှိသည်- ၎င်းသည် အနာဂတ် ထပ်တူပြုမှုများကိုသာ စီမံခန့်ခွဲနိုင်ပြီး Meilisearch တွင် ရှိပြီးသား သမိုင်းဝင်မှတ်တမ်းများကို အလိုအလျောက် ဖျက်ပစ်နိုင်မည်မဟုတ်ပါ။ တစ်နည်းအားဖြင့် သင်သည် ထိုဆောင်းပါးများကို ထပ်တူပြုပြီးပါက Meilisearch dashboard ရှိ ဒေတာဟောင်းများကို ကိုယ်တိုင်ဖျက်ရန် သို့မဟုတ် API command များကို အသုံးပြုရန် လိုအပ်ပါသည်။

ဒါက တစ်ကြိမ်တည်းလုပ်ရတဲ့ အလုပ်ပါ။ ပြီးသွားရင် စိတ်ပူစရာမလိုတော့ပါဘူး။ ဒါပေမယ့် ကုဒ်ကို ဖြန့်ကျက်ပြီးနောက်မှာ ရှာဖွေမှုရလဒ်တွေမှာ အဲဒီဆောင်းပါးတွေကို မတွေ့ရတော့ဘဲ ကုဒ်က အသက်မဝင်သေးဘူးလို့ မယူဆရအောင် ကြိုတင်ရှင်းပြထားဖို့ လိုပါတယ်။

သတိပြုရမည့် နောက်ထပ်အချက်တစ်ခုမှာ ဤချဉ်းကပ်မှုသည် WordPress ၏ အခြေခံကွန်ရက်နှင့် ဒေတာဘေ့စ်ဗိသုကာပေါ်တွင် မူတည်သည်။ Scry Search plugin ၏ အနာဂတ်ဗားရှင်းများသည် ဤဗိသုကာပုံစံအပေါ် အခြေခံ၍ ဆက်လက်လည်ပတ်နေသရွေ့ ဤ interceptor သည် ထိရောက်မှုရှိနေမည်ဖြစ်သည်။ သို့သော် ၎င်းသည် လုံးဝကွဲပြားသော ထပ်တူပြုခြင်းယန္တရားသို့ ပြောင်းလဲသွားပါက ပြန်လည်လိုက်လျောညီထွေဖြစ်အောင် လုပ်ဆောင်ရန် လိုအပ်နိုင်သည်။

ဒါပေမယ့် အမှန်အတိုင်းပြောရရင် ဒါက မဖြစ်နိုင်သလောက်ပါပဲ။ WordPress ဂေဟစနစ်တစ်ခုလုံးကို ဒီဗိသုကာပုံစံနဲ့ တည်ဆောက်ထားပြီး plugin တွေက ဒါကို လုံးဝကျော်သွားဖို့ မဖြစ်နိုင်ပါဘူး။

အကောင်အထည်ဖော်ရန် အဆင့်သုံးဆင့်လမ်းညွှန်

/**
 * 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 plugin ကိုသုံးပြီး ထည့်ပါ။ ပြီးရင် အပေါ်ဆုံးမှာ...defineအစုအဝေးတွင်၊ သင်ဖယ်ထုတ်လိုသော ဆောင်းပါး သို့မဟုတ် စာမျက်နှာ၏ ID ကို ရိုက်ထည့်ပါ။

ဒုတိယအဆင့်ကတော့ သမိုင်းဝင် အညွှန်းတွေကို သန့်ရှင်းရေးလုပ်ဖို့ပါ။ Meilisearch dashboard ထဲကို ဝင်ပါ ဒါမှမဟုတ် ချန်လှပ်ထားတဲ့ ဆောင်းပါးတွေအတွက် အညွှန်းဒေတာဟောင်းကို ကိုယ်တိုင်ဖျက်ဖို့ API command တွေကို အသုံးပြုပါ။

တတိယအဆင့်ကတော့ စမ်းသပ်ခြင်းပါ။ backend ကိုသွားပြီး ဖယ်ထုတ်ထားတဲ့ဆောင်းပါးမှာ အသေးစားပြောင်းလဲမှုတွေလုပ်ပါ၊ update ကိုနှိပ်ပြီး Meilisearch backend ကိုစစ်ဆေးပါ။ index အသစ်မပေါ်ဘူးဆိုရင် ပိတ်ဆို့ခြင်းအကျိုးသက်ရောက်ပါပြီ။

အမှန်အတိုင်းပြောရရင် ဒီလို နည်းပညာဆိုင်ရာ မျှဝေဆောင်းပါးတွေ ရေးရတာကို ကျွန်တော် အမြဲတမ်း အပြစ်ရှိတယ်လို့ ခံစားရတယ်။

ကျွန်တော်မျှဝေတဲ့အရာတွေက တချို့လူတွေအတွက် အသုံးဝင်နိုင်ပေမယ့် တချို့အတွက်တော့ အခြေခံလုပ်ဆောင်ချက်တွေပါပဲ။

ဒါပေမယ့် ဒီတစ်ခါ WordPress ရှာဖွေမှုပိတ်ဆို့ခြင်းကို အကောင်အထည်ဖော်တဲ့ လုပ်ငန်းစဉ်က တကယ်ကို ထိုးထွင်းသိမြင်မှုရှိပါတယ်။ မကြာခဏဆိုသလို၊ ကျွန်ုပ်တို့ကြုံတွေ့ရတဲ့ ပြဿနာတွေဟာ ဖြေရှင်းချက်မရှိခြင်းကြောင့် မဟုတ်ဘဲ၊ ကျွန်ုပ်တို့ရဲ့ အတွေးအခေါ်တွေဟာ ရှိပြီးသား မူဘောင်တွေကြောင့် အကန့်အသတ်ရှိလို့ပါ။

Scry Search plugin က filtering hook တစ်ခု ပေးစွမ်းတာကြောင့် ဒါဟာ တစ်ခုတည်းသော ရွေးချယ်စရာပဲလို့ ယုံကြည်စေပါတယ်။ ဒါပေမယ့် WordPress ရဲ့ architecture တစ်ခုလုံးက ဖြစ်နိုင်ခြေ အများကြီး ပိုရှိပါတယ်။ interception ကို network layer မှာ ပြုလုပ်နိုင်သလို database layer မှာလည်း ပြုလုပ်နိုင်ပါတယ်။ သင်စဉ်းစားဖို့ ဆန္ဒရှိနေသရွေ့ နည်းလမ်းတစ်ခု အမြဲရှိပါတယ်။

အဲဒါကြောင့် ဒီနည်းပညာပစ္စည်းတွေကို ကျွန်တော် ပြင်ရတာ နှစ်သက်တာပါ။ ကြွားဝါတာ ဒါမှမဟုတ် အထင်ကြီးစရာကောင်းအောင် ကြိုးစားတာ မဟုတ်ပါဘူး။ ပြဿနာတစ်ခုကို အပြည့်အဝ နားလည်တယ်ဆိုတဲ့ ခံစားချက်က အရမ်းကျေနပ်စရာကောင်းလို့ပါ။

ဒီတစ်ခါလိုပဲ၊ အစပိုင်းရှုပ်ထွေးမှုကနေ အလယ်မှာ ဆင်ခြင်တုံတရား၊ နောက်ဆုံးအဖြေအထိ လုပ်ငန်းစဉ်တစ်ခုလုံးက ပဟေဠိတစ်ခုကို ဖြေရှင်းနေရသလိုပါပဲ။

လျှို့ဝှက်ချက်ကို ဖြေရှင်းပြီးပါပြီ၊ အဖြေကို ဖော်ထုတ်ပြီးပါပြီ၊ အဲဒါက အရမ်းရိုးရှင်းတယ်ဆိုတာ သိလိုက်ရပါတယ်။

ဒါပေမယ့် အဲဒီရှုပ်ထွေးတဲ့ လုပ်ငန်းစဉ်ကို မဖြတ်သန်းဖူးဘူးဆိုရင် ဒီရိုးရှင်းတဲ့ ပျော်ရွှင်မှုကို ဘယ်တော့မှ နားလည်မှာ မဟုတ်ပါဘူး။

ဒီအထိဖတ်ပြီးပြီဆိုတော့ အသုံးဝင်ရင် like လုပ်ပြီး share လုပ်ပေးပါ။ update တွေကို ဦးစွာရယူချင်ရင် ကျွန်တော့်ကို follow လုပ်နိုင်ပါတယ်။

ကျွန်တော့်ရဲ့ဆောင်းပါးကို ဖတ်ရှုပေးတဲ့အတွက် ကျေးဇူးတင်ပါတယ်။ နောက်တစ်ကြိမ်မှာ ပြန်ဆုံကြမယ်။