MDTF

encode_search_get_params() отримує серіалізовану форму через ajax, розбирає й санітизує її, видаляє значення '~' (будь-яке) і зберігає решту як base64 JSON через set_page_mdf_session(). Залежно від налаштування keep_search_data_in дані потрапляють у transient на одну добу або в $_SESSION. Відповідь — mdf_cat=...&page_mdf=<key>, з якої фронтенд будує посилання на результати.

get_search_data_key() хешує вивід normalize_search_data(), яка рекурсивно обходить масив, сортує асоціативні ключі й зберігає порядок списків. Порядок полів із браузера більше не має значення, тож один пошук відповідає одному transient і одному посиланню. Посилання зі старішими ключами працюють, поки живе їхній transient.

mdf_encode_search_get_params зареєстровано для неавторизованих відвідувачів, і кожен окремий пошук записує transient, що живе добу. Обробник перевіряє, що vars є рядком у межах mdf_search_data_max_length, інакше відповідає mdf_cat=-1 без збереження. Наданий ключ приймається лише якщо збігається з /^[0-9a-f]{32}$/, інакше ключ виводиться з даних.

get_page_mdf_data() вважає все, що не декодується в масив, відсутністю пошуку. Вона зливає опції віджета за замовчуванням і для кожного поля medafi_ приводить 'from' і 'to' до чисел, тож значення діапазонів і календарів потрапляють у meta_query як числа, що б не надіслав відвідувач. Декодований результат зберігається в статичній змінній до кінця запиту.

Постійні посилання — це окремий прихований тип запису. Його save_post() зберігає закодований пошук у page_mdf_string. get_page_mdf_session() перевіряє ключ: числовий означає ID запису й читає збережене мета, усе інше йде в сховище transient або сесії. Результати, лічильники й шаблони не мусять знати, яке посилання було використано.

У get_meta_query_array() випадок повзунка порівнює вибране 'to' із власним максимумом повзунка; якщо вони рівні, верхня межа стає MetaDataFilterCore::$max_int, тож записи зі значеннями вище за налаштовану шкалу все одно збігаються. Випадні списки діапазонів використовують ту саму ідею із суфіксом 'i' (нескінченність), як-от '1001-i'. Одиночні повзунки й випадні списки діапазонів використовують BETWEEN з типом DECIMAL.

Для повзунків зі slider_range_value = 1 запис зберігає два значення: ключ поля й key_to (наприклад, діапазон ціни чи розміру). Відвідувач вибирає одне значення, і запит вимагає, щоб воно потрапляло в діапазон самого запису, обидві сторони типізовано як DECIMAL.

Елемент календаря зберігає <key>_from і <key>_to. Якщо задано лише 'to', виходить _to <= to; лише 'from' дає _from >= from; рівні значення відповідають позиціям, чий діапазон охоплює цей день; повноцінний діапазон стає BETWEEN за _from. Коментар у коді датує останню гілку 08-10-2014.

Текстовий елемент може націлюватися на власне мета-значення або на post_title, post_content, чи на обидва через OR або AND. Для колонок запису умова передається фільтрам MDTF_HELPER на posts_where, які ділять фразу на слова (перемикається через mdf_txtsearch_some_words_behavior) і з'єднують їх через mdf_txtsearch_some_words_condition, за замовчуванням AND. Повторні пробіли спершу згортаються.

Поле, позначене is_reflected, несе reflected_key. Конструктор запиту, розгалужувач OR і публічний API get_field() використовують віддзеркалений ключ, тож фільтр може працювати з мета, записаним темою чи іншим плагіном, без копіювання значень у ключі medafi_.

wrap_meta_query() будує relation AND і вкладає умови, до яких можна застосувати OR, як одну групу relation OR, лише коли їх дві або більше. mdf_hide_post NOT EXISTS, meta_data_filter_cat, _visibility і _stock_status потрапляють на верхній рівень і застосовуються завжди. Ту саму обгортку використовують запит результатів і лічильники.

Розгалужувач зіставляє кожен ключ пошуку (власний чи віддзеркалений) з типом його елемента за секціями фільтра в пошуку. Умови елементів checkbox і label стають придатними для OR; повзунки, випадні списки, текстові поля, календарі та випадні списки діапазонів лишаються обов'язковими. У режимі AND масив повертається без змін, тож наявні пошуки AND дають той самий SQL, що й раніше.

Після того як сторонні фільтри (mdf_filter_taxonomies, додаткові таксономії, product_visibility) змінили tax_query, розгалужувач порівнює кожну умову зі списком, побудованим із форми, через строгий array_search. Збіги — це умови відвідувача, решта — обов'язкові. Повторні умови відвідувача, які фільтр зібрав за запит, відкидаються. Потім wrap_tax_query() вкладає під OR лише частину відвідувача.

encode_search_get_params() записує meta_data_filter_bool і mdf_tax_bool у mdf_widget_options збереженого пошуку, беручи вибір відвідувача, коли віджет дозволяє обидва. get_meta_data_filter_bool() і get_mdf_tax_bool() спершу читають збережене значення й нормалізують усе, що не є 'OR', до 'AND'. Результати, лічильники, ajax-перерахунок, пагінація й сортування читають один і той самий стан.

Віджети, збережені старішими версіями, завжди шукали за таксономіями через AND, що б не казала їхня опція OR. Застосування опції до них змінило б результати на живих сайтах без жодної дії власника. get_widget_tax_bool() враховує опцію лише тоді, коли задано taxonomies_options_behaviour_ver, що відбувається, коли віджет зберігає нова версія.

