Hyvä läuft jetzt nativ auf Magento 2.4.9 und auf Mage-OS. Wir haben beides getestet. Was das für Ihren Shop bedeutet →
Kurz gesagt
Wenn es für eine Extension kein Hyvä-Kompatibilitätsmodul gibt, haben Sie fünf realistische Optionen: das Kompatibilitätsmodul selbst schreiben, die Extension ersetzen, nur den genutzten Teil neu bauen, diese Seite mit dem Fallback von Hyvä auf Luma belassen oder die Extension entfernen. Die richtige Wahl hängt davon ab, wie viel Storefront-Code die Extension mitbringt und wie wichtig sie für den Umsatz ist.
Sie haben das Extension-Audit abgeschlossen, und die meisten Module sind in Ordnung. Dann tauchen ein oder zwei wichtige auf, für die es überhaupt kein Hyvä-Kompatibilitätsmodul gibt.
Das ist normal und selten ein Grund, ein Hyvä-Projekt zu stoppen. Dieser Beitrag erklärt, warum es passiert und was Sie tun können.
Warum manche Extensions auf Hyvä nicht funktionieren
Eine Magento-Extension besteht in der Regel aus zwei Teilen. Der Backend-Teil enthält PHP-Logik, Datenbanktabellen, Admin-Einstellungen und Observer.
Der Frontend-Teil enthält Templates, Layout-XML, JavaScript und Styles. Unter Luma ist dieses JavaScript meist als RequireJS-Module, jQuery-Widgets oder Knockout-Komponenten geschrieben.
Hyvä entfernt diesen gesamten Stack. Der Backend-Teil arbeitet also weiter, aber der Frontend-Teil hat keine Grundlage mehr, auf der er laufen kann. Mehr über die beiden Stacks lesen Sie in wie Alpine.js und Tailwind RequireJS und Knockout ersetzen.
Ein Kompatibilitätsmodul schließt genau diese Lücke. Es ersetzt das Frontend der Extension durch Alpine.js und Tailwind CSS, während das ursprüngliche Backend erhalten bleibt.
So funktioniert ein Kompatibilitätsmodul
Ein Kompatibilitätsmodul ist ein kleines, separates Magento-Modul. Es ändert den Code der ursprünglichen Extension nicht, sodass diese weiterhin über Composer aktualisiert werden kann.
Hyvä bietet dafür einen Fallback-Mechanismus. Das Kompatibilitätsmodul registriert sich als Hyvä-Version des Originalmoduls, und Hyvä sucht Templates dann zuerst im Kompatibilitätsmodul.
<type name="Hyva\CompatModuleFallback\Model\CompatModuleRegistry">
<arguments>
<argument name="compatModules" xsi:type="array">
<item name="vendor_module_map" xsi:type="array">
<item name="original_module" xsi:type="string">Vendor_Module</item>
<item name="compat_module" xsi:type="string">Hyva_VendorModule</item>
</item>
</argument>
</arguments>
</type>Dieses Snippet gehört im Kompatibilitätsmodul in die Datei etc/frontend/di.xml. Innerhalb des Moduls schreiben Sie dann Hyvä-Versionen der Templates, die eine benötigen – mit Alpine.js statt Knockout oder jQuery.
Über Layout-XML lässt sich außerdem das ursprüngliche JavaScript entfernen, sodass es auf einer Hyvä-Seite nie geladen wird.
Option 1: das Kompatibilitätsmodul schreiben
Das ist die sauberste Option, wenn die Extension wichtig und ihr Frontend überschaubar ist.
- Sie behalten die Extension, ihre Backend-Logik und ihren Update-Pfad.
- Nur der Storefront-Teil wird neu gebaut, im selben Stil wie der Rest des Hyvä-Themes.
- Das Ergebnis ist schlank, weil es dem Ansatz von Hyvä folgt, statt alte Skripte zu laden.
Der Aufwand hängt davon ab, wie viel JavaScript das ursprüngliche Frontend enthält. Ein einfaches Widget ist eine kleine Aufgabe. Ein komplexer Produktkonfigurator oder Checkout-Schritt ist eine größere.
Bevor Sie selbst eines schreiben, fragen Sie den Anbieter der Extension, ob eine Hyvä-Version geplant ist. Viele Anbieter liefern inzwischen eigene aus.
Option 2: die Extension ersetzen
Manchmal ist das beste Kompatibilitätsmodul eine andere Extension. Wenn ein anderes Modul dieselbe Aufgabe erfüllt und bereits Hyvä-fähig ist, kann ein Wechsel günstiger und sicherer sein als eine Portierung.
Das funktioniert gut für gängige Funktionen wie Slider, Pop-ups, Social Login, Produkt-Labels oder einfache Such-Add-ons.
Prüfen Sie vor dem Wechsel die Datenmigration. Einstellungen, Inhalte oder Kundendaten von einem Modul ins andere zu übertragen, kann der versteckte Teil der Arbeit sein.
Option 3: nur nachbauen, was Sie nutzen
Große Extensions können oft weit mehr, als ein Shop tatsächlich nutzt. Vielleicht verwendet ein Shop nur ein einziges Widget aus einem funktionsreichen Modul.
In diesem Fall kann es sinnvoll sein, genau diese eine Funktion direkt im Hyvä-Theme oder als kleines individuelles Modul zu bauen. Unsere Magento-Extension-Entwicklung beginnt oft genau mit dieser Frage: Welchen Teil brauchen Sie wirklich?
Das Ergebnis ist meist schlanker und leichter zu warten als eine vollständige Portierung.
Option 4: eine Seite vorerst auf Luma belassen
Der Checkout ist der klassische Fall. Ein Zahlungsanbieter hat vielleicht noch keine Hyvä-fähige Integration, und eine Zahlungsart zu verlieren, ist keine Option.
Hyvä unterstützt dafür einen Fallback-Ansatz. Ausgewählte Seiten – meist der Checkout – werden weiter mit dem Luma-Theme gerendert, während der Rest des Shops auf Hyvä läuft.
- Kunden erhalten Hyvä-Geschwindigkeit auf Start-, Kategorie- und Produktseiten.
- Der Checkout funktioniert genau wie bisher, mit jeder Zahlungsart.
- Sie können den Checkout später auf Hyvä umstellen, sobald die Integration bereitsteht.
Das ist eine praktische Brücke, kein Endzustand. Der Luma-Checkout lädt weiterhin den alten Stack, planen Sie also, wann und wie Sie ihn umstellen.
Speziell für den Checkout können Sie Hyvä Checkout und andere Checkout-Varianten auch hier vergleichen: Lohnt sich Hyvä Checkout?.
Option 5: entfernen
Ein Audit fördert oft Extensions zutage, die niemand mehr nutzt. Manche wurden für eine vergangene Kampagne installiert, andere doppeln Funktionen, die Magento inzwischen selbst mitbringt.
Sie zu entfernen, ist die einfachste Portierung von allen. Außerdem wird der Shop dadurch leichter, sicherer und einfacher zu aktualisieren.
Prüfen Sie vor dem Entfernen eines Moduls, dass es keine Daten oder Einstellungen enthält, die Sie noch brauchen, und entfernen Sie es sauber über Composer, statt es nur zu deaktivieren.
So treffen Sie die Wahl
Stellen Sie für jede Extension ohne Kompatibilitätsmodul vier Fragen.
- Wirkt sie sich direkt auf den Umsatz aus, etwa im Checkout, im Warenkorb oder auf Produktseiten?
- Wie viel Storefront-JavaScript hat sie wirklich?
- Gibt es eine Hyvä-fähige Alternative, die dieselbe Aufgabe erfüllt?
- Nutzen Sie sie vollständig oder nur einen kleinen Teil davon?
| Situation | Übliche Wahl |
|---|---|
| Wichtig, überschaubares Frontend, keine gute Alternative | Kompatibilitätsmodul schreiben |
| Gängige Funktion mit Hyvä-fähigen Alternativen | Extension ersetzen |
| Großes Modul, kleiner Teil in Nutzung | Nur nachbauen, was Sie nutzen |
| Zahlungsart ohne Hyvä-Integration | Integration bauen oder Checkout vorerst auf Luma belassen |
| Wird nicht mehr genutzt | Entfernen |
Die meisten echten Projekte kombinieren alle fünf. Der Sinn des Hyvä-Migrations-Checkliste ist, diese Entscheidung einmal pro Modul zu treffen, bevor der Build beginnt.
FAQ
Verändert ein Kompatibilitätsmodul die ursprüngliche Extension?
Nein. Es ist ein separates Modul, das nur die Frontend-Templates und -Skripte ersetzt. Die ursprüngliche Extension lässt sich weiterhin wie gewohnt aktualisieren.
Kann ich auf Hyvä nicht einfach RequireJS laden, damit eine alte Extension funktioniert?
Theoretisch ist das möglich, aber es bringt das Gewicht zurück, das Hyvä entfernt, und führt oft zu subtilen Fehlern. Eine saubere Portierung oder der Luma-Fallback ist sicherer.
Was ist, wenn der Anbieter später eine eigene Hyvä-Version veröffentlicht?
Dann können Sie auf die Version des Anbieters wechseln und Ihr eigenes Kompatibilitätsmodul stilllegen. Bleibt die Portierung separat, ist dieser Wechsel einfach.
Wir machen bestehende Module Hyvä-fähig und bauen bei Bedarf neue. Sehen Sie sich unsere Hyvä-Theme-Entwicklung Leistungen an, um Ihren Umstieg zu planen.
English
German
Dutch
Turkish