Everything you'd want to know before you install.
A detailed look at how DataFirefly Fix Dropzone CORS — Multi-store tainted canvas fix for PrestaShop 8 works, why we built it the way we did, and the thinking behind the features above.
The bug, in clear terms
You're on PrestaShop 8 in multi-store, with several different domains — for example store-fr.com for France and store-en.com for England, each with its own HTTPS certificate. You open the back office from store-fr.com and click on a product associated with the English store. The images for this product are served from store-en.com, because that's the canonical domain of that store. For the browser, it's a cross-origin resource — and since native PrestaShop images don't send the right CORS headers (Access-Control-Allow-Origin), the canvas that needs to generate the Dropzone preview ends up "tainted". On the next ctx.getImageData call, the browser throws a SecurityError, the Dropzone editor crashes, and the product form becomes unusable for the image zone.
Why this bug is real and important
Many multi-domain stores have lived with this bug for a long time by avoiding cross-domain editing (always logging in to the "right" domain for each product). But in a real team organization — catalog managed by a single person, several international sub-stores — it's untenable. PrestaShop has an official fix on Dropzone.vue in some versions of the new Symfony editor, but the bug persists on the legacy AdminProducts editor and isn't always backported to stable versions. Our module solves the problem on both editors at once.
How the fix works technically
On product page load in the back office, the module injects a 70-line JS file into the header via the displayBackOfficeHeader hook. The script waits for window.Dropzone to be defined, then replaces Dropzone.prototype.displayExistingFile with an intercepted version. This version examines the received URL: if it's cross-origin, it parses the URL with new URL(url), forces u.protocol and u.host to those of window.location.origin, recomposes the URL, and passes it to the original method. Browser-side result: Dropzone receives a same-origin URL, the canvas stays "clean", getImageData works, the existing image file displays normally in the drag & drop. The patch is idempotent (a __dfCorsPatched flag prevents double application) and fail-safe (invalid URLs fall back to original behavior).
Why not a core patch or override
A PrestaShop override on the product controller would be fragile: it would break with every major update, and the Dropzone code isn't in the PHP controller. A direct modification of the Dropzone JS file would be overwritten with every update. The client-side monkey-patch, on the other hand, is totally non-invasive: no PrestaShop file is modified, no core override is placed, the patch is applied at runtime from outside. If PrestaShop updates Dropzone or its integration, the patch remains functional as long as the displayExistingFile signature doesn't change (which is extremely stable since Dropzone 5.x). If the method changes or PrestaShop fixes it natively, you can uninstall the module without any residual trace.
Use cases
Multi-country store with one domain per market (store-fr.com / store-en.com / store-es.com) managed by a centralized team — the bug blocks cross-domain product editing, the module solves it immediately. Marketplace or brand network in multi-store multi-domain mode — same configuration, same solution. Agency team managing several client sub-stores on distinct domains — the module makes the back office usable normally without juggling domain by domain. Migration from mono-store to multi-domain — installed preventively, the module avoids the post-migration unpleasant surprise.
Reviews
There are no reviews yet.