Assets By Partial

La maquetación pública del child se apoya en partials concretas y cada una consume un bloque distinto de CSS o JS.

Archivos clave:

Header parcial

templates/partials/header.php depende sobre todo de:

Responsabilidades:

header.css define shell, buscador, icon buttons, mega y estados visuales
header.js controla hover desktop, overlay, escape, drawer mobile y acordeones móviles
theme.js añade efectos transversales como wipe, top banner y convivencia con el footer

No se estiliza a mano dentro del header. El parent autoencola assets/css/menu-primary.css si la location primary tiene menú asignado.

Ese CSS trabaja sobre hooks genéricos que inyecta el módulo de menús:

Conclusión:

El comportamiento vive en header.js, pero la piel estructural de la location móvil sale de assets/css/menu-mobile.css si esa location está asignada.

Cada location puede disparar su propio CSS si existe el archivo correspondiente:

Eso permite que un mismo walker y una misma API de menús del core produzcan skins distintas por zona.

No tiene un archivo footer.js específico. Su movimiento real sale de theme.js por initFooterParallax() y del CSS global compilado en theme.css.

Por eso el footer mezcla:

Los acordeones FAQ no viven en un js de sección aislado. Los inicializa theme.js mediante initFaqAccordions().

Si una partial reutiliza el mismo patrón de data attributes, hereda el runtime sin crear otro bundle.

Cuando el markup de contacto usa la estructura CF7 prevista, assets/css/cf7-contacto.css le aplica la piel completa del formulario.

Esa hoja no va asociada a una partial por nombre, sino a la presencia de una pantalla de contacto detectada por el core.

si una partial es de navegación, piensa primero en header.css, header.js o menu-{location}.css
si una partial solo necesita utilidades visuales, probablemente ya cae dentro de theme.css
si una partial repite una interacción transversal, revisa theme.js antes de abrir un js nuevo