PrestaShop Administration & Productivité

DataFirefly Fix Dropzone CORS — Correctif tainted canvas multishop PrestaShop 8

Le correctif définitif pour le bug « tainted canvas » sur l'éditeur produit en multishop multi-domaines.

Si vous êtes sur PrestaShop 8 en multishop avec plusieurs domaines différents (boutique-fr.com, boutique-en.com, etc.), vous avez probablement déjà vu cette erreur dans la console navigateur en éditant une fiche produit : SecurityError: tainted canvas. Le formulaire image se brise, l'aperçu Dropzone ne s'affiche plus, et vous êtes bloqué. C'est un bug connu de PrestaShop : les images sont servies depuis un autre domaine, le canvas devient cross-origin, et getImageData explose. DataFirefly Fix Dropzone CORS résoud le problème en monkey-patchant Dropzone côté client : les URLs des images existantes sont réécrites vers le domaine du back-office avant chargement, le canvas reste propre, l'éditeur fonctionne. Install → activé → plus de bug. Aucune configuration, aucune table, 70 lignes de JS.

PrestaShop 8.0+ Multi-boutique multi-domaines Fix natif Zero config 1 fichier JS Sans BDD
  • Remboursement 30 jours
  • 12 mois de mises à jour
  • Support 24h
www.datafirefly.com/
FX
v1.0.0 · mis à jour 2026-05-01
Ce que ça fait

La version courte.

01

Résoud le bug tainted canvas multishop

Si votre back-office est ouvert sur boutique-fr.com et que vous éditez un produit assigné à boutique-en.com, les images viennent de boutique-en.com → cross-origin → canvas tainted → SecurityError. Le fix réécrit les URLs des images vers le domaine actuel du BO avant que Dropzone ne les charge.

02

Patch monkey élégant et minimaliste

Le module écrit Dropzone.prototype.displayExistingFile une seule fois à l'init pour intercepter les URLs cross-origin. Pas de polling, pas de listener permanent, pas de surcharge — le patch est invisible une fois en place et n'a aucun impact mesurable sur les performances du BO.

03

Zéro footprint, zéro config

Le fichier JS du module est chargé uniquement sur les contrôleurs produit AdminProducts (legacy) et admin_products_v2 (Symfony). Le reste du back-office n'est pas impacté. Aucune base de données, aucun paramètre à régler.

04

Pas de bricolage du noyau

Aucune modification du noyau PrestaShop, des thumbnails, du système d'images. Le fix agit uniquement côté navigateur sur Dropzone. Si PrestaShop corrige nativement le bug dans une mise à jour future, le module reste sans effet négatif (patch idempotent).

La version longue

Tout ce que vous voudriez savoir avant d'installer.

Un regard détaillé sur le fonctionnement de DataFirefly Fix Dropzone CORS — Correctif tainted canvas multishop PrestaShop 8, pourquoi nous l'avons conçu ainsi, et la réflexion derrière les fonctionnalités ci-dessus.

§ 01

Le bug, en clair

Vous êtes sur PrestaShop 8 en multishop, avec plusieurs domaines différents — par exemple boutique-fr.com pour la France et boutique-en.com pour l'Angleterre, chacun avec son propre certificat HTTPS. Vous ouvrez le back-office depuis boutique-fr.com et vous cliquez sur un produit qui est associé à la boutique anglaise. Les images de ce produit sont servies depuis boutique-en.com, parce que c'est le domaine canonique de cette boutique. Pour le navigateur, c'est une ressource cross-origin — et comme les images PrestaShop natives n'envoient pas les bons headers CORS (Access-Control-Allow-Origin), le canvas qui doit générer l'aperçu Dropzone se retrouve « tainted ». Au prochain appel à ctx.getImageData, le navigateur lance une SecurityError, l'éditeur Dropzone plante, et le formulaire produit devient inutilisable pour la zone images. Erreur console : main.bundle.js:274 Uncaught SecurityError: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': The canvas has been tainted by cross-origin data. at main.bundle.js:274:137430 at L (main.bundle.js:274:137535) at main.bundle.js:274:123939 at o (main.bundle.js:274:123147) at l.onload (main.bundle.js:274:123297)

§ 02

Pourquoi ce bug est réel et important

Beaucoup de boutiques multi-domaines vivent avec ce bug depuis longtemps en s'épargnant de l'éditer en cross-domaine (en se connectant toujours sur le « bon » domaine pour chaque produit). Mais dans une vraie organisation équipe — catalogue managé par une seule personne, plusieurs sous-boutiques internationales — c'est intenable. PrestaShop a un correctif officiel sur Dropzone.vue dans certaines versions du nouvel éditeur Symfony, mais le bug persiste sur l'ancien éditeur AdminProducts et n'est pas toujours rétroporté sur les versions stables. Notre module règle le problème sur les deux éditeurs en même temps.

§ 03

Comment fonctionne le fix techniquement

Au chargement d'une page produit du back-office, le module injecte un fichier JS de 70 lignes dans l'en-tête via le hook displayBackOfficeHeader. Le script attend que window.Dropzone soit défini, puis remplace Dropzone.prototype.displayExistingFile par une version interceptée. Cette version examine l'URL reçue : si elle est cross-origin, elle parse l'URL avec new URL(url), force u.protocol et u.host à ceux de window.location.origin, recompose l'URL, et la passe à la méthode originale. Résultat côté navigateur : Dropzone reçoit une URL same-origin, le canvas reste « clean », getImageData fonctionne, le fichier image existant s'affiche normalement dans le drag & drop. Le patch est idempotent (un flag __dfCorsPatched empêche la double application) et fail-safe (les URLs invalides retombent sur le comportement original).

§ 04

Pourquoi pas un patch core ou un override

Un override de PrestaShop sur le contrôleur produit serait fragile : il casserait à chaque mise à jour majeure, et le code Dropzone n'est pas dans le contrôleur PHP. Une modification directe du fichier JS de Dropzone serait écrasée à chaque mise à jour. Le monkey-patch côté client, lui, est totalement non-invasif : aucun fichier PrestaShop n'est modifié, aucun core override n'est posé, le patch s'applique à l'exécution depuis l'extérieur. Si PrestaShop met à jour Dropzone ou son intégration, le patch reste fonctionnel tant que la signature de displayExistingFile ne change pas (ce qui est extrêmement stable depuis Dropzone 5.x). Si la méthode change ou si PrestaShop corrige nativement, vous pouvez désinstaller le module sans aucune trace résiduelle.

§ 05

Cas d'usage

Boutique multi-pays avec un domaine par marché (boutique-fr.com / boutique-en.com / boutique-es.com) gérée par une équipe centralisée — le bug bloque l'édition produit en cross-domaine, le module règle immédiatement. Marketplace ou réseau de marques en mode multishop multi-domaines — même configuration, même solution. Équipe d'agence gérant plusieurs sous-boutiques clients sur des domaines distincts — le module rend le back-office utilisable normalement sans avoir à jongler de domaine en domaine. Migration de mono-boutique vers multi-domaines — installé préventivement, le module évite la mauvaise surprise post-migration.