Blog · 28. August 2026 · 6 Min. Lesezeit

Der EU-Gewährleistungshinweis auf einem Hyvä-Storefront

Die meisten Magento-Compliance-Extensions sind für Luma geschrieben. Auf einem Hyvä-Storefront scheitern sie still oder funktionieren nur, indem sie Lumas Frontend in ein Theme zurückholen, das genau deshalb existiert, um es loszuwerden. Mit einer harten Frist zum 27. September 2026 prüft man das besser vor dem Kauf als danach.

Warum eine Luma-Extension nicht einfach funktioniert

Hyvä ist kein umgestyltes Luma. Es bringt kein requireJS, kein Knockout und kein Luma-Stylesheet mit. Eine Extension, die ihr Modal über Magentos Luma-Modal-Widget rendert, hat auf Hyvä daher drei Möglichkeiten — und alle drei sind schlecht:

Still scheitern. Das Markup wird ausgegeben, der Auslöser tut nichts, und es fällt niemandem auf, bis jemand darauf klickt. Bei einer Compliance-Funktion ist das der schlimmste Fall: Der Shop sieht rechtskonform aus und ist es nicht.
Luma zurückholen. Manche Extensions laden requireJS oder Luma-CSS auf den betroffenen Seiten nach. Das funktioniert — und macht einen wesentlichen Teil des Grundes zunichte, warum der Shop auf Hyvä gewechselt ist.
Eine zweite Extension verkaufen. Zwei Pakete, zwei Konfigurationen, zwei Lizenzen — und eine Mehrshop-Installation mit einem Luma- und einem Hyvä-Shop braucht beide.

Wie eine saubere Umsetzung aussieht

Tragfähig ist das Muster, das laufende Theme zu erkennen und aus einem zweiten, für Hyvä geschriebenen Template zu rendern, ausgewählt zur Renderzeit — statt ein Luma-Template in eine Hyvä-Seite zu zwingen. Fünf Details trennen eine Umsetzung, die funktioniert, von einer, die nur ausgibt:

Kein Frontend-Rebuild. Hyvä kompiliert Tailwind aus den Klassen, die es beim Scannen findet. Ein Drittanbieter-Template, das nach dem letzten Build dazukommt, verliert seine Klassen. Die Lösung: Der Hinweis bringt Größe und Pop-up-Layout selbst mit, statt sich auf Utility-Klassen zu verlassen, die vielleicht überlebt haben — kein Eintrag in tailwind.config.js, kein Rebuild zu merken und nichts, was beim nächsten gedankenlosen Rebuild kaputtgeht.
CSP-taugliches Alpine. Hyväs CSP-Build verbietet die Ausdrucksauswertung, auf die gewöhnliche Alpine-Komponenten bauen. Ein als benannte Komponente registriertes Pop-up läuft auf dem Standard- wie auf dem CSP-Build; ein inline geschriebenes nur auf dem Standard-Build — und scheitert damit genau bei den Shops, die Sicherheit ernst genommen haben.
Ehrliche Theme-Erkennung. Ein Projekt-Theme liegt meist mehrere Generationen von einer Hyvä-Basis entfernt. Die Erkennung muss die Vererbungskette entlanglaufen; ein vollständig herausgelöstes Theme, das von nichts erbt, muss sich in der Konfiguration benennen lassen, statt still als Luma behandelt zu werden.
Der Footer-Link ist der schwierige Fall. Luma hat eine Footer-Linkliste, in die sich ein Modul einhängen kann. Hyvä nicht: Der Footer Ihres Themes ist Markup, kein Block. Einen Link in Markup zu spleißen, das eine Extension nie gesehen hat, ist der Weg, Themes kaputtzumachen — ehrlicher ist es, Ihnen das Layout zum Einfügen in Ihr eigenes Theme zu geben und jede andere Platzierung zu automatisieren.
Der Checkout ist eine eigene Frage. Magentos eigener Checkout bedeutet auf Hyvä den Luma Fallback Checkout, und dort rendert eine Checkout-Platzierung. Hyvä Checkout ist eine eigene Anwendung — eine andere Codebasis mit eigenen Erweiterungspunkten. Wer ihn einsetzt, plant die Checkout-Platzierung getrennt; und wer als Anbieter diese Unterscheidung nicht erwähnt, verdient Misstrauen.

Fragen, die man einem Anbieter stellen sollte

Deckt ein Paket Luma und Hyvä ab, oder brauche ich für eine gemischte Mehrshop-Installation zwei Lizenzen?
Muss ich nach der Installation etwas in tailwind.config.js eintragen oder das Frontend neu bauen?
Funktioniert es auf Hyväs CSP-Build?
Erreicht das Pop-up den Hinweis auch mit deaktiviertem JavaScript?
Welchen Checkout unterstützt die Checkout-Platzierung — Luma Fallback Checkout, Hyvä Checkout oder beide?

Frage vier trennt eine Compliance-Funktion von einer Dekoration. Ist jeder Auslöser schon vor jedem Skript ein echter Link auf den Hinweis, erreicht ihn auch jemand mit fehlgeschlagenem JavaScript in einem neuen Tab. Ist der Auslöser ein <span>, das auf einen Click-Handler wartet, ist er tot — und „unser Hinweis ist sichtbar, sofern JavaScript funktioniert" ist keine Position, die man verteidigen möchte.

Replatforming

Zieht ein Luma-Shop nach Hyvä um, sollte die Compliance-Schicht den Umzug überstehen. Eine Extension, die beides aus einem Paket abdeckt, bedeutet dieselbe Konfiguration und dieselbe Compliance-Position vorher wie nachher; nur das Theme wechselt. Eine je Frontend gekaufte Extension bedeutet, diese Arbeit zweimal zu machen — beim zweiten Mal unter Termindruck.

Wir entwickeln EU-Gewährleistungshinweis, eine Magento-2-Extension, die den offiziellen Hinweis in allen 24 Sprachen auf einem Luma- oder Hyvä-Storefront anzeigt.

Dieser Beitrag beschreibt, wie wir die Durchführungsverordnung (EU) 2025/1960 beim Bau einer Extension gelesen haben. Er ist keine Rechtsberatung. Ob, wann und wo der Hinweis Ihr Unternehmen betrifft, bleibt Ihre Verantwortung und sollte fachkundig geprüft werden.