Design & Hyvä Settings – Magento Manual

Theme Configuration

<div class="prose prose-hyva max-w-none">How to switch the active theme and make basic design settings in the backend.Set the active theme under Content > Design > Configuration — each store view can be assigned its own theme, useful if you want a different design for a specific market, for example. <h3>What else gets configured here</h3> <ul> <li>Applied Theme: select the active theme (e.g. the Mironsoft Hyvä theme on this project).</li> <li>Other Settings > Pagination: how many products are shown per page by default.</li> <li>Watermark: automatic watermarks on product images (a classic Luma feature, often unused with Hyvä themes).</li> <li>HTML Head: default meta tags, favicon and a default title, used as a fallback when an individual page hasn't set its own SEO fields.</li> </ul> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/applied12kategorie.png}}" alt="applied" /> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/pagination12kategorie.png}}" alt="pagination" /> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/html12kategorie.png}}" alt="html" /> <h3>What does NOT happen in the backend</h3> With a Hyvä theme like the one on this project, most of the actual design work does NOT happen in the backend — it lives in the theme code itself (Tailwind CSS, .phtml templates, Alpine.js components). The backend mainly controls WHICH theme is active and a few global behavior options, not the visual fine-tuning itself. Changes to colors, spacing, fonts or the overall page structure always require touching the theme code and a subsequent deploy (see the deploy sequence in the project documentation), not just a backend setting. <h3>Design configuration per category/product/CMS page</h3> In addition to the global theme setting, individual categories, products and CMS pages can select a different layout (e.g. no sidebar) under the "Design" tab of their respective form – this overrides the global setting only for that one page. <h3>Pagination and Sorting in Detail</h3> Under Content > Design > Configuration, in the Other Settings section, product list pagination can be controlled in more detail than just the default count: the Grid per Page Values field defines which values customers can choose from in grid view (e.g. "12,24,36"), while List per Page Values is the equivalent for list view. Default Grid per Page Value and Default List per Page Value determine which of these values is pre-selected on first load, and Default List Mode decides whether category pages start in grid or list view by default. Practical tip: The Allow All Products per Page field enables a "view all" option in pagination — for large categories with several hundred products, it's best left disabled, since a single page request would otherwise have to load and render a huge number of products at once. <h3>Search Engine Robots Settings</h3> The Search Engine Robots section, also found under Content > Design > Configuration, contains the Default Robots field, which controls the default meta robots value (e.g. "INDEX, FOLLOW" or "NOINDEX, NOFOLLOW") applied to all pages unless an individual page overrides it with its own robots settings. Edit custom instruction of robots.txt File lets you adjust the content of the delivered robots.txt directly in the backend, without uploading the file via FTP. Practical tip: On a staging or test environment, Default Robots should always be set to "NOINDEX, NOFOLLOW" so search engines don't index test content — forgetting to reset this setting after go-live is a common mistake. <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/robots12kategorie.png}}" alt="robots" /> <h3>Scheduling Design Changes</h3> Under Content > Design > Schedule, you can create time-limited design changes, for example a special layout for a campaign or a holiday. A new entry requires a Store View, a period defined by Date From and Date To, and either a different Custom Design (theme) or a Custom Layout Update XML that is only active during that period. Once the date range has passed, Magento automatically switches back to the regular configuration without anything needing to be reset manually — useful for seasonal promotions where nobody has to remember to revert the design the day after.</div>

Customizing Header and Footer

