/* ============================================================ NA — Reposiciones del header sobre el tema VamTam PetMania CMP · Agosto 2026 ============================================================ RETIRADO EN LA SESION 16 — no volver a ponerlo sin releer esto. Este fichero contenia dos reglas escritas en la sesion 15 bajo una premisa que resulto FALSA: que la familia `theme-icons` no llegaria a servirse nunca en este sitio. Eran: 1. forzar `display:block` en `svg.dgwt-wcas-ico-magnifier`, para reponer la lupa del plugin que el tema oculta a proposito, y 2. `content: none` en `.dgwt-wcas-sf-wrapp::before`, para tapar el «cuadrito vacio» que salia a su izquierda. El propio comentario de la sesion 15 ya avisaba: «si algun dia el tema vuelve a servir theme-icons, hay que decidir cual de las dos lupas se queda y retirar una de estas dos reglas». LO QUE PASO DE VERDAD. El cuadrito no era un fondo ni un borde de otro elemento: era el propio glifo del tema pintado como `.notdef` (tofu) porque la fuente no existia en dev. La fuente no la declara el tema, sino un set de iconos de Elementor Pro que en dev no estaba instalado. Instalado el set y servida la fuente desde `na-core` (ver `assets/css/na-theme-icons.css`), el glifo pinta la lupa real. MEDIDO tras el arreglo: el ancho del glifo `\e90b` a 100 px paso de 77,8 px (el `.notdef` de la fuente por defecto) a **100 px**, exactamente el valor del demo. Por eso las dos reglas se RETIRAN: con la fuente puesta reponer ademas el SVG del plugin daria DOS lupas. El demo hace justo lo contrario — medido en testing: `.dgwt-wcas-ico-magnifier` en `display:none` y el `::before` del tema visible. Se deja que el tema se comporte como fue disenado. ============================================================ */ /* ------------------------------------------------------------ El rectangulo blanco detras de la barra de busqueda ------------------------------------------------------------ Lo pedia el usuario: «un fondo blanco detras siempre en formato rectangular que desencaja con el color de fondo de varias paginas». ORIGEN, localizado en el CSS del plugin (no en el tema): ajax-search-for-woocommerce/assets/css/style.css:1857 .dgwt-wcas-style-pirx .dgwt-wcas-sf-wrapp { background:#fff; padding:10px; border-radius:10px } Es parte del estilo «pirx» de FiboSearch, que da por hecho un fondo de pagina blanco. MEDIDO en dev a 1440 px: la caja son 266 x 72 px con radio 10 px, mientras la pildora que SI debe verse es el `input`, que ya trae su propio borde `1px solid #E6E6E6` y radio 30 px. O sea: el rectangulo es puro estorbo, quitarlo no deja el buscador sin forma. POR QUE NO SE CAMBIA EL ESTILO A «solaris», que es el que usa el demo: `search_style` vale `pirx` TAMBIEN EN PRODUCCION, asi que es la eleccion propia del sitio y no un defecto de la migracion. Cambiarla alteraria el buscador entero, que no es lo que se pidio. Solo se anula el fondo. El `padding` se conserva: es lo que da a la caja sus 72 px de alto y quitarlo descuadraria el header. Se gana por especificidad (0,3,0 contra 0,2,0) para no depender del orden de carga, porque el minify de WP-Optimize reordena los ficheros. ------------------------------------------------------------ */ .dgwt-wcas-search-wrapp.dgwt-wcas-style-pirx .dgwt-wcas-sf-wrapp { background: transparent; } /* ------------------------------------------------------------ La lupa, descolocada en la esquina superior izquierda (escritorio) ------------------------------------------------------------ Este defecto solo se pudo ver a partir de la sesion 16: hasta entonces el glifo no se dibujaba (salia como cuadrito tofu porque faltaba la fuente `theme-icons`), asi que su POSICION nunca habia podido juzgarse. ORIGEN, en el CSS del tema: elementor-all.css:6460 @media (min-width: 768px) ... .dgwt-wcas-sf-wrapp::before { position:absolute; top:2px; left:2px; font-size:36px; content:"\e90b" } Esa regla esta escrita para el buscador SIN boton de envio (`.dgwt-wcas-no-submit`), donde el wrapper no tiene relleno y el input arranca justo en su esquina: por eso `top:2px; left:2px` cae dentro del campo. El nuestro es `.dgwt-wcas-has-submit`, y el estilo «pirx» del plugin le pone `padding:10px` al wrapper. MEDIDO a 1440 px: el wrapper mide 72 px de alto y el input queda en 10..62, con su centro vertical en 36; el glifo ocupa 2..38, centro en 20. Le sobran 16 px por arriba, y por eso asoma fuera de la pildora. Se centra por porcentaje en vez de con un `top` fijo para no depender de que el wrapper siga midiendo 72 px. El `left:16px` deja el icono dentro del relleno izquierdo del input (que en pirx es de 48 px), sin pisar el texto. ATENCION A LA ESPECIFICIDAD. El primer intento uso tres clases sobre el wrapper mas `.dgwt-wcas-sf-wrapp`, o sea (0,4,0): EMPATE con el selector del tema, que gana por orden de aparicion. El sintoma fue enganoso porque el empate es POR PROPIEDAD: `transform` (que el tema no declara) si se aplico y `top`/`left` no, asi que el glifo se desplazo 18 px HACIA ARRIBA y quedo peor que antes. Por eso el selector lleva ademas la clase del widget de Elementor: (0,5,0), que si gana. Solo escritorio y solo con boton de envio: por debajo de 768 px la regla del tema no aplica y ahi se ve el SVG del plugin, que ya esta bien colocado. ------------------------------------------------------------ */ @media (min-width: 768px) { .elementor-widget-wp-widget-dgwt_wcas_ajax_search .dgwt-wcas-search-wrapp.dgwt-wcas-has-submit.dgwt-wcas-style-pirx .dgwt-wcas-sf-wrapp::before { top: 50%; left: 16px; transform: translateY(-50%); } } /* ------------------------------------------------------------ Al escribir, las letras se metian DEBAJO de la lupa ------------------------------------------------------------ Reportado el 2-sep-2026: «cuando se escribe en la barra de busqueda, las letras empiezan a escribirse sobre el icono de busqueda y no a su derecha como mismo esta el placeholder». MEDIDO a 1440 px en la portada. El campo en reposo trae `padding-left: 48px`, que es justo lo que deja el placeholder a la derecha del glifo del tema (el `::before` de arriba: 36 px de ancho, anclado a 16 px del wrapper, o sea que termina en 52 px). Pero en cuanto el campo tiene texto FiboSearch le anade la clase `dgwt-wcas-search-filled` y con ella BAJA el relleno a 24 px (a la vez mueve su boton de envio de la izquierda a la derecha). El glifo del tema no se mueve: es un pseudo-elemento del wrapper, no del boton del plugin. Resultado: el texto arrancaba en 24 px, dentro de los 52 px que ocupa la lupa. El arreglo es mantener el relleno de reposo tambien en el estado «con texto»: 48 px, el mismo valor que ya usa el plugin, para que el texto y el placeholder empiecen exactamente en el mismo sitio. No se toca el `padding-right`, que lo gestiona el propio plugin al mover su boton. ESPECIFICIDAD, sin `!important`: (0,5,1) contra el selector del estado lleno de FiboSearch. Mismo gancho de tres piezas que la regla del glifo de arriba (widget de Elementor + `has-submit` + `style-pirx`), asi que las dos viven o caen juntas. Solo escritorio, por el mismo motivo que la regla anterior: por debajo de 768 px no hay glifo del tema —se ve el SVG del plugin, ya colocado— y ademas la busqueda pasa por su superposicion movil. ------------------------------------------------------------ */ @media (min-width: 768px) { .elementor-widget-wp-widget-dgwt_wcas_ajax_search .dgwt-wcas-search-wrapp.dgwt-wcas-has-submit.dgwt-wcas-style-pirx .dgwt-wcas-sf-wrapp .dgwt-wcas-search-input { padding-left: 48px; } } /* ------------------------------------------------------------ El desplegable del icono de usuario se salia por la derecha ------------------------------------------------------------ MEDIDO en dev a 1440 px antes del arreglo: el panel del popup «My account drop down menu» daba caja x=1317, ancho 160 -> borde derecho en 1477 sobre una ventana de 1440, o sea 37,45 px FUERA. QUIEN MANDA NO ES EL CSS. La posicion la escribe el JS del tema como estilo EN LINEA sobre `.dialog-widget-content`: style="top: 103.797px; left: 1317.45px;" Ya se intento por ajustes del popup y NO BASTO: se apagaron las dos opciones de VamTam (`vamtam_align_with_selector` y `vamtam_abs_pos`) y se puso el posicionamiento nativo (`horizontal_position=end`, `offset_orientation_h=end`, `offset_x=30px`, `margin=0`). El ajuste SI se aplico (la clase `vamtam-abs-pos` desaparecio y el modal paso de `absolute` a `fixed`), pero el inline siguio siendo el mismo byte a byte: el JS lo escribe igual. POR QUE ESTA REGLA LLEVA `!important` — es la EXCEPCION, no la norma. Un estilo en linea gana a cualquier selector por especificidad; lo unico que lo supera es `!important`. Sin el no hay forma de neutralizar ese `left`. Se ancla por la derecha (`right: 30px`, el mismo `offset_x` que ya tiene el popup en sus ajustes) y se suelta el `left`. El `top` NO se toca: el que escribe el JS ya deja el panel justo debajo del icono, y el ancho de 160 px viene del ajuste `width` del popup, que tampoco se toca. ACOTADA A ESE POPUP, jamas a `.elementor-popup-modal` a secas: los popups 53606 («Productos») y 54086 («Marcas») son los mega-menus, ocupan el ancho completo y una regla generica los romperia. EL GANCHO ES ESTABLE: no se usa `#elementor-popup-modal-53584`, porque ese ID es el de dev y en produccion sera otro. Se le puso al popup la clase CSS `na-user-menu-popup` en sus ajustes (Popup > Advanced > CSS Classes, que Elementor Pro vuelca en el elemento del modal). Al desplegar hay que asegurarse de que el popup equivalente de produccion lleva esa misma clase. ------------------------------------------------------------ */ /* ------------------------------------------------------------ 2-sep-2026 — ANCLARLO A LA VENTANA NO BASTABA ------------------------------------------------------------ El `right: 30px` de abajo evita que el panel se salga, pero lo deja pegado al borde derecho de la VENTANA, no debajo del icono que lo abre. Medido a 1440 px: el icono ocupa 1126-1162 y el panel aparecia en 1250 (y con `top: 0`, arriba del todo). El usuario lo describio asi: «cuando se presiona el icono del usuario en el header el desplegable se abre en un lugar totalmente diferente a la derecha de este». La posicion pasa a venir de tres variables que escribe `na-user-menu-popup.js` midiendo el icono en cada apertura. LOS VALORES POR DEFECTO SON EL COMPORTAMIENTO ANTERIOR a proposito: si el script no llega a correr, el panel sigue anclado a 30 px del borde derecho —descolocado, pero dentro de la pantalla— en vez de quedarse sin posicion ninguna. El `!important` sigue siendo imprescindible por el mismo motivo de antes: el JS de Elementor escribe `top` y `left` COMO ESTILO EN LINEA y nada que no sea `!important` le gana. Por eso el script no pelea con estilos en linea propios: solo define las variables que estas tres declaraciones consumen. ------------------------------------------------------------ */ .elementor-popup-modal.na-user-menu-popup .dialog-widget-content { left: var( --na-user-menu-left, auto ) !important; right: var( --na-user-menu-right, 30px ) !important; top: var( --na-user-menu-top, 103px ) !important; } /* ------------------------------------------------------------ El escalon blanco antes de «Cuenta de miembro» ------------------------------------------------------------ La fila «Cuenta de miembro» (S20) se anadio al popup como una SECCION nueva, igual que sus tres hermanas. El clonado copio todos los ajustes de estilo de «Mi perfil», pero la seccion aporta ademas su propio margen superior, que se SUMA al del bloque anterior. MEDIDO en dev: la separacion entre los items 1-3 es de 42 px en escritorio y 71 px en movil, pero antes del cuarto sube a 53 px y 82 px. Son 11 px de mas, los mismos en las dos anchuras, y se leen como un escalon blanco que parte el menu en dos bloques. Se corrige con el mismo numero medido, no con uno «que quede bien». Va acotado al popup del menu de usuario: `.na-solo-miembros` es una clase de proposito general (la puede llevar cualquier elemento de Elementor, ver nutriclub-elementor-solo-miembros.php) y una regla suelta le meteria un margen negativo a cualquier bloque solo-para-miembros del sitio. */ .elementor-popup-modal.na-user-menu-popup .na-solo-miembros { margin-top: -11px; } /* ------------------------------------------------------------------------- * El boton de NutriClub, en la MISMA linea que los iconos de usuario y carrito. * * Peticion del usuario: «el badge de Mi NutriClub que aparece debajo del icono * del usuario y el carrito de compra en el header quisiera que se encontrara a * la derecha de estos iconos, haciendo que todo el header quedara en una sola * linea». * * NO estaba mal colocado en la plantilla: el shortcode `na15b001` ya es el cuarto * hijo de la misma columna (`73c593e7`) que el buscador, el icono de usuario y el * carrito. Lo que pasaba es que NO CABIA y el flex lo mandaba a una segunda fila. * Medido a 1440 px: la columna mide 510 px y sus cuatro piezas suman 581 * (buscador 290 + usuario 56 + carrito 56 + boton 179). * * Se resuelve liberando esos 71 px en el unico sitio donde sobran: el buscador, * que a 290 px es mas ancho de lo que necesita. A 210 px la suma baja a 501 y * entra en una sola linea, con el campo todavia comodo para escribir. * * Solo de 1025 px hacia arriba: por debajo manda la cabecera movil (seccion * `74d751f7`), que tiene su propia barra de NutriClub (`na15s001`) y no comparte * esta geometria. * ---------------------------------------------------------------------- */ @media ( min-width: 1025px ) { .elementor-element-73c593e7 > .elementor-widget-wrap { flex-wrap: nowrap !important; align-items: center !important; justify-content: flex-end !important; } /* Los 71 px que faltaban salen de aqui. */ .elementor-element-73c593e7 .elementor-element-56642e79 { width: 210px !important; max-width: 210px !important; flex: 0 0 210px !important; } /* Que el boton ocupe lo justo y no lo encoja el flex. */ .elementor-element-73c593e7 .elementor-element-na15b001 { width: auto !important; flex: 0 0 auto !important; margin-left: 12px !important; } .elementor-element-73c593e7 .elementor-element-3fa00d54, .elementor-element-73c593e7 .elementor-element-2d443097 { flex: 0 0 auto !important; } }