Alles, was Sie wissen sollten bevor Sie installieren.
Ein detaillierter Blick darauf, wie DataFirefly Fix Dropzone CORS — Tainted-Canvas-Behebung Multi-Shop PrestaShop 8 funktioniert, warum wir es so gebaut haben und der Gedanke hinter den Funktionen oben.
Der Bug, klar erklärt
Sie sind auf PrestaShop 8 im Multi-Shop, mit mehreren unterschiedlichen Domains — zum Beispiel boutique-fr.com für Frankreich und boutique-en.com für England, jede mit eigenem HTTPS-Zertifikat. Sie öffnen das Backoffice von boutique-fr.com und klicken auf ein Produkt, das mit dem englischen Shop verknüpft ist. Die Bilder dieses Produkts werden von boutique-en.com ausgeliefert, weil das die kanonische Domain dieses Shops ist. Für den Browser ist das eine cross-origin Ressource — und da die nativen PrestaShop-Bilder nicht die korrekten CORS-Header senden (Access-Control-Allow-Origin), wird das Canvas, das die Dropzone-Vorschau generieren soll, „tainted“. Beim nächsten Aufruf von ctx.getImageData wirft der Browser eine SecurityError, der Dropzone-Editor stürzt ab, und das Produktformular wird für den Bildbereich unbrauchbar. Konsole-Fehler: 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)
Warum dieser Bug real und wichtig ist
Viele Multi-Domain-Shops leben mit diesem Bug seit langer Zeit, indem sie sich die Bearbeitung im Cross-Domain ersparen (immer auf der „richtigen“ Domain für jedes Produkt einloggen). Aber in einer echten Team-Organisation — von einer einzigen Person verwalteter Katalog, mehrere internationale Sub-Shops — ist das nicht haltbar. PrestaShop hat eine offizielle Korrektur in Dropzone.vue in bestimmten Versionen des neuen Symfony-Editors, aber der Bug besteht im alten AdminProducts-Editor weiter und ist nicht immer auf die stabilen Versionen zurückportiert. Unser Modul löst das Problem auf beiden Editoren gleichzeitig.
Wie die Behebung technisch funktioniert
Beim Laden einer Backoffice-Produktseite injiziert das Modul eine 70-Zeilen-JS-Datei in den Header über den Hook displayBackOfficeHeader. Das Skript wartet, bis window.Dropzone definiert ist, dann ersetzt es Dropzone.prototype.displayExistingFile durch eine intercepting Version. Diese Version untersucht die empfangene URL: wenn sie cross-origin ist, parsed sie die URL mit new URL(url), setzt u.protocol und u.host auf die von window.location.origin, rekomponiert die URL und gibt sie an die Originalmethode weiter. Ergebnis browser-seitig: Dropzone erhält eine same-origin URL, das Canvas bleibt „clean“, getImageData funktioniert, das bestehende Bild zeigt sich normal im Drag-and-Drop. Der Patch ist idempotent (ein Flag __dfCorsPatched verhindert die doppelte Anwendung) und fail-safe (ungültige URLs fallen auf das Originalverhalten zurück).
Warum kein Core-Patch oder Override
Ein PrestaShop-Override auf den Produkt-Controller wäre fragil: er würde bei jeder Major-Aktualisierung brechen, und der Dropzone-Code befindet sich nicht im PHP-Controller. Eine direkte Modifikation der Dropzone-JS-Datei würde bei jeder Aktualisierung überschrieben. Der client-seitige Monkey-Patch hingegen ist völlig nicht-invasiv: keine PrestaShop-Datei wird modifiziert, kein Core-Override wird gesetzt, der Patch wird zur Laufzeit von außen angewendet. Wenn PrestaShop Dropzone oder seine Integration aktualisiert, bleibt der Patch funktional, solange die Signatur von displayExistingFile sich nicht ändert (was seit Dropzone 5.x extrem stabil ist). Wenn die Methode sich ändert oder PrestaShop nativ behebt, können Sie das Modul ohne Spuren-Rückstand deinstallieren.
Anwendungsfälle
Multi-Länder-Shop mit einer Domain pro Markt (boutique-fr.com / boutique-en.com / boutique-es.com) verwaltet von einem zentralen Team — der Bug blockiert die Cross-Domain-Produktbearbeitung, das Modul löst sofort. Marketplace oder Markennetzwerk im Multi-Shop-Multi-Domain-Modus — dieselbe Konfiguration, dieselbe Lösung. Agentur-Team, das mehrere Kunden-Sub-Shops auf unterschiedlichen Domains verwaltet — das Modul macht das Backoffice normal nutzbar, ohne von Domain zu Domain zu jonglieren. Migration von Mono-Shop zu Multi-Domain — präventiv installiert, vermeidet das Modul die böse Überraschung nach der Migration.
Rezensionen
Es gibt noch keine Rezensionen.