<div class="prose prose-hyva max-w-none">Customize logo, contact details and links in the header and footer from the backend, without writing code.Some header/footer content can be adjusted directly in the backend, no developer access required: <ul> <li>Logo: under Content > Design > Configuration, on the Header tab, upload a new logo and set its alt text and width/height.</li> <li>Copyright text in the footer: also via Content > Design > Configuration, on the Footer tab.</li> <li>Footer links and contact info: in many Hyvä themes (including this one) implemented as CMS blocks (see the "Using CMS Blocks" chapter) — editable directly in the backend, no deployment required.</li> </ul> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/header12kategorie.png}}" alt="header" /> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/footer12kategorie.png}}" alt="footer" /> Structural changes (e.g. new columns in the footer, a completely new header layout), on the other hand, require changes to the theme code itself and therefore a deploy — these aren't possible from the backend alone. But for anything that's plain text, an image, or a simple link, it's always worth checking first whether it's already editable as a CMS block or configuration field in the backend. <h3>Contact Details from Store Information</h3> Many Hyvä footer and header templates don't pull from a CMS block but read directly from the store's core data under Stores > Configuration > General > General, section Store Information — this is where you set the Store Name, Store Phone Number, Country and VAT Number. These fields are frequently used for schema.org markup (e.g. Organization or LocalBusiness data) and for phone number links in the header. <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/storeinformationen12kategorie.png}}" alt="store" /> Practical tip: If the phone number or address changes, it's worth checking not only Store Information but also the theme code or related CMS blocks, since some Hyvä themes hard-code these values in the footer template instead of pulling them from configuration. <h3>Store-View-Specific Adjustments (Scope)</h3> Logo, copyright text and many other design configuration fields can be set per scope: the store view switcher in the upper left of the respective configuration form lets you choose between Default Config, an individual website, or an individual store view. A value set at store view level overrides the website or default value above it only for that one store view — useful, for example, if a shop variant in a different language needs its own logo or footer text. Practical tip: A green checkmark next to a field indicates that a specific value has already been set for the current scope (not inherited) — clicking Use Default Value removes that override so the field falls back to the value from the parent scope again. <h3>Finding and Editing CMS Blocks for Footer and Header</h3> To find out which CMS block is responsible for a specific footer or header area, go to Content > Elements > Blocks and use the search by title or Block ID (identifier), for example searching for "footer" or "header". In the grid view, the Status column also shows whether a block is currently active (Enable Block = Yes) — a disabled block simply isn't rendered on the storefront, even if the template still references it. Practical tip: Not every visible footer or header area is necessarily a CMS block — some content is hard-coded in the .phtml template. If an area doesn't show up in the blocks overview, a code change by the development team is needed to make it backend-editable at all.</div>

Hyvä-Specific Settings

Which additional configuration options a Hyvä theme adds to the backend that Luma doesn't have.

Depending on which Hyvä modules are installed, Hyvä themes add their own configuration areas under Stores > Configuration, usually in a dedicated "Hyvä Themes" section:

Hyvä Theme (base module): settings for cookie consent behavior, image compression/lazy loading, and Content Security Policy (CSP), since Hyvä themes use a strict CSP by default.
Hyvä CSP: actively used on this project — every inline script included has to be explicitly registered via $hyvaCsp->registerInlineScript() in the code so the browser doesn't block it (a developer-side concern, not backend-configurable).
GraphQL caching: since Hyvä themes rely heavily on client-side GraphQL (e.g. for the cart), there are sometimes dedicated cache settings for GraphQL responses.

The most important conceptual difference from Luma: Hyvä does away with Knockout.js entirely and doesn't load jQuery — interactivity runs through Alpine.js instead. Among other things, that means classic Luma extensions built with Knockout components do NOT work with Hyvä without adaptation; when buying new extensions, look for explicit Hyvä compatibility.

Cookie Consent Management in Detail

The Hyvä cookie consent module lets you, under Stores > Configuration > Hyvä Themes, not only turn the consent banner on or off but also maintain several cookie categories (e.g. essential, functional, statistics and marketing cookies), each with its own texts. Scripts assigned to a non-essential category are only loaded on the storefront after the visitor has actively given consent — technically implemented through Alpine.js bindings that react to the stored consent state.

Practical tip: When embedding a new tracking or marketing script, it needs to be assigned to the right consent category and — because of the active CSP — registered as an allowed source (see the next section). Forgetting either step is a common reason a script suddenly fails to load on the storefront.

CSP: Maintaining Allowed Hosts for Third-Party Scripts

When embedding third-party services like Google Maps, Google Tag Manager, a chat widget provider, or payment scripts, the Content Security Policy that Hyvä enables by default blocks the call unless the respective domain is explicitly allowed. Under Stores > Configuration > Hyvä Themes > Hyvä CSP, additional allowed hosts can be entered per directive (including script-src, style-src, img-src, connect-src, and font-src).

Practical tip: Before pushing a new CSP rule to production, the report-only mode helps — it only logs violations instead of blocking them, so missing hosts can be identified without affecting customers with a broken script.

Compatibility with Classic Luma Extensions

For third-party extensions originally built for Luma with Knockout.js components that haven't been ported to Hyvä yet, a separate compatibility module exists that runs such components in isolation within a Hyvä page. It isn't a substitute for a native Hyvä integration but a stopgap solution that loads additional JavaScript (RequireJS/Knockout) — which works against the actual goal of a lean, jQuery-free frontend.

Practical tip: Before purchasing a new extension, always check whether a native Hyvä version exists before falling back on a compatibility module — the latter should remain the exception, not the rule, since it increases load time and CSP complexity again.