Skip to content


Compilation from source: LESS file is empty: …/email-fonts.less

When running static content deploy the error occurs:

Compilation from source: LESS file is empty: frontend/Hyva/reset/xx_XX/css/email-fonts.less

This warning can be safely ignored, as it doesn’t cause the compilation to abort.

However, to properly resolve the issue, upgrade the module hyva-themes/magento2-email-module to release 1.0.4 or later.

“Incorrect CAPTCHA” error messages

Hyvä does not support the old legacy Magento Captcha or reCAPTCHA V1, as is documented in the Feature Matrix and in the Getting Started section.

Please disable the legacy Captcha, which unfortunately still is enabled by default:

bin/magento config:set customer/captcha/enable 0

Child theme throws exception "Overriding view file '...xml' does not match to any of the files."

This error occurs after creating and loading a child theme.

Exception #0 (LogicException): Overriding view file 'vendor/hyva-themes/magento2-reset-theme/.../layout/override/base/....xml' does not match to any of the files.

The exact path to the layout override XML file might vary.
If that happens, check the Hyva_Theme module is active.

bin/magento module:status Hyva_Theme

If the output is

Hyva_Theme : Module is disabled

then enable the module and run setup:upgrade.

bin/magento module:enable Hyva_Theme
bin/magento setup:upgrade

Visitors see the wrong store view and are unable to switch


This is a core Magento issue and not related to Hyvä.
However, since it can also occur with Hyvä, we have decided to add it to our documentations.

This happens for requests that have a store cookie set, but no X-Magento-Vary cookie, and the FPC record for the requested default store URL is expired. This might happen when a visitors' session times out after they select a non-default store view.

Varnish caches the page based on the X-Magento-Vary cookie, while Magento decides on which store view to render based on the store cookie.
For the default store view with the customer group guest neither cookie will be set.
This means, that when a request with the store cookie set to a non-default store view, has no X-Magento-Vary cookie set, the result will be cached in Varnish as the default store view page.

A possible fix is to adjust the default Varnish configuration. Instead of

sub vcl_hash {
    if (req.http.cookie ~ "X-Magento-Vary=") {
        hash_data(regsub(req.http.cookie, "^.*?X-Magento-Vary=([^;]+);*.*$", "\1"));

use the following:

sub vcl_hash {
    if (req.http.cookie ~ "X-Magento-Vary=") {
            hash_data(regsub(req.http.cookie, "^.*?X-Magento-Vary=([^;]+);*.*$", "\1"));
        } else {
            # If there is no 'X-Magento-Vary' cookie set, then there should also be no 'store' cookie
            # This check prevents requests with illegal cookie state from polluting the cache for default store view:
            if (req.http.cookie ~ "store=") {
                hash_data(regsub(req.http.cookie, "^.*?store=([^;]+);*.*$", "\1"));

(Thanks to Maximilian Fickers from to allow us to share their solution)