MDTF

encode_search_get_params() erhält das serialisierte Formular per AJAX, parst und bereinigt es, entfernt '~'-Werte (beliebig) und speichert den Rest mit set_page_mdf_session() als Base64-JSON. Je nach Einstellung keep_search_data_in gehen die Daten einen Tag lang in einen Transient oder nach $_SESSION. Die Antwort ist mdf_cat=...&page_mdf=<key>, woraus das Frontend den Ergebnislink macht.

get_search_data_key() hasht die Ausgabe von normalize_search_data(), das das Array rekursiv durchläuft, assoziative Schlüssel sortiert und die Reihenfolge von Listen beibehält. Die Feldreihenfolge aus dem Browser spielt keine Rolle mehr, sodass eine Suche auf einen Transient und einen Link abgebildet wird. Links mit älteren Schlüsseln funktionieren weiter, solange ihr Transient lebt.

mdf_encode_search_get_params ist für nicht angemeldete Besucher registriert, und jede verschiedene Suche schreibt einen Transient, der einen Tag lebt. Der Handler prüft, dass vars ein String innerhalb von mdf_search_data_max_length ist, und antwortet andernfalls mit mdf_cat=-1, ohne zu speichern. Ein übergebener Schlüssel wird nur akzeptiert, wenn er auf /^[0-9a-f]{32}$/ passt, sonst wird der Schlüssel aus den Daten abgeleitet.

get_page_mdf_data() behandelt alles, was nicht zu einem Array dekodiert, als keine Suche. Es führt die Standard-Widget-Optionen zusammen und wandelt für jedes Feld medafi_ 'from' und 'to' in Zahlen um, sodass Bereichs- und Kalenderwerte als Zahlen in meta_query ankommen, was immer der Besucher gesendet hat. Das dekodierte Ergebnis wird für den Rest des Requests in einer statischen Variable gehalten.

Konstante Links sind ein separater versteckter Post-Type. Sein save_post() speichert die kodierte Suche in page_mdf_string. get_page_mdf_session() prüft den Schlüssel: numerisch bedeutet eine Post-ID und liest das gespeicherte Meta, alles andere geht an den Transient- oder Session-Speicher. Ergebnisse, Zähler und Templates müssen nicht wissen, welche Art von Link verwendet wurde.

In get_meta_query_array() vergleicht der Schieberegler-Fall das gewählte 'to' mit dem eigenen Maximum des Reglers; sind sie gleich, wird die obere Grenze zu MetaDataFilterCore::$max_int, sodass Beiträge mit Werten oberhalb der konfigurierten Skala weiter passen. Bereichs-Dropdowns nutzen dieselbe Idee mit einem Suffix 'i' (Unendlich) wie '1001-i'. Einzelne Schieberegler und Bereichs-Dropdowns verwenden BETWEEN mit dem Typ DECIMAL.

Bei Schiebereglern mit slider_range_value = 1 speichert ein Beitrag zwei Werte, den Feldschlüssel und key_to (zum Beispiel eine Preis- oder Größenspanne). Der Besucher wählt einen Wert, und die Abfrage verlangt, dass er innerhalb der eigenen Spanne des Beitrags liegt, beide Seiten als DECIMAL typisiert.

Das Kalenderelement speichert <key>_from und <key>_to. Nur 'to' gesetzt ergibt _to <= to; nur 'from' ergibt _from >= from; gleiche Werte treffen Elemente, deren Spanne diesen Tag abdeckt; eine echte Spanne wird zu BETWEEN auf _from. Ein Code-Kommentar datiert den letzten Zweig auf 08-10-2014.

Ein Textelement kann auf seinen eigenen Meta-Wert oder auf post_title, post_content oder beide mit OR oder AND zielen. Für die Post-Spalten wird die Bedingung an MDTF_HELPER-Filter auf posts_where übergeben, die die Phrase in Wörter zerlegen (umschaltbar mit mdf_txtsearch_some_words_behavior) und sie mit mdf_txtsearch_some_words_condition verbinden, standardmäßig AND. Mehrfache Leerzeichen werden zuvor zusammengefasst.

Ein als is_reflected markiertes Feld trägt reflected_key. Der Query-Builder, der OR-Splitter und die öffentliche API get_field() verwenden alle den reflected key, sodass ein Filter auf Meta arbeiten kann, das vom Theme oder einem anderen Plugin geschrieben wurde, ohne Werte in medafi_-Schlüssel zu kopieren.

