Extensies zonder Hyvä-compatibiliteitsmodule: je opties

Je hebt de extensie-audit gedaan en de meeste modules zijn in orde. Dan duiken er een of twee belangrijke op zonder enige Hyvä-compatibiliteitsmodule.

Dat is normaal, en zelden een reden om een Hyvä-project te stoppen. Dit artikel legt uit waarom het gebeurt en wat je eraan kunt doen.

Waarom sommige extensies niet werken op Hyvä

Een Magento-extensie bestaat meestal uit twee delen. Het backendgedeelte bevat PHP-logica, databasetabellen, admininstellingen en observers.

Het frontendgedeelte bevat templates, layout-XML, JavaScript en styling. Op Luma is die JavaScript meestal geschreven als RequireJS-modules, jQuery-widgets of Knockout-componenten.

Hyvä haalt die hele stack weg. Het backendgedeelte blijft dus werken, maar het frontendgedeelte heeft niets meer om op te draaien. Meer over de twee stacks lees je in hoe Alpine.js en Tailwind RequireJS en Knockout vervangen.

Een compatibiliteitsmodule dicht precies dat gat. Ze vervangt de frontend van de extensie door Alpine.js en Tailwind CSS, terwijl de oorspronkelijke backend blijft staan.

Hoe een compatibiliteitsmodule werkt

Een compatibiliteitsmodule is een kleine, aparte Magento-module. Ze verandert de code van de oorspronkelijke extensie niet, zodat die nog steeds via Composer kan worden bijgewerkt.

Hyvä biedt hiervoor een fallbackmechanisme. De compatibiliteitsmodule registreert zich als de Hyvä-versie van de oorspronkelijke module, en Hyvä zoekt templates dan eerst in de compatibiliteitsmodule.

<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>

Dit fragment hoort in de compatibiliteitsmodule, in etc/frontend/di.xml. In de module schrijf je vervolgens Hyvä-versies van de templates die dat nodig hebben, met Alpine.js in plaats van Knockout of jQuery.

Layout-XML kan ook de oorspronkelijke JavaScript verwijderen, zodat die nooit op een Hyvä-pagina laadt.

Optie 1: schrijf de compatibiliteitsmodule

Dit is de netste optie als de extensie belangrijk is en haar frontend middelgroot is.

• Je houdt de extensie, haar backendlogica en haar updatepad.
• Alleen het storefront-gedeelte wordt opnieuw gebouwd, in dezelfde stijl als de rest van het Hyvä-thema.
• Het resultaat is licht, omdat het de aanpak van Hyvä volgt in plaats van oude scripts te laden.

De inspanning hangt af van hoeveel JavaScript de oorspronkelijke frontend bevat. Een eenvoudige widget is een kleine klus. Een complexe productconfigurator of checkoutstap is een grotere.

Vraag de leverancier van de extensie, voordat je er zelf een schrijft, of er een Hyvä-versie gepland is. Veel leveranciers leveren die inmiddels zelf.

Optie 2: vervang de extensie

Soms is de beste compatibiliteitsmodule een andere extensie. Als een andere module hetzelfde doet en al Hyvä-klaar is, kan overstappen goedkoper en veiliger zijn dan porten.

Dit werkt goed voor veelvoorkomende functies zoals sliders, pop-ups, social login, productlabels of eenvoudige zoek-add-ons.

Controleer de datamigratie voordat je overstapt. Instellingen, content of klantgegevens van de ene module naar de andere verhuizen kan het verborgen deel van de klus zijn.

Optie 3: bouw alleen wat je gebruikt opnieuw

Grote extensies doen vaak veel meer dan een webshop daadwerkelijk gebruikt. Een webshop gebruikt misschien maar één widget uit een module vol functies.

In dat geval kan het zinvol zijn om alleen die ene functie rechtstreeks in het Hyvä-thema of als kleine maatwerkmodule te bouwen. Ons werk aan Magento-extensieontwikkeling begint vaak met precies deze vraag: welk deel heb je echt nodig?

Het resultaat is meestal lichter en makkelijker te onderhouden dan een volledige port.

Optie 4: houd een pagina voorlopig op Luma

De checkout is het klassieke voorbeeld. Een payment provider heeft misschien nog geen Hyvä-klare integratie, en een betaalmethode kwijtraken is geen optie.

Hyvä ondersteunt hiervoor een fallback-aanpak. Geselecteerde pagina's, meestal de checkout, blijven renderen met het Luma-thema, terwijl de rest van de webshop op Hyvä draait.

• Shoppers krijgen de snelheid van Hyvä op home-, categorie- en productpagina's.
• De checkout blijft precies werken zoals voorheen, met elke betaalmethode.
• Je kunt de checkout later naar Hyvä overzetten, zodra de integratie klaar is.

Dit is een praktische brug, geen eindsituatie. De Luma-checkout laadt nog steeds de oude stack, dus plan wanneer en hoe je die overzet.

Specifiek voor de checkout kun je Hyvä Checkout en andere checkoutroutes ook vergelijken in is Hyvä Checkout het waard?.

Optie 5: verwijder de extensie

Een audit vindt vaak extensies die niemand meer gebruikt. Sommige zijn geïnstalleerd voor een oude campagne, andere dupliceren functies die Magento nu standaard heeft.

Ze verwijderen is de makkelijkste port van allemaal. Bovendien wordt de webshop er lichter, veiliger en eenvoudiger te upgraden van.

Controleer voordat je een module verwijdert of ze geen data of instellingen bevat die je nog nodig hebt, en verwijder haar netjes via Composer in plaats van haar alleen uit te schakelen.

Hoe je kiest

Stel voor elke extensie zonder compatibiliteitsmodule vier vragen.

1. Heeft ze direct invloed op de verkoop, bijvoorbeeld in de checkout, winkelwagen of op productpagina's?
2. Hoeveel storefront-JavaScript bevat ze echt?
3. Is er een Hyvä-klaar alternatief dat hetzelfde doet?
4. Gebruik je alles, of maar een klein deel?

In de meeste echte projecten wordt een mix van alle vijf gebruikt. Het doel van de Hyvä-migratiechecklist is die beslissing één keer per module te nemen, voordat de bouw begint.

Veelgestelde vragen

Verandert een compatibiliteitsmodule de oorspronkelijke extensie?

Nee. Het is een aparte module die alleen de frontend-templates en -scripts vervangt. De oorspronkelijke extensie kan nog steeds gewoon worden bijgewerkt.

Kan ik niet gewoon RequireJS op Hyvä laden om een oude extensie werkend te krijgen?

In theorie kan dat, maar dan haal je het gewicht terug dat Hyvä weghaalt, en het gaat vaak op subtiele manieren mis. Een goede port of de Luma-fallback is veiliger.

Wat als de leverancier later een eigen Hyvä-versie uitbrengt?

Dan kun je overstappen op de versie van de leverancier en je eigen compatibiliteitsmodule uitfaseren. Doordat de port apart staat, is die overstap eenvoudig.

We maken bestaande modules Hyvä-klaar en bouwen zo nodig nieuwe. Bekijk onze Hyvä-themaontwikkeling diensten om je overstap te plannen.