MDTF

encode_search_get_params() recibe por ajax el formulario serializado, lo analiza y lo sanea, elimina los valores '~' (cualquiera) y guarda el resto como JSON en base64 con set_page_mdf_session(). Según el ajuste keep_search_data_in, los datos van a un transient durante un día o a $_SESSION. La respuesta es mdf_cat=...&page_mdf=<key>, que el front end convierte en el enlace de resultados.

get_search_data_key() calcula el hash de la salida de normalize_search_data(), que recorre el array de forma recursiva, ordena las claves asociativas y mantiene el orden de las listas. El orden de los campos que envía el navegador ya no importa, así que una búsqueda se corresponde con un transient y un enlace. Los enlaces con claves anteriores siguen funcionando mientras viva su transient.

mdf_encode_search_get_params está registrado para visitantes sin sesión, y cada búsqueda distinta escribe un transient que vive un día. El manejador comprueba que vars sea una cadena dentro de mdf_search_data_max_length y, si no, responde mdf_cat=-1 sin guardar. Una clave suministrada se acepta solo si coincide con /^[0-9a-f]{32}$/; en caso contrario, la clave se deriva de los datos.

get_page_mdf_data() trata como ausencia de búsqueda todo lo que no se decodifica a un array. Combina las opciones por defecto del widget y, en cada campo medafi_, convierte 'from' y 'to' a números, de modo que los valores de rango y de calendario llegan a meta_query como números, sea lo que sea lo que envió el visitante. El resultado decodificado se conserva en una variable estática durante el resto de la petición.

Los enlaces constantes son un tipo de contenido oculto aparte. Su save_post() guarda la búsqueda codificada en page_mdf_string. get_page_mdf_session() comprueba la clave: numérica significa un ID de entrada y lee el meta guardado, cualquier otra cosa va al almacén de transients o de sesión. Los resultados, los contadores y las plantillas no necesitan saber de qué tipo de enlace se trata.

En get_meta_query_array(), el caso del slider compara el 'to' seleccionado con el máx. del propio slider; si son iguales, el límite superior pasa a ser MetaDataFilterCore::$max_int, de modo que las entradas con valores por encima de la escala configurada siguen coincidiendo. Los desplegables de rango usan la misma idea con un sufijo 'i' (infinito), como '1001-i'. Los sliders simples y los desplegables de rango usan BETWEEN con tipo DECIMAL.

En los sliders con slider_range_value = 1, una entrada guarda dos valores, la clave del campo y key_to (por ejemplo un tramo de precio o de tamaño). El visitante elige un valor, y la consulta exige que caiga dentro del tramo propio de la entrada, con ambos lados de tipo DECIMAL.

El elemento de calendario guarda <key>_from y <key>_to. Solo 'to' definido da _to <= to; solo 'from' da _from >= from; valores iguales coinciden con los elementos cuyo tramo cubre ese día; un tramo completo se convierte en BETWEEN sobre _from. Un comentario del código fecha la última rama el 08-10-2014.

Un elemento de texto puede apuntar a su propio valor meta o a post_title, post_content, o a ambos con OR o AND. Para las columnas de la entrada, la condición se pasa a los filtros de MDTF_HELPER en posts_where, que dividen la frase en palabras (se puede cambiar con mdf_txtsearch_some_words_behavior) y las unen con mdf_txtsearch_some_words_condition, AND por defecto. Los espacios repetidos se colapsan primero.

Un campo marcado is_reflected lleva reflected_key. El constructor de consultas, el separador de OR y la API pública get_field() usan la clave reflejada, de modo que un filtro puede trabajar sobre meta escrito por el tema u otro plugin sin copiar valores a claves medafi_.

wrap_meta_query() construye una relación AND y anida las condiciones combinables con OR como un único grupo de relación OR, solo cuando hay dos o más. mdf_hide_post NOT EXISTS, meta_data_filter_cat, _visibility y _stock_status van en el nivel superior y se aplican siempre. La misma envoltura la usan la consulta de resultados y los contadores.

