Extensions without a Hyvä compatibility module: your options

You have done the extension audit and most modules are fine. Then one or two important ones show up with no Hyvä compatibility module at all.

This is normal, and it is rarely a reason to stop a Hyvä project. This post explains why it happens and what you can do about it.

Why some extensions do not work on Hyvä

A Magento extension usually has two parts. The backend part contains PHP logic, database tables, admin settings and observers.

The frontend part contains templates, layout XML, JavaScript and styles. On Luma, that JavaScript is usually written as RequireJS modules, jQuery widgets or Knockout components.

Hyvä removes that whole stack. So the backend part keeps working, but the frontend part has nothing to run on. You can read more about the two stacks in how Alpine.js and Tailwind replace RequireJS and Knockout.

A compatibility module fixes exactly this gap. It replaces the extension’s frontend with Alpine.js and Tailwind CSS, while the original backend stays in place.

How a compatibility module works

A compatibility module is a small, separate Magento module. It does not change the original extension’s code, so the original can still be updated through Composer.

Hyvä provides a fallback mechanism for this. The compatibility module registers itself as the Hyvä version of the original module, and Hyvä then looks for templates in the compatibility module first.

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

This snippet goes in the compatibility module’s etc/frontend/di.xml. Inside the module, you then write Hyvä versions of the templates that need them, using Alpine.js instead of Knockout or jQuery.

Layout XML can also remove the original JavaScript, so it never loads on a Hyvä page.

Option 1: write the compatibility module

This is the cleanest option when the extension is important and its frontend is moderate in size.

• You keep the extension, its backend logic and its update path.
• Only the storefront part is rebuilt, in the same style as the rest of the Hyvä theme.
• The result is light, because it follows Hyvä’s approach instead of loading old scripts.

The effort depends on how much JavaScript the original frontend contains. A simple widget is a small job. A complex product configurator or checkout step is a larger one.

Before writing one yourself, ask the extension vendor whether a Hyvä version is planned. Many vendors now ship their own.

Option 2: replace the extension

Sometimes the best compatibility module is a different extension. If another module does the same job and is already Hyvä-ready, switching can be cheaper and safer than porting.

This works well for common features such as sliders, pop-ups, social login, product labels or simple search add-ons.

Check data migration before you switch. Moving settings, content or customer data from one module to another can be the hidden part of the job.

Option 3: rebuild only what you use

Large extensions often do far more than a store actually uses. A store might use one widget out of a feature-rich module.

In that case, it can make sense to build just that one feature directly in the Hyvä theme or as a small custom module. Our Magento extension development work often starts with exactly this question: which part do you really need?

The result is usually lighter and easier to maintain than a full port.

Option 4: keep a page on Luma for now

Checkout is the classic case. A payment provider may have no Hyvä-ready integration yet, and losing a payment method is not acceptable.

Hyvä supports a fallback approach for this. Selected pages, most often the checkout, keep rendering with the Luma theme, while the rest of the store runs on Hyvä.

• Shoppers get Hyvä speed on home, category and product pages.
• Checkout keeps working exactly as before, with every payment method.
• You can move checkout to Hyvä later, when the integration is ready.

This is a practical bridge, not a final state. The Luma checkout still loads the old stack, so plan when and how you will move it.

For checkout specifically, you can also compare Hyvä Checkout and other checkout routes in is Hyvä Checkout worth it?.

Option 5: remove it

An audit often finds extensions that nobody uses any more. Some were installed for a past campaign, and some duplicate features that Magento now has built in.

Removing them is the easiest port of all. It also makes the store lighter, safer and simpler to upgrade.

Before removing a module, check that it has no data or settings you still need, and remove it properly through Composer rather than only disabling it.

How to choose

For each extension without a compatibility module, ask four questions.

1. Does it affect sales directly, for example in checkout, cart or product pages?
2. How much storefront JavaScript does it really have?
3. Is there a Hyvä-ready alternative that does the same job?
4. Do you use all of it, or only a small part?

Most real projects use a mix of all five. The point of the Hyvä migration checklist is to make that decision once, per module, before the build starts.

FAQ

Does a compatibility module change the original extension?

No. It is a separate module that replaces only the frontend templates and scripts. The original extension can still be updated as usual.

Can I just load RequireJS on Hyvä to make an old extension work?

It is possible in theory, but it brings back the weight Hyvä removes and often breaks in subtle ways. A proper port or the Luma fallback is safer.

What if the vendor releases its own Hyvä version later?

Then you can switch to the vendor’s version and retire your own compatibility module. Keeping the port separate makes that switch simple.

We make existing modules Hyvä-ready and build new ones when needed. See our Hyvä theme development services to plan your move.