Todo lo que querrías saber antes de instalar.
Una mirada detallada a cómo funciona DataFirefly Fix Dropzone CORS — Correctivo tainted canvas multi-tienda PrestaShop 8, por qué lo construimos así y la lógica detrás de las características anteriores.
El bug, en términos claros
Está en PrestaShop 8 multi-tienda, con varios dominios diferentes — por ejemplo tienda-fr.com para Francia y tienda-en.com para Inglaterra, cada uno con su propio certificado HTTPS. Abre el back office desde tienda-fr.com y hace clic en un producto asociado a la tienda inglesa. Las imágenes de este producto se sirven desde tienda-en.com, porque ese es el dominio canónico de esa tienda. Para el navegador, es un recurso cross-origin — y como las imágenes nativas de PrestaShop no envían los headers CORS adecuados (Access-Control-Allow-Origin), el canvas que debe generar la vista previa de Dropzone termina «tainted». En la siguiente llamada a ctx.getImageData, el navegador lanza una SecurityError, el editor Dropzone se rompe y el formulario de producto queda inutilizable para la zona de imágenes.
Por qué este bug es real e importante
Muchas tiendas multi-dominio han convivido durante mucho tiempo con este bug evitando editar en cross-dominio (conectándose siempre al «dominio correcto» para cada producto). Pero en una organización de equipo real — catálogo gestionado por una sola persona, varias sub-tiendas internacionales — es insostenible. PrestaShop tiene un fix oficial sobre Dropzone.vue en algunas versiones del nuevo editor Symfony, pero el bug persiste en el editor antiguo AdminProducts y no siempre se retroporta a las versiones estables. Nuestro módulo resuelve el problema en ambos editores a la vez.
Cómo funciona el fix técnicamente
Al cargar una página de producto en el back office, el módulo inyecta un archivo JS de 70 líneas en la cabecera mediante el hook displayBackOfficeHeader. El script espera a que window.Dropzone esté definido y luego sustituye Dropzone.prototype.displayExistingFile por una versión interceptada. Esta versión examina la URL recibida: si es cross-origin, parsea la URL con new URL(url), fuerza u.protocol y u.host a los de window.location.origin, recompone la URL y la pasa al método original. Resultado en el lado del navegador: Dropzone recibe una URL same-origin, el canvas permanece «limpio», getImageData funciona, el archivo de imagen existente se muestra normalmente en el drag & drop. El patch es idempotente (un flag __dfCorsPatched evita la doble aplicación) y fail-safe (las URLs inválidas vuelven al comportamiento original).
Por qué no un patch del núcleo o un override
Un override de PrestaShop sobre el controlador de producto sería frágil: se rompería en cada actualización mayor, y el código Dropzone no está en el controlador PHP. Una modificación directa del archivo JS de Dropzone se sobreescribiría en cada actualización. El monkey-patch del lado cliente, en cambio, es totalmente no invasivo: ningún archivo de PrestaShop se modifica, ningún core override se coloca, el patch se aplica en tiempo de ejecución desde fuera. Si PrestaShop actualiza Dropzone o su integración, el patch sigue siendo funcional mientras la firma de displayExistingFile no cambie (lo cual es extremadamente estable desde Dropzone 5.x). Si el método cambia o PrestaShop lo corrige nativamente, puede desinstalar el módulo sin trazas residuales.
Casos de uso
Tienda multi-país con un dominio por mercado (tienda-fr.com / tienda-en.com / tienda-es.com) gestionada por un equipo centralizado: el bug bloquea la edición de producto en cross-dominio, el módulo lo resuelve inmediatamente. Marketplace o red de marcas en modo multi-tienda multi-dominio: misma configuración, misma solución. Equipo de agencia que gestiona varias sub-tiendas de cliente en dominios distintos: el módulo hace que el back office sea utilizable normalmente sin tener que ir saltando de dominio en dominio. Migración de mono-tienda a multi-dominio: instalado preventivamente, el módulo evita la mala sorpresa post-migración.
Valoraciones
No hay valoraciones aún.