Cómo desactivar el CSS/JS de un módulo sin desinstalarlo

El problema: necesitas el módulo, pero no sus recursos en todas las páginas

Hay muchas situaciones en las que quieres mantener un módulo de PrestaShop instalado y activo pero evitar que cargue sus archivos CSS o JavaScript en páginas específicas, o incluso en todas las páginas. Quizás tienes un módulo cuya funcionalidad necesitas pero cuyo estilo entra en conflicto con tu tema. Quizás un módulo carga una biblioteca JavaScript pesada que ya has incluido a través de tu tema. Quizás quieres reemplazar los estilos predeterminados de un módulo con tu propio CSS personalizado sin que los estilos originales interfieran. O quizás has identificado mediante una auditoría de rendimiento que un módulo carga recursos en páginas donde no tiene salida visible, y quieres eliminar ese desperdicio.

Desinstalar el módulo no es una opción porque necesitas su funcionalidad principal: sus hooks, sus tablas de base de datos, su configuración, sus funciones del back office. Solo necesitas eliminar quirúrgicamente archivos CSS o JavaScript específicos de la salida del front office. PrestaShop proporciona varios mecanismos para lograr esto, y este artículo cubre todos ellos en detalle, desde el más sencillo hasta el más potente.

Método 1: Usar Theme.yml para eliminar recursos de módulos

La forma más sencilla y mantenible de eliminar el CSS o JavaScript de un módulo en PrestaShop 1.7 y posteriores es a través del archivo de configuración del tema, theme.yml. Este archivo, ubicado en la raíz del directorio de tu tema, controla qué recursos carga el tema y qué recursos de módulos elimina.

Abre tu archivo theme.yml y busca la sección assets. Si no existe, puedes crearla. Dentro de la sección assets, puedes especificar archivos CSS y JavaScript a eliminar por su ID de recurso. Cada recurso registrado a través de registerStylesheet o registerJavascript tiene un ID, que típicamente es el nombre del módulo seguido de un sufijo descriptivo.

Para encontrar los IDs de recurso utilizados por un módulo, inspecciona el código fuente de tu página y busca las etiquetas link de hojas de estilo y los elementos de scripts. PrestaShop añade un atributo id a estos elementos en modo de depuración, o puedes encontrar los IDs en el código fuente del módulo donde llama a registerStylesheet o registerJavascript.

En tu archivo theme.yml, añade una sección bajo assets, luego css, luego all. Añade una entrada con el ID del recurso y establécelo en false. Por ejemplo, si un módulo registra una hoja de estilos con el ID modulename-style, añadirías modulename-style con un valor de false bajo la sección css all. Haz lo mismo para los archivos JavaScript bajo la sección js all.

Después de modificar theme.yml, necesitas limpiar la caché de PrestaShop desde Parámetros Avanzados, Rendimiento. Los cambios de theme.yml surten efecto después de que se reconstruya la caché. Este enfoque persiste a través de las actualizaciones del módulo porque la eliminación está definida en tu tema, no en el propio módulo. Sin embargo, elimina los recursos de todas las páginas. Si necesitas los recursos en algunas páginas pero no en otras, necesitarás un enfoque más selectivo.

Método 2: Media::unregisterStylesheet y Media::unregisterJavascript

PrestaShop 1.7 introdujo los métodos de la clase Media unregisterStylesheet y unregisterJavascript, que te permiten eliminar programáticamente recursos específicos que fueron registrados por otros módulos. Estos métodos son potentes porque puedes llamarlos condicionalmente, eliminando recursos solo en páginas específicas mientras los mantienes en otras.

Para usar este enfoque, necesitas un módulo personalizado o una modificación a un módulo existente. En el método hookActionFrontControllerSetMedia de tu módulo, llama a Media::unregisterStylesheet con el ID del recurso del archivo CSS que quieres eliminar. De la misma forma, llama a Media::unregisterJavascript con el ID del recurso del archivo JavaScript. Puedes envolver estas llamadas en lógica condicional para eliminar recursos solo en tipos de página específicos.

Por ejemplo, si quieres eliminar los recursos de un módulo de slider de todas las páginas excepto la de inicio, verificarías si el controlador actual es IndexController. Si no es la página de inicio, llamas a los métodos de eliminación del registro. Si es la página de inicio, no haces nada y dejas que los recursos se carguen normalmente.

La consideración clave con este enfoque es el orden de ejecución de los hooks. El hookActionFrontControllerSetMedia de tu módulo debe ejecutarse después del módulo cuyos recursos quieres eliminar. PrestaShop ejecuta las llamadas de hook en el orden en que los módulos están registrados en el hook, lo cual puedes controlar a través de la página Diseño, Posiciones en el back office. Mueve tu módulo personalizado debajo del módulo objetivo en el hook actionFrontControllerSetMedia para asegurar que tus llamadas de eliminación del registro ocurran después de que el módulo objetivo registre sus recursos.

