Hyvä-spezifische Einstellungen

Welche zusätzlichen Konfigurationsoptionen ein Hyvä-Theme im Backend mitbringt, die Luma nicht hat.

Hyvä-Themes bringen — je nach installierten Hyvä-Modulen — eigene Konfigurationsbereiche unter Stores > Configuration mit, meist in einer eigenen Sektion "Hyvä Themes":

• Hyvä Theme (Basis-Modul): u. a. Einstellungen zum Cookie-Consent-Verhalten, zu Bildkomprimierung/Lazy Loading und zur Content Security Policy (CSP), da Hyvä-Themes standardmäßig eine strikte CSP nutzen.
• Hyvä CSP: in diesem Projekt aktiv verwendet — jedes eingebundene Inline-Script muss explizit über $hyvaCsp->registerInlineScript() im Code registriert werden, damit es nicht vom Browser blockiert wird (rein entwicklerseitig, nicht im Backend konfigurierbar).
• GraphQL-Caching: da Hyvä-Themes clientseitig stark auf GraphQL setzen (z. B. für den Warenkorb), gibt es teils eigene Cache-Einstellungen für GraphQL-Antworten.

Der wichtigste konzeptionelle Unterschied zu Luma: Hyvä verzichtet komplett auf Knockout.js und lädt kein jQuery — Interaktivität läuft über Alpine.js. Das bedeutet u. a., dass klassische Luma-Erweiterungen mit Knockout-Komponenten NICHT ohne Anpassung mit Hyvä funktionieren; achten Sie beim Kauf neuer Erweiterungen auf explizite Hyvä-Kompatibilität.

Cookie-Consent-Verwaltung im Detail

Das Hyvä-Cookie-Consent-Modul erlaubt es, unter Stores > Configuration > Hyvä Themes nicht nur den Consent-Banner ein- oder auszuschalten, sondern auch verschiedene Cookie-Kategorien (z. B. essenzielle, funktionale, Statistik- und Marketing-Cookies) mit eigenen Texten zu pflegen. Skripte, die einer nicht-essenziellen Kategorie zugeordnet sind, werden im Frontend erst nach aktiver Zustimmung des Besuchers geladen — technisch über Alpine.js-Bindings, die auf den gespeicherten Consent-Status reagieren.

Praxis-Tipp: Wird ein neues Tracking- oder Marketing-Skript eingebunden, muss es sowohl in die passende Consent-Kategorie einsortiert als auch — wegen der aktiven CSP — als erlaubte Quelle registriert werden (siehe nächster Abschnitt). Beides zu vergessen ist eine häufige Fehlerquelle, wenn ein Skript im Frontend plötzlich nicht lädt.

CSP: Erlaubte Hosts für Drittanbieter-Skripte pflegen

Bindet man Drittanbieter-Dienste wie Google Maps, Google Tag Manager, einen Chat-Widget-Anbieter oder Zahlungs-Skripte ein, blockiert die von Hyvä standardmäßig aktive Content Security Policy deren Aufruf, solange die jeweilige Domain nicht explizit erlaubt ist. Unter Stores > Configuration > Hyvä Themes > Hyvä CSP lassen sich pro Direktive (u. a. script-src, style-src, img-src, connect-src, font-src) zusätzliche erlaubte Hosts eintragen.

Praxis-Tipp: Bevor eine neue CSP-Regel produktiv geschaltet wird, hilft der Report-Only-Modus — dabei werden Verstöße nur protokolliert statt blockiert, sodass sich fehlende Hosts erst identifizieren lassen, ohne dass Kunden von einem defekten Skript betroffen sind.

Kompatibilität mit klassischen Luma-Erweiterungen

Für Drittanbieter-Erweiterungen, die ursprünglich für Luma mit Knockout.js-Komponenten entwickelt wurden und noch nicht auf Hyvä umgestellt sind, existiert ein separates Kompatibilitäts-Modul, das solche Komponenten isoliert innerhalb einer Hyvä-Seite lauffähig macht. Es ist kein Ersatz für eine native Hyvä-Integration, sondern eine Übergangslösung, die zusätzliches JavaScript (RequireJS/Knockout) nachlädt — was dem eigentlichen Ziel eines schlanken, jQuery-freien Frontends entgegensteht.

Praxis-Tipp: Prüfen Sie vor dem Kauf einer neuen Erweiterung immer, ob eine native Hyvä-Version existiert, bevor Sie auf ein Kompatibilitäts-Modul zurückgreifen — letzteres sollte die Ausnahme bleiben, nicht die Regel, da es Ladezeit und CSP-Komplexität wieder erhöht.