tax_query за замовчуванням включає нащадків, тож позначений батько збігався б з кожним записом під ним і робив би вибір нащадка безглуздим. get_tax_query_array() видаляє позначений термін, якщо get_term_children() від нього перетинається з позначеною множиною, а потім переіндексовує список.

get_item_posts_count() починає з поточного пошуку. Checkbox додає key = 1, якщо його там ще немає. Опція випадного списку спершу видаляє умову того самого ключа, бо сусідні опції взаємовиключні, а потім додає себе (як BETWEEN для опцій діапазону). Для термінів get_tax_count() вставляє термін у копію стану таксономії з вимкненим кешем таксономій на запит і відновлює його після цього.

Запити лічильників просять лише ID з вимкненими update_post_meta_cache, update_post_term_cache і cache_results. WP_QueryMDFCounterIn розширює WP_Query і перевизначає set_found_posts() так, щоб вона нічого не робила, тож WordPress не виконує зайвого кроку found-rows; відповідь — це post_count.

WP_QueryMDFCounter хешує повний масив аргументів і шукає його в двоколонковій таблиці з індексом на mkey; при промаху виконує запит і вставляє лічильник. Сторінка налаштувань створює таблицю й вимикає опцію, показуючи оператор CREATE, якщо користувачеві БД бракує привілею. Адміністратор очищає кеш зі сторінки налаштувань, що виконує TRUNCATE за manage_options і nonce.

get_terms() один раз завантажує всі терміни таксономії, а assemble_terms_childs() будує списки нащадків з цього масиву. З увімкненим cache_terms_data результат зберігається під mdf_terms_cache_<md5 від аргументів> як transient, термін життя якого береться з налаштування періоду кешу термінів (від щогодини до 7 днів; без закінчення, коли період не задано).

is_should_init() виконується до того, як плагін реєструє свої типи записів і хуки. Якщо задано init_on_pages_only, вона нормалізує поточний URL (рядок запиту й /page/N видаляються) і завершується раніше, якщо URL немає в списку. Запити адмінки завжди ініціалізуються.

save_post() записує page_meta_data_filter як один масив, який зчитує екран редагування, а потім записує кожне поле medafi_ через update_post_meta(), що може використати meta_query. Секції фільтра та їхні елементи зберігаються як мета html_items прихованого типу запису meta_data_filter.

Поля старої категорії фільтра інакше лишилися б у wp_postmeta і збігалися б з пошуками цієї категорії. save_post() порівнює надіслану категорію зі збереженою і видаляє всі рядки medafi_% запису, коли вона змінилася.

change_meta_key() вимагає префікс medafi_, відхиляє ключ, що вже використовується в цій або будь-якій іншій секції фільтра, і називає секцію-конфліктника. Потім вона перейменовує ключ усередині html_items, переписує масиви page_meta_data_filter у зачеплених записах і виконує UPDATE postmeta SET meta_key. Вона потребує nonce, edit_post і edit_others_posts, бо зачіпає всі записи.

parse_query() позначає головний запит як пошук запитаного типу запису. pre_get_posts() відображає [meta_data_filter_results] без шаблону; це відображення оголошує global $wp_query і присвоює новий WP_Query, побудований із пошуку. Прапорець запиту запобігає повторному входу, бо новий запит знову запускає pre_get_posts. Фільтр mdtf_prohibited_post_types тримає внутрішні запити ACF і Contact Form 7 поза цим.

Результати, лічильники елементів і лічильники термінів розгалужуються за WOOCOMMERCE_VERSION: починаючи з 3.0 вони додають tax_query, що виключає exclude-from-catalog, а раніші версії отримують мета-умову _visibility IN (catalog, visible). Необов'язкова умова _stock_status ховає товари, яких немає в наявності. З активним WPML кожен запит також отримує поточну мову.

Опції випадних списків, збережені старішими версіями конструктора, мають порожній ключ, тоді як мета-блок запису зберігає назву опції як значення. Замість міграції fill_select_keys() виконується всередині get_html_items() і при збереженні, заповнюючи порожні ключі обрізаною назвою й не чіпаючи явні ключі, зокрема '0'. Наявні значення записів збігаються без повторного збереження записів.

Legacy Widget усередині блока не має бічної панелі, де перерахунок міг би знайти його за ID, тож його форма несе клас віджета й опції. get_widget_redraw_data() підписує їх через wp_hash(); get_widget_from_redraw_data() перевіряє через hash_equals() і перед викликом the_widget() приймає лише MetaDataFilter_Search і MetaDataFilter_TaxSearch.

sanitize_template_path() нормалізує слеші, фільтрує кожен сегмент до безпечного набору символів і відкидає порожні, тож значення не може вийти за межі теки шаблонів, а підпапки на кшталт any/my_posts працюють.

save_post() видаляє з надісланого масиву кожен ключ без префікса medafi_ перед збереженням і перевіряє префікс ще раз перед кожним викликом update_post_meta(), тож форма не може задати _edit_lock, _price чи подібні ключі. Збереження значень вимагає current_user_can('edit_post').

Очищення кешу вимагає manage_options і mdtf_ajax_nonce. Перейменування ключа вимагає власного nonce, edit_post і edit_others_posts. Дії з полями віджета вимагають edit_theme_options. Неавторизовані відвідувачі потрапляють лише до дій пошуку на фронтенді (нащадки термінів, кодування пошуку, перерахунок, панель пошуку, вміст кнопки пошуку). Інші обробники, зареєстровані для них, самі перевіряють доступ: дії підписки messenger вимагають входу й nonce, помічник статистики вимагає manage_options.