Si el módulo infractor usa los métodos antiguos addCSS y addJS en lugar de registerStylesheet y registerJavascript, los métodos de eliminación del registro podrían no funcionar porque los métodos antiguos no usan el mismo sistema de gestión de recursos. En ese caso, necesitas un enfoque diferente.

Método 3: Módulo personalizado para bloquear recursos específicos

Cuando necesitas un control detallado sobre qué recursos se cargan en qué páginas, crear un módulo dedicado de gestión de recursos es la solución más flexible. Este módulo actúa como un lugar central donde defines reglas para bloquear o permitir recursos específicos de módulos.

Crea un nuevo módulo con un método hookActionFrontControllerSetMedia. Dentro de este método, define un array de reglas de recursos. Cada regla especifica un nombre de módulo, los IDs de recursos a bloquear y las condiciones bajo las cuales bloquearlos. Las condiciones pueden basarse en el nombre del controlador, el tipo de página o cualquier otro criterio disponible en el contexto de PrestaShop.

Tu módulo itera a través de las reglas en cada carga de página, verifica las condiciones y llama a Media::unregisterStylesheet o Media::unregisterJavascript para cada recurso que deba bloquearse en la página actual. Este enfoque centralizado es mucho más fácil de mantener que dispersar la lógica de eliminación de recursos en múltiples módulos o archivos de tema.

Puedes mejorar este módulo con una página de configuración en el back office que te permita gestionar las reglas a través de la interfaz de administración de PrestaShop en lugar de editar código. Un formulario simple con campos para el nombre del módulo, el ID del recurso y un multiselect para los tipos de página donde el recurso debería bloquearse te da una forma amigable de gestionar la carga de recursos sin tocar ningún código después de la configuración inicial.

Este enfoque funciona tanto con el nuevo sistema registerStylesheet como con el antiguo sistema addCSS, aunque podrías necesitar usar técnicas diferentes para cada uno. Para recursos registrados con el nuevo sistema, usa los métodos Media::unregister. Para recursos añadidos con el sistema antiguo, puedes manipular directamente los arrays css_files y js_files del controlador en el método hookActionFrontControllerSetMedia.

Método 4: El enfoque de desvincular hooks

Un enfoque más agresivo pero a veces necesario es desvincular completamente un módulo de los hooks donde registra sus recursos. Ve a Diseño y luego a Posiciones en tu back office. Encuentra el módulo en el hook displayHeader o actionFrontControllerSetMedia. Haz clic en el botón de eliminar o desvincular para quitar el módulo de ese hook por completo.

Esto evita que el módulo cargue cualquier recurso en cualquier página. Los otros hooks del módulo, como displayProductAdditionalInfo o displayFooter, continúan funcionando normalmente. Sin embargo, la salida del front office del módulo puede romperse si depende de su CSS para el estilo o de su JavaScript para el comportamiento interactivo.

Este enfoque es más útil cuando planeas reemplazar completamente el estilo del módulo con tu propio CSS personalizado. Desvinculas el módulo de displayHeader para evitar que se cargue su CSS, y luego escribes tus propios estilos en el archivo CSS personalizado de tu tema apuntando a los elementos HTML del módulo. Esto te da control total sobre la apariencia del módulo sin ningún conflicto entre los estilos originales y tus personalizaciones.

Para JavaScript, desvincular es más arriesgado. Si el módulo depende de su JavaScript para funcionalidades principales como llamadas AJAX, validación de formularios o carga dinámica de contenido, eliminar el JavaScript romperá esas funcionalidades. Solo desvincula el JavaScript si estás seguro de que la salida del front office del módulo no depende de él, o si estás proporcionando una implementación de reemplazo a través de tu tema.

Una advertencia importante: si actualizas el módulo, el proceso de actualización puede volver a registrar el módulo en los hooks de los que lo eliminaste. Después de cada actualización de módulo, comprueba Diseño, Posiciones para verificar que tu desvinculación sigue en efecto. Algunos módulos registran explícitamente sus hooks durante el proceso de actualización, lo cual anula tu desvinculación manual.

Método 5: Anular los recursos del módulo a través de tu tema

El sistema de temas de PrestaShop te permite anular los archivos de plantilla de un módulo colocándolos en el directorio modules de tu tema. Aunque esto se usa principalmente para anular plantillas, también puedes usarlo para controlar la carga de recursos indirectamente.

