Hyvä-Kompatibilität: Welche Magento-Erweiterungen funktionieren?
Jede kostenpflichtige Magento-Erweiterung, die das Frontend berührt, benötigt ein Hyvä-Kompatibilitätsmodul, bevor sie unter Hyvä korrekt dargestellt wird. Ohne dieses Modul läuft die Backend-Logik der Erweiterung weiterhin, die Admin-Konfiguration, Beobachter, Ereignisse, aber die sichtbare Ausgabe bleibt stumm. Kunden sehen nichts, wo die Erweiterung dargestellt werden sollte.
Die gute Nachricht: Die meisten großen Anbieter liefern jetzt ein eigenes Hyvä-Kompatibilitätsmodul. Die schlechte Nachricht: Der lange Schwanz kleinerer und älterer Erweiterungen tut dies nicht, und Sie benötigen eine benutzerdefinierte Kompatibilität für jede.
Dieser Beitrag ist der praktische Leitfaden, um zu überprüfen, was funktioniert und was nicht, sowie was benutzerdefinierte Kompatibilität kostet, wenn Sie sie benötigen.
Der erste Ort, den Sie überprüfen sollten: compat.hyva.io
compat.hyva.io ist der von der Community gepflegte Hyvä-Kompatibilitäts-Tracker. Jede kostenpflichtige Magento-Erweiterung, die ein Hyvä-Kompatibilitätsmodul hat, das vom Anbieter bereitgestellt oder von der Community beigetragen wurde, ist dort mit Status, Versionskompatibilität und einem Link zum Modul aufgeführt.
Vor jedem Scoping-Anruf zur Hyvä-Migration sollte der Händler Folgendes wissen:
- Die vollständige Liste der kostenpflichtigen Erweiterungen in ihrem Shop (Anbieter + Version + Lizenzstatus)
- Welche davon auf compat.hyva.io mit dem Status "Kompatibel" aufgeführt sind (Anbieter-Kompatibilität verfügbar)
- Welche als "Workaround" aufgeführt sind (community-beigetragene Kompatibilität existiert)
- Welche als "Nicht kompatibel" oder "Unbekannt" aufgeführt sind (Sie benötigen benutzerdefinierte Kompatibilität)
Diese 15-minütige Übung spart Wochen an Projektentdeckungszeit.
Kategorien der Erweiterungskompatibilität
In grober Reihenfolge des "Aufwands":
1. Vom Anbieter bereitgestellte Hyvä-Kompatibilität (null Aufwand)
Der Anbieter der Erweiterung veröffentlicht sein eigenes Hyvä-Kompatibilitätsmodul. Die Installation erfolgt über composer require + einen Konfigurationswechsel. 30 Minuten pro Erweiterung.
Anbieter, die ab 2026 Hyvä-Kompatibilität liefern:
- Amasty (die meisten ihrer großen Erweiterungen)
- Mageplaza (die meisten modernen Erweiterungen)
- Aheadworks (ausgewählte Erweiterungen)
- Mirasvit (ausgewählte Erweiterungen)
- MGS (ausgewählte Erweiterungen)
- Mageworx (ausgewählte Erweiterungen)
- Yotpo, Klaviyo, Bloomreach (die Marketing-Tools)
- Stripe, Adyen, Klarna, PayPal, Worldpay, Mollie, Braintree (Zahlungsgateways)
- Signifyd, Riskified (Betrug)
- ShipperHQ, ShipStation (Versand)
Diese Liste wächst jedes Quartal. Überprüfen Sie compat.hyva.io für den aktuellen Status, die Anbieterliste ist wichtiger als jeder Blogbeitrag.
2. Von der Community beigetragene Hyvä-Kompatibilität (geringer Aufwand)
Open-Source-Kompatibilitätsmodule, die von Mitgliedern der Hyvä-Community für weit verbreitete kommerzielle Erweiterungen beigetragen wurden. Oft unter der MIT-Lizenz veröffentlicht, häufig von Hyvä-spezialisierten Agenturen (einschließlich uns, wir veröffentlichen unsere über unsere GitHub-Organisation).
Die Installation erfolgt über composer require aus einem öffentlichen Repository. Das Risiko liegt in der Wartung, die Community-Kompatibilität ist nur so aktuell wie der letzte Commit von jemandem. Überprüfen Sie, ob das Kompatibilitätsmodul Ihre Erweiterungsversion unterstützt, bevor Sie es als kostenlosen Gewinn zählen.
3. Benutzerdefinierte Hyvä-Kompatibilität erforderlich (mittlerer bis hoher Aufwand)
Wenn weder der Anbieter noch die Community ein Kompatibilitätsmodul bereitgestellt haben, müssen Sie eines erstellen. Die Kosten variieren:
- Nur Anzeige-Erweiterungen (Banner, Abzeichen, Inhaltsblöcke, Social-Proof-Widgets): £1,500–£3,000 pro Erweiterung, 1–3 Tage Arbeit
- PDP / PLP-berührende Erweiterungen (Produktvariantenwähler, Konfiguratoren, Bildergalerien): £2,500–£5,000 pro Erweiterung, 3–5 Tage
- Checkout-berührende Erweiterungen (Zahlung, Betrug, Versandkostenrechner, Geschenkkarten, Store-Guthaben): £4,000–£8,000 pro Erweiterung, 5–10 Tage plus Testen des Bestellflusses
Die Abweichung ergibt sich daraus, wie tief die Erweiterung in das Frontend integriert ist. Nur Anzeige ist eine unkomplizierte Template-Neuimplementierung. Checkout-berührende Erweiterungen benötigen Integrationstests über echte Bestellungen.
Was ein Hyvä-Kompatibilitätsmodul tatsächlich tut
Für die technischen Leser, das Muster von docs.hyva.io:
- Ein neues Magento-Modul, das von dem Modul der ursprünglichen Erweiterung abhängt
- Layout-Updates, die auf die Blöcke der ursprünglichen Erweiterung abzielen und diese durch Hyvä-darstellte Versionen ersetzen
- Hyvä-native Templates (.phtml-Dateien), die die Frontend-Ausgabe der Erweiterung mit Tailwind-Klassen und Alpine.js-Komponenten neu implementieren
- Magische Strings und Ereignisdispatcher bleiben erhalten, sodass die Admin-Konfiguration der Erweiterung unverändert bleibt
- Optional, ein Alpine-Store, wenn die Erweiterung einen reaktiven clientseitigen Zustand benötigt (z. B. einen konfigurierbaren Preisrechner)
Das Muster ist gut dokumentiert; die Arbeit ist mechanisch, aber mühsam. Ein Spezialist erstellt diese 2x schneller als ein Generalist, der das Muster lernt.
Wann man die Kompatibilität überspringen und Erweiterungen wechseln sollte
Manchmal ist die richtige Antwort nicht, die Kompatibilität zu erstellen, sondern die Erweiterung durch eine Hyvä-native Alternative zu ersetzen. Zwei Szenarien, in denen wir empfehlen, zu wechseln:
1. Die Erweiterung ist stark vernachlässigt. Wenn der Anbieter seit über 18 Monaten keine Updates geliefert hat, ist es besser, die Erweiterung durch eine gewartete Hyvä-native Alternative zu ersetzen, anstatt jetzt Kompatibilität zu erstellen.
2. Ein natives Hyvä-Modul existiert. Wenn es ein Hyvä-erster Äquivalent gibt, das denselben Job zu vergleichbaren Kosten erledigt, ist der Austausch sauberer als die dauerhafte Wartung einer benutzerdefinierten Kompatibilität. Oft funktioniert die Hyvä-native Version besser und hat einen kleineren Code-Fußabdruck.
Wir sagen Ihnen, welcher Weg günstiger ist, bereits in der Scoping-Phase, nicht nachdem Sie das Kompatibilitätsmodul bereits in Auftrag gegeben haben.
Das Problem "Wir müssen unsere Erweiterungsliste kennen"
Die größte Ursache für die Scope-Creep bei der Hyvä-Migration ist das Entdecken einer Erweiterung während des Projekts, die nicht auf der ursprünglichen Liste stand. Jede überraschende Erweiterung fügt 1–2 Wochen zum Zeitrahmen und £1.5k–£8k zum Budget hinzu.
So vermeiden Sie das: Führen Sie das Erweiterungsinventar gründlich vor dem Scoping-Anruf durch. Einschließlich:
- Alle Erweiterungen in
composer.json(Anbieter + Version) - Alle Erweiterungen in
app/code/*, die nicht über Composer geliefert wurden - Alle Drittanbieter-Themen oder -Module, auch wenn "wir sie nicht wirklich nutzen"
- Alle Erweiterungen in Admin → System → Erweiterungsmanager (oder composer.lock)
- Benutzerdefinierte Inhouse-Module, die das Frontend berühren
Das Einfügen von composer.json + composer.lock in ein gemeinsames Dokument ist normalerweise ausreichend.
Was ist mit ZIP-installierten Erweiterungen?
Einige ältere oder budgetfreundliche Erweiterungen werden immer noch als ZIP-Dateien für die manuelle Installation anstelle von Composer geliefert. Diese sind normalerweise der schlechteste Fall für die Hyvä-Migration, weil:
- Der Erweiterungscode ist oft älter, weniger gewartet
- Keine Versionsverfolgung bedeutet, dass es schwieriger ist, die Versionen des Kompatibilitätsmoduls zu überprüfen
- Anbieter-Kompatibilität, die auf Composer basiert, zielt normalerweise nur auf Composer-installierte Erweiterungen ab
Wenn Sie ZIP-installierte Erweiterungen haben, planen Sie entweder:
- Auf eine Composer-verteilte Version zu aktualisieren (oft kostenpflichtig)
- Durch eine Hyvä-native Alternative zu ersetzen
- Benutzerdefinierte Kompatibilität zu erstellen (die teuerste Option)
ZIP-installierte Erweiterungen sind der Grund, warum Magento-Upgrades länger dauern als sie sollten; dasselbe Problem gilt für Hyvä-Migrationen.
Die Bibliothek der Kompatibilitätsmodule, warum sie sich summiert
Eine spezialisierte Hyvä-Agentur sammelt im Laufe der Zeit eine Bibliothek von benutzerdefinierten Kompatibilitätsmodulen an. Nach ihrer 10. Hyvä-Migration greifen sie auf ein vorgefertigtes Modul zurück, anstatt eines von Grund auf neu zu schreiben, das ist der Unterschied zwischen einem 6-wöchigen und einem 10-wöchigen Projekt mit demselben Umfang.
Für uns speziell: Wir haben über 100 benutzerdefinierte Hyvä-Kompatibilitätsmodule in unseren Kundenprojekten geliefert, mit einem bedeutenden Teil, der über unsere GitHub-Organisation Open Source ist. Neue Kunden profitieren von der Bibliothek, Erweiterungen, die für ein erstes Hyvä-Team einen 2-wöchigen benutzerdefinierten Kompatibilitätsaufbau erforderten, sind für uns eine 30-minütige Installation.
Dies ist der praktische Fall für die Wahl eines Spezialisten: Die Bibliothek summiert sich.
Preisgestaltung, was die Kompatibilitätsarbeit tatsächlich kostet
Kosten für benutzerdefinierte Kompatibilität pro Erweiterung:
| Komplexität | Zeit | Kosten |
|---|---|---|
| Nur Anzeige (Banner, Abzeichen, Inhaltsblock) | 1–3 Tage | £1,500–£3,000 |
| PDP-berührend (Variantenwähler, Konfigurator) | 3–5 Tage | £2,500–£5,000 |
| Checkout-berührend (Zahlung, Betrug, Versand) | 5–10 Tage | £4,000–£8,000 |
| Warenkorb-berührend (Geschenkkarte, Store-Guthaben, Bundles) | 3–7 Tage | £3,000–£6,000 |
| Kundenkonto (Abonnements, Wallets, Rücksendungen) | 3–7 Tage | £3,000–£6,000 |
In eine Hyvä-Migration integriert, ist die Kompatibilitätsarbeit Teil des gesamten Festpreisangebots. Als Standalone (Sie haben eine bestehende Hyvä-Website und eine neue Erweiterung hinzuzufügen), gelten die oben genannten Preise pro Erweiterung.
Open-Source-Beitragsrichtlinie
Wenn wir Kompatibilität für eine weit verbreitete kommerzielle Erweiterung erstellen, veröffentlichen wir sie unter MIT über unsere GitHub-Organisation. Die breitere Hyvä-Community profitiert und der nächste Kunde, der sie benötigt, erhält sie kostenlos.
Kundenspezifische benutzerdefinierte Arbeiten (maßgeschneiderte Module, die einzigartig für einen Händler sind) bleiben standardmäßig privat. Wir werden die Open-Source-Veröffentlichung bei der Übergabe besprechen, wenn der Kunde zustimmt und eine breitere Nachfrage in der Community besteht.
Fazit
Die meisten großen Magento-Erweiterungen haben entweder eine Anbieter- oder Community-Hyvä-Kompatibilität verfügbar, überprüfen Sie compat.hyva.io vor dem Scoping. Für den langen Schwanz von Erweiterungen ohne Kompatibilität kosten benutzerdefinierte Module zwischen £1.5k und £8k, abhängig von der Komplexität. Eine spezialisierte Hyvä-Agentur hat eine Bibliothek angesammelt, die bedeutet, dass die Arbeit an benutzerdefinierter Kompatibilität schneller und günstiger ist als von Grund auf neu zu beginnen.
Die Anzahl der Erweiterungen ist die größte Variable bei den Kosten der Hyvä-Migration. Stellen Sie sicher, dass das Inventar vor dem Scoping-Anruf korrekt ist.
Nächste Schritte
- Durchsuchen Sie compat.hyva.io für die aktuelle Liste der Anbieter-Kompatibilität
- Sehen Sie sich die Hyvä-Kompatibilitätsdienstleistungsseite an
- Sehen Sie sich den Glossareintrag zur Hyvä-Kompatibilitätsmodul für die technische Einführung an
- Lesen Sie Hyvä-Modulentwicklung: Wann benötigen Sie benutzerdefinierte Module
- Buchen Sie einen Scoping-Anruf, wir werden Ihre Erweiterungsliste prüfen und ein Angebot erstellen