MDTF

encode_search_get_params() reçoit le formulaire sérialisé par ajax, l'analyse et l'assainit, retire les valeurs '~' (any) et stocke le reste en JSON base64 avec set_page_mdf_session(). Selon le réglage keep_search_data_in, les données vont dans un transient pour un jour ou dans $_SESSION. La réponse est mdf_cat=...&page_mdf=<key>, que le front office transforme en lien des résultats.

get_search_data_key() hache la sortie de normalize_search_data(), qui parcourt le tableau récursivement, trie les clés associatives et conserve l'ordre des listes. L'ordre des champs venant du navigateur n'a plus d'importance, si bien qu'une recherche correspond à un transient et à un lien. Les liens avec d'anciennes clés continuent de fonctionner tant que leur transient existe.

mdf_encode_search_get_params est enregistré pour les visiteurs non connectés, et chaque recherche distincte écrit un transient qui vit un jour. Le gestionnaire vérifie que vars est une chaîne de longueur inférieure à mdf_search_data_max_length et, sinon, répond mdf_cat=-1 sans rien stocker. Une clé fournie n'est acceptée que si elle correspond à /^[0-9a-f]{32}$/, sinon la clé est dérivée des données.

get_page_mdf_data() traite tout ce qui ne se décode pas en tableau comme une absence de recherche. Elle fusionne les options par défaut du widget et, pour chaque champ medafi_, convertit 'from' et 'to' en nombres, si bien que les valeurs de plage et de calendrier atteignent meta_query sous forme de nombres quoi que le visiteur ait envoyé. Le résultat décodé est conservé dans une variable statique pour le reste de la requête.

Les liens constants sont un type de contenu caché distinct. Son save_post() stocke la recherche encodée dans page_mdf_string. get_page_mdf_session() vérifie la clé : numérique signifie un ID de post et lit la meta stockée, tout le reste va au stockage par transient ou par session. Les résultats, les compteurs et les templates n'ont pas besoin de savoir quel type de lien a été utilisé.

Dans get_meta_query_array(), le cas du curseur compare le 'to' sélectionné au maximum propre au curseur ; s'ils sont égaux, la borne supérieure devient MetaDataFilterCore::$max_int, si bien que les contenus dont les valeurs dépassent l'échelle configurée correspondent toujours. Les listes déroulantes de plage utilisent la même idée avec un suffixe 'i' (infini) tel que '1001-i'. Les curseurs simples et les listes déroulantes de plage utilisent BETWEEN avec le type DECIMAL.

Pour les curseurs avec slider_range_value = 1, un contenu stocke deux valeurs, la clé du champ et key_to (par exemple une fourchette de prix ou de surface). Le visiteur choisit une valeur, et la requête exige qu'elle tombe dans la fourchette propre au contenu, les deux côtés typés DECIMAL.

L'élément calendrier stocke <key>_from et <key>_to. Seul 'to' renseigné donne _to <= to ; seul 'from' renseigné donne _from >= from ; des valeurs égales correspondent aux éléments dont la période couvre ce jour ; une vraie période devient BETWEEN sur _from. Un commentaire dans le code date la dernière branche du 08-10-2014.

Un élément texte peut cibler sa propre valeur meta ou post_title, post_content, ou les deux avec OR ou AND. Pour les colonnes du post, la condition est transmise aux filtres MDTF_HELPER sur posts_where, qui découpent l'expression en mots (modifiable avec mdf_txtsearch_some_words_behavior) et les assemblent avec mdf_txtsearch_some_words_condition, AND par défaut. Les espaces répétées sont d'abord réduites.

Un champ marqué is_reflected porte reflected_key. Le constructeur de requêtes, le séparateur OR et l'API publique get_field() utilisent tous la clé reflétée, si bien qu'un filtre peut travailler sur des meta écrites par le thème ou une autre extension sans copier les valeurs dans des clés medafi_.