wrap_meta_query() baut relation AND und verschachtelt die per OR verknüpfbaren Bedingungen als eine Gruppe relation OR, nur wenn es zwei oder mehr sind. mdf_hide_post NOT EXISTS, meta_data_filter_cat, _visibility und _stock_status stehen auf oberster Ebene und gelten immer. Derselbe Wrapper wird von der Ergebnisabfrage und von den Zählern verwendet.

Der Splitter ordnet jeden Suchschlüssel (eigen oder reflected) dem Typ seines Elements aus den Filterabschnitten der Suche zu. Klauseln von Checkbox- und Label-Elementen werden per OR verknüpfbar; Schieberegler, Dropdowns, Texteingaben, Kalender und Bereichs-Dropdowns bleiben erforderlich. Im AND-Modus wird das Array unverändert zurückgegeben, sodass bestehende AND-Suchen dasselbe SQL erzeugen wie zuvor.

Nachdem Filter von Drittanbietern (mdf_filter_taxonomies, zusätzliche Taxonomien, product_visibility) die tax_query verändert haben, vergleicht der Splitter jede Klausel mit der aus dem Formular aufgebauten Liste mit striktem array_search. Treffer sind Besucherbedingungen, der Rest ist erforderlich. Wiederholte Besucherklauseln, die der Filter pro Request gesammelt hat, werden verworfen. wrap_tax_query() verschachtelt danach nur den Besucheranteil unter OR.

encode_search_get_params() schreibt meta_data_filter_bool und mdf_tax_bool in mdf_widget_options der gespeicherten Suche und übernimmt die Wahl des Besuchers, wenn das Widget beides erlaubt. get_meta_data_filter_bool() und get_mdf_tax_bool() lesen zuerst den gespeicherten Wert und normalisieren alles, was nicht 'OR' ist, zu 'AND'. Ergebnisse, Zähler, AJAX-Neuzählung, Paginierung und Sortierung lesen denselben Zustand.

Von älteren Versionen gespeicherte Widgets haben Taxonomien immer mit AND durchsucht, was immer ihre OR-Option sagte. Die Option auf sie anzuwenden würde Ergebnisse auf Live-Websites ohne jede Handlung des Inhabers verändern. get_widget_tax_bool() beachtet die Option nur, wenn taxonomies_options_behaviour_ver gesetzt ist, was geschieht, wenn das Widget von der neuen Version gespeichert wird.

tax_query schließt Kinder standardmäßig ein, daher würde ein angehakter Elternterm jeden Beitrag darunter treffen und die Auswahl des Kindes bedeutungslos machen. get_tax_query_array() entfernt einen angehakten Term, wenn get_term_children() von ihm die angehakte Menge schneidet, und indiziert die Liste dann neu.

get_item_posts_count() beginnt bei der aktuellen Suche. Eine Checkbox fügt key = 1 hinzu, sofern es nicht schon da ist. Eine Dropdown-Option entfernt zuerst die Klausel desselben Schlüssels, weil Geschwisteroptionen sich ausschließen, und fügt dann sich selbst hinzu (bei Bereichsoptionen als BETWEEN). Für Terme fügt get_tax_count() den Term in eine Kopie des Taxonomie-Zustands ein, mit abgeschaltetem Tax-Cache pro Request, und stellt danach wieder her.

Zählabfragen verlangen nur IDs, mit ausgeschalteten update_post_meta_cache, update_post_term_cache und cache_results. WP_QueryMDFCounterIn erweitert WP_Query und überschreibt set_found_posts() mit nichts, sodass WordPress den zusätzlichen Found-Rows-Schritt nicht ausführt; post_count ist die Antwort.

WP_QueryMDFCounter hasht das vollständige Argument-Array und sucht es in einer Tabelle mit zwei Spalten und einem Index auf mkey; bei einem Fehltreffer führt es die Abfrage aus und fügt die Zahl ein. Die Einstellungsseite legt die Tabelle an und schaltet die Option mit der angezeigten CREATE-Anweisung aus, falls dem Datenbankbenutzer das Recht fehlt. Ein Admin leert den Cache über die Einstellungsseite, die hinter manage_options und einem Nonce ein TRUNCATE ausführt.

get_terms() lädt alle Terme der Taxonomie einmal, und assemble_terms_childs() baut die Kind-Listen aus diesem Array. Bei aktivem cache_terms_data wird das Ergebnis als Transient unter mdf_terms_cache_<md5 der Argumente> gespeichert, dessen Lebensdauer aus der Einstellung für den Zeitraum des Term-Caches stammt (stündlich bis 7 Tage; kein Ablauf, wenn kein Zeitraum gesetzt ist).

