Conflictos de CSS/JS en admin de Conorderfee

miguelhub

¡Hola a todos!

Estamos teniendo un dolor de cabeza con el módulo Conorderfee en nuestro PrestaShop 1.7.7.2 (corriendo con PHP 7.2). Notamos problemas de estilo intermitentes con admin_conorderfee.css o errores de JavaScript que vienen de adminConditionBuilder.js dentro de la interfaz de administración del módulo.

Parece que los recursos cargados vía addCSS y addJS en el método run() de ConorderfeeAdmin.php no siempre se cargan en el momento esperado, y esto provoca conflictos visuales o de funcionalidad con otros módulos del administrador. A veces, la página se ve bien; otras, los elementos están descolocados o algún script no funciona.

Aquí tenéis un fragmento del código en cuestión de conorderfee/classes/ConorderfeeAdmin.php:

function run()
    {
        if (isset($this->context->controller) && method_exists($this->context->controller, 'addCSS')) {
            $this->context->controller->addCSS($this->module->getPathUri() . 'views/css/admin_conorderfee.css');

¿Alguien ha experimentado algo similar con este módulo o con la forma en que PrestaShop 1.7 gestiona la carga de assets en el back office para módulos de terceros? ¿Hay alguna forma de asegurar que estos archivos se carguen correctamente sin entrar en conflicto?

alba_auto

Qué tal, @miguelhub.

Esa es una situación clásica en PrestaShop 1.7, especialmente con módulos que no usan un AdminController propio o que intentan cargar assets desde métodos que no son setMedia(). El addCSS y addJS son correctos, pero la clave está en el momento y el contexto en que se llama run().

Si el método run() de ConorderfeeAdmin se ejecuta en todas las páginas del back office (o en muchas), no solo en las del propio módulo, podría estar inyectando CSS/JS que no son necesarios y que, efectivamente, chocan con los de otros módulos. ¿Has revisado si el run() se ejecuta condicionalmente, es decir, solo cuando estás en la configuración de Conorderfee?

silvia94

Yo tuve un problema parecido con otro módulo de pedidos en PS 1.7.8 (que es muy similar al 1.7.7.2 en la gestión de assets de BO). Al final, el desarrollador del módulo tuvo que mover la lógica de addCSS y addJS al método setMedia() de su AdminController personalizado. Si ConorderfeeAdmin no es un controlador en sí, sino una clase auxiliar, es posible que el context->controller no sea siempre el AdminController principal que está renderizando la página, o que otro módulo esté sobrescribiendo la lista de assets.

Echa un vistazo a la consola del navegador cuando tengas el problema. ¿Hay errores de JS? ¿Los archivos CSS y JS del módulo aparecen en la pestaña 'Network' y se cargan sin errores 404?

Milo

Hola @miguelhub, @alba_auto y @silvia94. Entiendo perfectamente vuestra frustración con este tipo de problemas de carga intermitente.

El problema que describes es común cuando se cargan assets de forma global o en un contexto donde no son estrictamente necesarios, lo que puede llevar a conflictos con otros scripts o estilos ya cargados por el PrestaShop core o por otros módulos. En el fragmento que nos muestras, la carga de CSS y JS ocurre en el método run() y se activa simplemente si el controlador de contexto existe y tiene el método addCSS. Esto es demasiado amplio.

La clave está en asegurar que estos assets solo se inyecten cuando el usuario esté activamente en la interfaz de configuración de vuestro módulo Conorderfee. El mismo fragmento de código que has compartido ya contiene una pista con $activeTab = Tools::getValue('conorderfee_tab', 'dashboard');.

La solución más limpia y robusta para PrestaShop 1.7.x es condicionar la carga de esos assets a que el activeTab corresponda a las pestañas principales de vuestro módulo. Así evitamos inyectarlos en otras páginas del back office donde podrían generar conflictos.

Aquí te dejo una adaptación del fragmento que debería resolver el problema. Asegúrate de incluir todos los nombres de las pestañas principales de tu módulo en el array, no solo 'dashboard' o 'policies', si tiene más:

function run()
    {
        $activeTab = Tools::getValue('conorderfee_tab', 'dashboard');
        if (isset($this->context->controller) && method_exists($this->context->controller, 'addCSS')
            && in_array($activeTab, ['dashboard', 'policies', 'otros_tabs_aqui'])) { // Ajusta los tabs de tu módulo
            $this->context->controller->addCSS($this->module->getPathUri() . 'views/css/admin_conorderfee.css');
            $this->context->controller->addJS($this->module->getPathUri() . 'views/js/adminConditionBuilder.js');
        }

Este cambio asegura que los assets se carguen solo cuando el usuario está en una de las pestañas activas del módulo Conorderfee, reduciendo drásticamente las posibilidades de conflicto. Aunque los hacks directos en el código pueden funcionar, para una solución más profesional y mantenible a largo plazo, siempre recomiendo optar por módulos diseñados para añadir recargos de manipulación o servicio condicionales, ya que están optimizados para evitar este tipo de incompatibilidades.

Espero que esto os sirva de ayuda.

miguelhub

¡Increíble, @Milo! ¡Muchas gracias!

He aplicado tu sugerencia de envolver los addCSS y addJS en la condición in_array($activeTab, [...]) y he puesto todos los nombres de las pestañas de nuestro módulo. Después de unos días de pruebas intensivas, los conflictos de estilo y los errores de JavaScript han desaparecido por completo.

Ahora la interfaz de administración del módulo se ve consistente y no interfiere con el resto del back office. Es un cambio pequeño pero con un impacto enorme. ¡Muchas gracias por la explicación tan clara y por la solución tan efectiva!