El divisor asocia cada clave de búsqueda (propia o reflejada) con el tipo de su elemento a partir de las secciones de filtro de la búsqueda. Las cláusulas de los elementos checkbox y label pasan a ser combinables con OR; los sliders, desplegables, campos de texto, calendarios y desplegables de rango siguen siendo obligatorios. En el modo AND, el array se devuelve sin cambios, de modo que las búsquedas AND existentes producen el mismo SQL que antes.

Después de que los filtros de terceros (mdf_filter_taxonomies, taxonomías adicionales, product_visibility) hayan modificado la tax_query, el divisor compara cada cláusula con la lista construida a partir del formulario mediante array_search estricto. Las coincidencias son condiciones del visitante; el resto es obligatorio. Las cláusulas repetidas del visitante que el filtro recopiló por petición se descartan. wrap_tax_query() anida entonces solo la parte del visitante bajo OR.

encode_search_get_params() escribe meta_data_filter_bool y mdf_tax_bool en mdf_widget_options de la búsqueda guardada, tomando la elección del visitante cuando el widget permite ambos. get_meta_data_filter_bool() y get_mdf_tax_bool() leen primero el valor guardado y normalizan a 'AND' todo lo que no sea 'OR'. Los resultados, los contadores, el recuento por ajax, la paginación y la ordenación leen el mismo estado.

Los widgets guardados por versiones anteriores siempre han buscado en las taxonomías con AND, dijera lo que dijera su opción OR. Aplicarles la opción cambiaría los resultados en sitios en producción sin ninguna acción del propietario. get_widget_tax_bool() respeta la opción solo cuando taxonomies_options_behaviour_ver está definido, lo que ocurre cuando el widget se guarda con la nueva versión.

tax_query incluye los hijos por defecto, así que un padre marcado coincidiría con todas las entradas que hay bajo él y dejaría sin sentido la selección del hijo. get_tax_query_array() elimina un término marcado si get_term_children() de él se interseca con el conjunto marcado, y luego reindexa la lista.

get_item_posts_count() parte de la búsqueda actual. Un checkbox añade key = 1 si todavía no está. Una opción de desplegable elimina primero la cláusula de la misma clave, porque las opciones hermanas se excluyen entre sí, y luego se añade a sí misma (como BETWEEN para las opciones de rango). Para los términos, get_tax_count() inyecta el término en una copia del estado de la taxonomía con la caché de taxonomías por petición desactivada y la restaura después.

Las consultas de contadores piden solo IDs con update_post_meta_cache, update_post_term_cache y cache_results desactivados. WP_QueryMDFCounterIn extiende WP_Query y sobrescribe set_found_posts() para que no haga nada, de modo que WordPress no ejecuta el paso adicional de found-rows; post_count es la respuesta.

WP_QueryMDFCounter calcula el hash del array completo de argumentos y lo busca en una tabla de dos columnas con un índice en mkey; si no lo encuentra, ejecuta la consulta e inserta el recuento. La página de ajustes crea la tabla y desactiva la opción mostrando la sentencia CREATE si el usuario de la base de datos carece del privilegio. Un administrador vacía la caché desde la página de ajustes, lo que ejecuta un TRUNCATE protegido por manage_options y un nonce.

get_terms() carga una vez todos los términos de la taxonomía y assemble_terms_childs() construye las listas de hijos a partir de ese array. Con cache_terms_data activado, el resultado se guarda bajo mdf_terms_cache_<md5 de los argumentos> como un transient cuya vida útil procede del ajuste del periodo de caché de términos (de una hora a 7 días; sin caducidad cuando no se define periodo).

is_should_init() se ejecuta antes de que el plugin registre sus tipos de contenido y hooks. Si init_on_pages_only está activado, normaliza la URL actual (sin cadena de consulta ni /page/N) y termina pronto cuando la URL no está en la lista. Las peticiones de administración siempre se inicializan.