Si un módulo carga sus recursos a través de sus archivos de plantilla usando funciones Smarty como etiquetas de archivos directamente en los archivos TPL en lugar de mediante hooks PHP, puedes anular esas plantillas en tu tema y eliminar las referencias a los recursos. Copia el archivo de plantilla del módulo al directorio modules de tu tema, manteniendo la misma estructura de directorios, y edita la copia para eliminar las referencias a CSS o JavaScript no deseadas.

Este enfoque es específico del tema, lo que significa que solo afecta al tema actual. Si cambias de tema, las anulaciones no se transfieren. También requiere mantenimiento: cuando el módulo actualiza sus plantillas, necesitas actualizar tus anulaciones para reflejar cualquier cambio estructural mientras mantienes tus modificaciones de eliminación de recursos.

Para módulos que cargan recursos a través de hooks PHP en lugar de plantillas, las anulaciones de plantillas del tema no ayudan con el bloqueo de recursos. En ese caso, usa uno de los otros métodos descritos en este artículo.

PrestaShop 1.7 vs 8.x: diferencias en el enfoque

PrestaShop 8.x perfeccionó el sistema de gestión de recursos introducido en 1.7, pero los enfoques fundamentales siguen siendo los mismos. Las principales diferencias están en la implementación interna y algunas funcionalidades adicionales.

En PrestaShop 1.7, el sistema de gestión de recursos usa registerStylesheet y registerJavascript con un sistema de prioridad. Los métodos Media::unregisterStylesheet y Media::unregisterJavascript funcionan de forma fiable para recursos registrados a través de este sistema. Sin embargo, los módulos que aún usan los métodos heredados addCSS y addJS (que están obsoletos pero siguen siendo funcionales) no pasan por el nuevo sistema de gestión de recursos, lo que hace más difícil eliminarlos limpiamente.

PrestaShop 8.x mejoró la compatibilidad hacia atrás para que incluso los recursos añadidos a través de los métodos heredados se procesen a través del nuevo pipeline de recursos. Esto significa que los métodos Media::unregister funcionan de forma más consistente en todos los módulos, independientemente de qué método de registro utilicen. Si estás ejecutando PrestaShop 8.x, el enfoque de eliminación del registro es el método más fiable para todos los módulos.

PrestaShop 8.x también introdujo mejor invalidación de caché para los recursos, lo que significa que cuando eliminas o modificas recursos, los cambios surten efecto inmediatamente después de limpiar la caché, sin que los clientes vean versiones almacenadas en caché obsoletas. En PrestaShop 1.7, a veces necesitabas limpiar tanto la caché de PrestaShop como la caché del navegador, o esperar a que el sistema Combinar, Comprimir, Cachear (CCC) regenerara los archivos combinados.

Ambas versiones soportan el enfoque theme.yml para la eliminación de recursos, y la sintaxis es idéntica. Si estás escribiendo un módulo personalizado para la gestión de recursos, el mismo código funciona tanto en 1.7 como en 8.x con diferencias mínimas.

Midiendo las mejoras de rendimiento después de desactivar recursos

Después de desactivar los recursos de un módulo, deberías medir la mejora de rendimiento para confirmar que tus cambios tuvieron el efecto esperado. Usa una combinación de herramientas para una medición completa.

Comienza con la pestaña Red de Chrome DevTools. Compara el número total de peticiones y el tamaño total transferido antes y después de tus cambios. Filtra por CSS y JS para ver la reducción específica en el número y tamaño de archivos de hojas de estilo y JavaScript. Una optimización significativa debería mostrar una reducción clara tanto en el número de peticiones como en el tamaño total.

Ejecuta una auditoría de rendimiento de Lighthouse antes y después. Céntrate en las métricas más afectadas por la carga de CSS y JavaScript: First Contentful Paint se ve afectado por el CSS que bloquea el renderizado, Largest Contentful Paint se ve afectado por la carga general de recursos, y Total Blocking Time se ve afectado por el análisis y ejecución de JavaScript. Registra estas métricas de al menos tres ejecuciones y compara los promedios.

Usa la pestaña Coverage en Chrome DevTools para medir el uso de CSS y JavaScript. Abre la pestaña Coverage desde el menú de tres puntos en Más herramientas, luego recarga la página. La pestaña Coverage te muestra cuánto de cada archivo CSS y JavaScript se utiliza realmente en la página actual. Los archivos con alto porcentaje de código no utilizado (mostrados en rojo) son candidatos para eliminación o carga condicional. Después de desactivar los recursos del módulo, los archivos restantes deberían mostrar porcentajes de uso más altos, indicando que has eliminado el desperdicio con éxito.

También considera las métricas del mundo real de tu plataforma de analítica. Si usas Google Analytics o una herramienta similar, compara los tiempos de carga de página durante una semana antes y después de tu optimización. Los datos del mundo real de visitantes reales en diferentes dispositivos y condiciones de red te dan la imagen más precisa de la mejora de rendimiento.