wrap_meta_query() construit une relation AND et imbrique les conditions combinables en OR dans un groupe de relation OR, seulement s'il y en a deux ou plus. mdf_hide_post NOT EXISTS, meta_data_filter_cat, _visibility et _stock_status vont au niveau supérieur et s'appliquent toujours. La même enveloppe est utilisée par la requête de résultats et par les compteurs.

Le séparateur associe chaque clé de recherche (propre ou reflétée) à son type d'élément à partir des sections de filtre de la recherche. Les clauses des éléments case à cocher et libellé deviennent combinables en OR ; les curseurs, listes déroulantes, saisies de texte, calendriers et listes déroulantes de plage restent obligatoires. En mode AND, le tableau est renvoyé inchangé, si bien que les recherches AND existantes produisent le même SQL qu'avant.

Une fois que des filtres tiers (mdf_filter_taxonomies, taxonomies supplémentaires, product_visibility) ont modifié la tax_query, le séparateur compare chaque clause à la liste construite à partir du formulaire avec array_search strict. Les correspondances sont des conditions du visiteur, le reste est obligatoire. Les clauses répétées du visiteur que le filtre a collectées par requête sont supprimées. wrap_tax_query() n'imbrique ensuite sous OR que la partie du visiteur.

encode_search_get_params() écrit meta_data_filter_bool et mdf_tax_bool dans mdf_widget_options de la recherche stockée, en prenant le choix du visiteur lorsque le widget autorise les deux. get_meta_data_filter_bool() et get_mdf_tax_bool() lisent d'abord la valeur stockée et normalisent en 'AND' tout ce qui n'est pas 'OR'. Les résultats, les compteurs, le recomptage ajax, la pagination et le tri lisent le même état.

Les widgets enregistrés par d'anciennes versions ont toujours cherché dans les taxonomies avec AND, quoi que dise leur option OR. Leur appliquer l'option changerait les résultats sur des sites en production sans aucune action du propriétaire. get_widget_tax_bool() ne respecte l'option que si taxonomies_options_behaviour_ver est défini, ce qui arrive quand le widget est enregistré par la nouvelle version.

tax_query inclut les enfants par défaut ; un parent coché correspondrait donc à tous les contenus en dessous et rendrait la sélection de l'enfant sans objet. get_tax_query_array() retire un terme coché si get_term_children() de ce terme croise l'ensemble coché, puis réindexe la liste.

get_item_posts_count() part de la recherche courante. Une case à cocher ajoute key = 1 si elle n'y est pas déjà. Une option de liste déroulante retire d'abord la clause de la même clé, car les options sœurs s'excluent mutuellement, puis s'ajoute elle-même (sous forme de BETWEEN pour les options de plage). Pour les termes, get_tax_count() injecte le terme dans une copie de l'état de la taxonomie avec le cache de taxonomie par requête désactivé, et le restaure ensuite.

Les requêtes de comptage ne demandent que les ID, avec update_post_meta_cache, update_post_term_cache et cache_results désactivés. WP_QueryMDFCounterIn étend WP_Query et surcharge set_found_posts() pour ne rien faire, si bien que WordPress n'exécute pas l'étape found-rows supplémentaire ; post_count est la réponse.

WP_QueryMDFCounter hache le tableau complet d'arguments et le cherche dans une table à deux colonnes dotée d'un index sur mkey ; en cas d'absence, elle exécute la requête et insère le compte. La page de réglages crée la table et désactive l'option, en affichant l'instruction CREATE, si l'utilisateur de la base n'a pas le privilège. Un administrateur vide le cache depuis la page de réglages, ce qui exécute un TRUNCATE derrière manage_options et un nonce.

get_terms() charge une fois tous les termes de la taxonomie et assemble_terms_childs() construit les listes d'enfants à partir de ce tableau. Avec cache_terms_data activé, le résultat est stocké sous mdf_terms_cache_<md5 des arguments> dans un transient dont la durée vient du réglage de la période du cache des termes (de une heure à 7 jours ; sans expiration si aucune période n'est définie).

is_should_init() s'exécute avant que l'extension n'enregistre ses types de contenu et ses hooks. Si init_on_pages_only est défini, elle normalise l'URL courante (chaîne de requête et /page/N retirées) et retourne tôt si l'URL ne figure pas dans la liste. Les requêtes d'administration s'initialisent toujours.