is_should_init() läuft, bevor das Plugin seine Post-Types und Hooks registriert. Ist init_on_pages_only gesetzt, normalisiert es die aktuelle URL (Query-String und /page/N entfernt) und kehrt früh zurück, wenn die URL nicht in der Liste steht. Admin-Requests initialisieren immer.

save_post() schreibt page_meta_data_filter als einzelnes Array, das der Bearbeitungsbildschirm zurückliest, und schreibt dann jedes Feld medafi_ mit update_post_meta(), das meta_query verwenden kann. Filterabschnitte und ihre Elemente werden als Meta html_items des versteckten Post-Types meta_data_filter gespeichert.

Felder der alten Filterkategorie würden sonst in wp_postmeta bleiben und Suchen dieser Kategorie treffen. save_post() vergleicht die gesendete Kategorie mit der gespeicherten und entfernt alle Zeilen medafi_% des Beitrags, wenn sie sich geändert hat.

change_meta_key() verlangt das Präfix medafi_, lehnt einen Schlüssel ab, der in diesem oder einem anderen Filterabschnitt bereits verwendet wird, und nennt den kollidierenden Abschnitt. Danach benennt es den Schlüssel in html_items um, schreibt die page_meta_data_filter-Arrays der betroffenen Beiträge neu und führt UPDATE postmeta SET meta_key aus. Es braucht einen Nonce, edit_post und edit_others_posts, weil es alle Beiträge berührt.

parse_query() markiert die Hauptabfrage als Suche des angeforderten Post-Types. pre_get_posts() rendert [meta_data_filter_results] ohne Template; diese View deklariert global $wp_query und weist eine neue, aus der Suche gebaute WP_Query zu. Ein Request-Flag verhindert den erneuten Eintritt, weil die neue Abfrage pre_get_posts erneut auslöst. Der Filter mdtf_prohibited_post_types hält interne Abfragen von ACF und Contact Form 7 heraus.

Ergebnisse, Element-Zähler und Term-Zähler verzweigen alle nach WOOCOMMERCE_VERSION: ab 3.0 fügen sie eine tax_query hinzu, die exclude-from-catalog ausschließt, frühere Versionen erhalten eine Meta-Klausel _visibility IN (catalog, visible). Eine optionale Klausel _stock_status blendet ausverkaufte Produkte aus. Bei aktivem WPML erhält außerdem jede Abfrage die aktuelle Sprache.

Von älteren Versionen des Konstruktors gespeicherte Dropdown-Optionen haben einen leeren Schlüssel, während die Meta-Box des Beitrags den Optionstitel als Wert speichert. Statt einer Migration läuft fill_select_keys() in get_html_items() und beim Speichern, füllt leere Schlüssel mit dem getrimmten Titel und lässt ausdrückliche Schlüssel, auch '0', unberührt. Bestehende Beitragswerte passen, ohne dass Beiträge neu gespeichert werden müssen.

Ein Legacy-Widget innerhalb eines Blocks hat keine Sidebar, in der die Neuzählung es per ID finden könnte, daher trägt sein Formular die Widget-Klasse und die Optionen. get_widget_redraw_data() signiert sie mit wp_hash(); get_widget_from_redraw_data() verifiziert mit hash_equals() und akzeptiert vor dem Aufruf von the_widget() nur MetaDataFilter_Search und MetaDataFilter_TaxSearch.

sanitize_template_path() normalisiert Slashes, filtert jedes Segment auf einen sicheren Zeichensatz und verwirft leere, sodass ein Wert den Template-Ordner nicht verlassen kann, während Unterordner wie any/my_posts weiter funktionieren.

save_post() entfernt jeden Schlüssel ohne das Präfix medafi_ aus dem gesendeten Array, bevor es gespeichert wird, und prüft das Präfix vor jedem Aufruf von update_post_meta() erneut, sodass das Formular weder _edit_lock noch _price oder ähnliche Schlüssel setzen kann. Das Speichern von Werten verlangt current_user_can('edit_post').

Das Leeren des Caches verlangt manage_options und mdtf_ajax_nonce. Das Umbenennen von Schlüsseln verlangt einen eigenen Nonce, edit_post und edit_others_posts. Aktionen für Widget-Felder verlangen edit_theme_options. Nicht angemeldete Besucher erreichen nur Frontend-Suchaktionen (Term-Kinder, Suchkodierung, Neuzählung, Suchpanel, Inhalt des Suchbuttons). Die anderen für sie registrierten Handler prüfen den Zugriff selbst: die Messenger-Abonnement-Aktionen verlangen Anmeldung und einen Nonce, der Statistik-Helfer verlangt manage_options.