Riesgos y consideraciones de compatibilidad

Desactivar los recursos de un módulo conlleva riesgos que necesitas entender y gestionar. El riesgo más común es la rotura visual. Cuando eliminas el CSS de un módulo, sus elementos HTML pierden su estilo y pueden mostrarse incorrectamente. Esto puede ir desde problemas cosméticos menores como colores o espaciados incorrectos hasta problemas de diseño graves como elementos superpuestos o contenido invisible.

La eliminación de JavaScript conlleva un riesgo mayor. Los módulos modernos a menudo dependen de su JavaScript para funcionalidades principales. Eliminar el JavaScript puede hacer que las funcionalidades dejen de funcionar por completo: botones que no responden a los clics, formularios que no se envían, popups que no se abren, contenido AJAX que no se carga. Siempre prueba cada funcionalidad de un módulo después de eliminar su JavaScript.

También existe un riesgo de compatibilidad con las actualizaciones de módulos. Cuando un módulo se actualiza, el desarrollador puede añadir nuevos archivos CSS o JavaScript con diferentes IDs de recurso. Tus reglas de eliminación, ya sea en theme.yml o en un módulo personalizado, podrían no capturar los nuevos recursos porque apuntan a los IDs antiguos. Después de cada actualización de módulo, verifica que tu bloqueo de recursos sigue funcionando correctamente y actualiza tus reglas si es necesario.

Algunos módulos realizan detección de funcionalidades en su JavaScript y se comportan de forma diferente cuando su CSS no está cargado. Un módulo podría verificar la existencia de clases CSS específicas o estilos computados antes de inicializar su funcionalidad JavaScript. Eliminar el CSS en este caso no solo cambia la apariencia sino que también rompe el comportamiento del JavaScript que depende de esos estados definidos por CSS.

Finalmente, ten en cuenta las dependencias entre módulos. El Módulo A podría cargar una biblioteca JavaScript como un plugin de lightbox que el Módulo B también usa pero no carga por sí mismo porque asume que el Módulo A lo proporciona. Eliminar los archivos JavaScript del Módulo A rompería ambos módulos en este escenario. Verifica las dependencias compartidas antes de eliminar cualquier recurso.

Un flujo de trabajo práctico para la eliminación segura de recursos

Sigue este flujo de trabajo para desactivar de forma segura los recursos de un módulo sin romper tu tienda. Primero, documenta tu estado actual. Toma capturas de pantalla de cada tipo de página donde el módulo muestra contenido. Registra las puntuaciones de Lighthouse y las estadísticas de la pestaña Red. Esto te da una referencia para comparar y una guía de cómo debería verse y funcionar el módulo.

Segundo, identifica los recursos específicos que quieres eliminar. Usa DevTools para encontrar los nombres exactos de archivos y los IDs de recursos. Determina qué páginas necesitan los recursos y cuáles no.

Tercero, implementa la eliminación usando el método más apropiado de este artículo. Para eliminación global simple, usa theme.yml. Para eliminación condicional basada en tipo de página, crea un módulo personalizado con llamadas a Media::unregister. Para reemplazo completo de recursos, desvincula el módulo y proporciona tus propios estilos.

Cuarto, prueba exhaustivamente. Comprueba cada tipo de página donde el módulo debería mostrar contenido. Verifica que la apariencia visual del módulo es correcta y que todas las funcionalidades interactivas funcionan. Comprueba las páginas donde eliminaste los recursos para confirmar que ya no se están cargando. Prueba en múltiples navegadores y dispositivos.

Quinto, mide la mejora de rendimiento. Ejecuta auditorías de Lighthouse y compara con tu referencia. Comprueba la pestaña Red para verificar la reducción en el número de peticiones y tamaños. Si la mejora es significativa, tu optimización fue exitosa. Si la mejora es mínima, los recursos que eliminaste podrían no haber sido el principal cuello de botella de rendimiento, y deberías investigar otras oportunidades de optimización.

Sexto, documenta tus cambios. Registra qué recursos eliminaste, qué método usaste y qué páginas están afectadas. Esta documentación es esencial para resolver problemas futuros, especialmente después de actualizaciones de módulos, y para la transferencia de conocimiento si otra persona mantiene la tienda.

Siguiendo este enfoque sistemático, puedes reducir de forma segura el peso de página de tu tienda y mejorar los tiempos de carga sin sacrificar la funcionalidad del módulo de la que depende tu tienda. La clave es siempre probar y medir: nunca asumas que eliminar un recurso es seguro, y siempre verifica los resultados con datos concretos.