Alles wat u wilt weten voordat u installeert.
Een gedetailleerde blik op hoe DataFirefly Fix Dropzone CORS: Correctie voor Tainted Canvas bij Multishop in PrestaShop 8 werkt, waarom we het zo gebouwd hebben en de gedachte achter de bovenstaande functies.
De fout, in gewone taal
U draait PrestaShop 8 in multishop met meerdere verschillende domeinen, bijvoorbeeld winkel-nl.com voor Nederland en winkel-en.com voor het Verenigd Koninkrijk, elk met een eigen HTTPS-certificaat. U opent de backoffice via winkel-nl.com en klikt op een product dat aan de Engelse winkel hangt. De afbeeldingen van dat product worden vanaf winkel-en.com geserveerd, want dat is het canonieke domein van die winkel. Voor de browser is dat een cross-origin bron, en omdat de native PrestaShop-afbeeldingen niet de juiste CORS-headers meesturen (Access-Control-Allow-Origin), raakt het canvas dat de Dropzone-voorvertoning moet opbouwen besmet. Bij de eerstvolgende aanroep van ctx.getImageData gooit de browser een SecurityError, de Dropzone-editor loopt vast, en de afbeeldingszone van het productformulier wordt onbruikbaar. De foutmelding in de console: main.bundle.js:274 Uncaught SecurityError: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': The canvas has been tainted by cross-origin data.
Waarom deze fout er werkelijk toe doet
Veel winkels met meerdere domeinen leven al lang met deze fout door het bewerken over domeinen heen te vermijden, dus door zich voor elk product altijd op het juiste domein aan te melden. Maar in een echte teamorganisatie, met een catalogus die door één persoon wordt beheerd en meerdere internationale subwinkels, is dat niet vol te houden. PrestaShop heeft in sommige versies van de nieuwe Symfony-editor een officiële correctie op Dropzone.vue, maar de fout blijft bestaan in de oude AdminProducts-editor en wordt niet altijd naar de stabiele versies teruggezet. Onze module lost het probleem in beide editors tegelijk op.
Hoe de fix technisch werkt
Bij het laden van een productpagina in de backoffice voegt de module via de hook displayBackOfficeHeader een JS-bestand van 70 regels toe aan de header. Het script wacht tot window.Dropzone bestaat en vervangt daarna Dropzone.prototype.displayExistingFile door een onderschepte versie. Die versie bekijkt de ontvangen URL: is die cross-origin, dan wordt de URL met new URL(url) uit elkaar gehaald, worden u.protocol en u.host op die van window.location.origin gezet, wordt de URL weer samengesteld en aan de oorspronkelijke methode doorgegeven. Aan browserzijde krijgt Dropzone dus een URL van dezelfde oorsprong, blijft het canvas schoon, werkt getImageData gewoon, en verschijnt de bestaande afbeelding netjes in het sleepgebied. De patch is idempotent (een vlag __dfCorsPatched voorkomt dubbele toepassing) en veilig bij fouten (ongeldige URL's vallen terug op het oorspronkelijke gedrag).
Waarom geen ingreep in de core of een override
Een PrestaShop-override op de productcontroller zou kwetsbaar zijn: die breekt bij elke grote update, en de Dropzone-code zit sowieso niet in de PHP-controller. Het JS-bestand van Dropzone rechtstreeks aanpassen zou bij elke update worden overschreven. Een monkey patch aan clientzijde is daarentegen volledig niet-invasief: er wordt geen enkel PrestaShop-bestand gewijzigd, er komt geen override in de core, en de patch wordt tijdens de uitvoering van buitenaf toegepast. Werkt PrestaShop Dropzone of de koppeling daarmee bij, dan blijft de patch werken zolang de signatuur van displayExistingFile niet verandert (en die is sinds Dropzone 5.x bijzonder stabiel). Verandert die methode toch, of lost PrestaShop het zelf op, dan verwijdert u de module zonder dat er iets achterblijft.
Gebruikssituaties
Een winkel voor meerdere landen met een eigen domein per markt (winkel-nl.com, winkel-en.com, winkel-es.com), beheerd door één centraal team: de fout blokkeert het bewerken van producten over domeinen heen, en de module lost dat meteen op. Een marktplaats of een netwerk van merken in multishop met meerdere domeinen: dezelfde opzet, dezelfde oplossing. Een bureau dat meerdere klantwinkels op aparte domeinen beheert: de module maakt de backoffice gewoon bruikbaar zonder telkens van domein te wisselen. En bij een overstap van één winkel naar meerdere domeinen: preventief geïnstalleerd voorkomt de module de onaangename verrassing na de migratie.
Er zijn nog geen beoordelingen.