save_post() écrit page_meta_data_filter comme un seul tableau, que l'écran d'édition relit, puis écrit chaque champ medafi_ avec update_post_meta(), que meta_query peut utiliser. Les sections de filtre et leurs éléments sont stockés comme meta html_items du type de contenu caché meta_data_filter.

Les champs de l'ancienne catégorie de filtre resteraient sinon dans wp_postmeta et correspondraient aux recherches de cette catégorie. save_post() compare la catégorie envoyée à celle qui est stockée et supprime toutes les lignes medafi_% du contenu lorsqu'elle a changé.

change_meta_key() exige le préfixe medafi_, rejette une clé déjà utilisée dans cette section ou dans toute autre section de filtre et nomme la section en conflit. Elle renomme ensuite la clé dans html_items, réécrit les tableaux page_meta_data_filter des contenus concernés et exécute UPDATE postmeta SET meta_key. Elle exige un nonce, edit_post et edit_others_posts, car elle touche tous les contenus.

parse_query() marque la requête principale comme une recherche du type de contenu demandé. pre_get_posts() affiche [meta_data_filter_results] sans template ; cette vue déclare global $wp_query et lui assigne un nouveau WP_Query construit à partir de la recherche. Un indicateur de requête empêche la réentrance, car la nouvelle requête redéclenche pre_get_posts. Le filtre mdtf_prohibited_post_types garde hors de ce mécanisme les requêtes internes d'ACF et de Contact Form 7.

Les résultats, les compteurs d'éléments et les compteurs de termes se branchent tous sur WOOCOMMERCE_VERSION : à partir de 3.0, ils ajoutent une tax_query qui exclut exclude-from-catalog, les versions antérieures reçoivent une clause meta _visibility IN (catalog, visible). Une clause _stock_status facultative masque les produits en rupture de stock. Avec WPML actif, chaque requête reçoit aussi la langue courante.

Les options de liste déroulante enregistrées par d'anciennes versions du constructeur ont une clé vide, alors que la meta box du contenu stocke le titre de l'option comme valeur. Au lieu d'une migration, fill_select_keys() s'exécute dans get_html_items() et à l'enregistrement, remplit les clés vides avec le titre nettoyé et laisse intactes les clés explicites, y compris '0'. Les valeurs existantes des contenus correspondent sans qu'il faille réenregistrer les contenus.

Un Legacy Widget dans un bloc n'a pas de barre latérale où le recomptage pourrait le trouver par son ID, son formulaire porte donc la classe et les options du widget. get_widget_redraw_data() les signe avec wp_hash() ; get_widget_from_redraw_data() vérifie avec hash_equals() et n'accepte que MetaDataFilter_Search et MetaDataFilter_TaxSearch avant d'appeler the_widget().

sanitize_template_path() normalise les barres obliques, filtre chaque segment vers un jeu de caractères sûr et supprime les segments vides, de sorte qu'une valeur ne peut pas sortir du dossier des templates tandis que des sous-dossiers comme any/my_posts continuent de fonctionner.

save_post() retire du tableau envoyé toute clé sans le préfixe medafi_ avant de le stocker et revérifie le préfixe avant chaque appel à update_post_meta(), de sorte que le formulaire ne peut pas définir _edit_lock, _price ou des clés similaires. L'enregistrement des valeurs exige current_user_can('edit_post').

Le vidage du cache exige manage_options et mdtf_ajax_nonce. Le renommage de clé exige son propre nonce, edit_post et edit_others_posts. Les actions sur les champs de widget exigent edit_theme_options. Les visiteurs non connectés n'atteignent que les actions de recherche du front office (enfants de termes, encodage de la recherche, recomptage, panneau de recherche, contenu du bouton de recherche). Les autres gestionnaires enregistrés pour eux vérifient eux-mêmes l'accès : les actions d'abonnement du messager exigent une connexion et un nonce, l'assistant de statistiques exige manage_options.