save_post() escribe page_meta_data_filter como un único array, que la pantalla de edición vuelve a leer, y después escribe cada campo medafi_ con update_post_meta(), que meta_query puede usar. Las secciones del filtro y sus elementos se guardan como meta html_items del tipo de contenido oculto meta_data_filter.

Los campos de la categoría de filtro anterior permanecerían en wp_postmeta y coincidirían con las búsquedas de esa categoría. save_post() compara la categoría enviada con la guardada y elimina todas las filas medafi_% de la entrada cuando ha cambiado.

change_meta_key() exige el prefijo medafi_, rechaza una clave ya usada en esta o en cualquier otra sección del filtro y nombra la sección en conflicto. Después renombra la clave dentro de html_items, reescribe los arrays page_meta_data_filter de las entradas afectadas y ejecuta UPDATE postmeta SET meta_key. Necesita un nonce, edit_post y edit_others_posts porque toca todas las entradas.

parse_query() marca la consulta principal como una búsqueda del tipo de contenido solicitado. pre_get_posts() renderiza [meta_data_filter_results] sin plantilla; esa vista declara global $wp_query y le asigna un nuevo WP_Query construido a partir de la búsqueda. Una bandera de petición impide la reentrada, porque la nueva consulta vuelve a disparar pre_get_posts. El filtro mdtf_prohibited_post_types mantiene fuera las consultas internas de ACF y Contact Form 7.

Los resultados, los contadores de elementos y los contadores de términos se ramifican según WOOCOMMERCE_VERSION: desde la 3.0 añaden una tax_query que excluye exclude-from-catalog; las versiones anteriores reciben una cláusula meta _visibility IN (catalog, visible). Una cláusula opcional _stock_status oculta los productos sin stock. Con WPML activo, cada consulta recibe además el idioma actual.

Las opciones de desplegable guardadas por versiones anteriores del constructor tienen una clave vacía, mientras que el meta box de la entrada guarda el título de la opción como valor. En lugar de una migración, fill_select_keys() se ejecuta dentro de get_html_items() y al guardar, rellenando las claves vacías con el título recortado y dejando intactas las claves explícitas, incluido '0'. Los valores existentes de las entradas coinciden sin volver a guardarlas.

Un Legacy Widget dentro de un bloque no tiene una barra lateral donde el recuento pueda encontrarlo por ID, así que su formulario lleva la clase y las opciones del widget. get_widget_redraw_data() las firma con wp_hash(); get_widget_from_redraw_data() verifica con hash_equals() y acepta solo MetaDataFilter_Search y MetaDataFilter_TaxSearch antes de llamar a the_widget().

sanitize_template_path() normaliza las barras, filtra cada segmento a un juego de caracteres seguro y descarta los vacíos, de modo que un valor no puede salir de la carpeta de plantillas mientras que subcarpetas como any/my_posts siguen funcionando.

save_post() elimina del array enviado toda clave sin el prefijo medafi_ antes de guardarlo y vuelve a comprobar el prefijo antes de cada llamada a update_post_meta(), de modo que el formulario no puede establecer _edit_lock, _price ni claves similares. Guardar valores requiere current_user_can('edit_post').

Vaciar la caché requiere manage_options y mdtf_ajax_nonce. Renombrar claves requiere su propio nonce, edit_post y edit_others_posts. Las acciones sobre los campos de widgets requieren edit_theme_options. Los visitantes sin sesión solo llegan a las acciones de búsqueda del front end (hijos de términos, codificación de búsqueda, recuento, panel de búsqueda, contenido del botón de búsqueda). Los demás manejadores registrados para ellos comprueban el acceso por sí mismos: las acciones de suscripción del messenger requieren inicio de sesión y un nonce, y el ayudante de estadísticas requiere manage_options.