Hyvä bug, inspected & fixed

Every project gets a fixed written quote. Send a short brief on WhatsApp and I reply within one working day with scope, price and timeline.

Most single Hyvä front-end bugs are a Quick Fix. A batch of bugs or one deep root-cause hunt, like post-upgrade breakage or a checkout regression, is a Bug-Fix Sprint. Emergency or on-call cover is custom, and a full stabilization sprint is available for stores that need hardening. You always see the hours basis before any work starts.

Emergency triage starts during my working hours (10 AM to 7 PM IST, Monday to Saturday); most well-defined bugs are fixed in 24-48 hours. Hyvä front-end bugs are usually fast to root-cause because the stack is transparent, no RequireJS bundling to untangle. Once we reproduce it on staging with devtools open, the cause (purged class, dead Alpine component, resolver mismatch) is normally clear within hours.

A Hyvä x-data / x-init component goes dead for a few common reasons: (1) a JavaScript error earlier on the page halts Alpine before it reaches your component, (2) the component’s function is registered after alpine:init has already fired, or (3) a non-Hyvä extension injected a script that throws. We open the console, find the throwing line, and either reorder the registration or fix the upstream error. Typical symptom: Alpine Expression Error: x is not defined.

It was purged. Tailwind only keeps classes it can find by scanning the files listed in your tailwind.config.js content array. If a class is built dynamically in PHP, lives in a PHTML the scanner doesn’t cover, or is concatenated from strings, Tailwind never sees it and strips it from the production bundle. The fix is to add the path to content, safelist the class, or rebuild the class statically, then rebuild Tailwind. We catch these by diffing the DOM classes against the compiled app.css.

Yes. Hyvä compiles Tailwind into a static CSS bundle, editing a PHTML or adding a new utility class does nothing on the frontend until you run the Tailwind build (npm run build-prod in the theme’s web/tailwind folder) and re-deploy static content. If you forget the rebuild, the page looks unchanged even though the markup updated. Every fix we ship includes the Tailwind rebuild plus the right cache clear so you don’t hit a stale bundle.

Yes. That happens when a Luma-only extension injects RequireJS markup into a Hyvä page that doesn’t load RequireJS, so its require([...]) call throws Uncaught ReferenceError: require is not defined and the feature renders blank. The fix is one of: install the vendor’s Hyvä compatibility module, write a small compat bridge that re-implements the widget in Alpine, or disable the Luma frontend output and replace it with a Hyvä-native equivalent. We’ll tell you which is cheapest in your case.

Yes, Hyvä Checkout is one of our most-requested fixes. Custom steps, payment-method renderers and magewire components break for predictable reasons: a stale magewire snapshot (component snapshot checksum mismatch), a hydration mismatch between server and client state, or a renderer that never mounted because of a config typo. We reproduce the failing flow on staging, trace the magewire lifecycle, and fix the component without disturbing the rest of the checkout. See our Magento checkout bug fixing page for non-Hyvä checkout work.

Usually, yes. Hyvä components fetch price, stock and cart data over GraphQL, so a missing value almost always means the GraphQL response carries an error or returns null, GraphQL response contains errors: Cannot query field. Common causes: a custom resolver throwing, a schema field renamed after an upgrade, a missing @cache / @resolver directive, or full-page cache serving stale GraphQL. We inspect the network tab, replay the query, and fix the resolver or schema so the data renders again.

Yes, this is a frequent ask. After bumping hyva-themes/magento2-*, a compat module, or Magento itself, templates can 500 or render twice (Unable to resolve the source file for hyva_default). The cause is usually a theme override that drifted from the new parent template, two compat modules now registering the same block, or a renamed Hyvä layout handle. We diff your overrides against the new Hyvä version, re-base only what changed, and add a check so the next upgrade is cleaner. See also our Magento upgrade bug fixing service.

Staging first, always. Every fix is reproduced and applied on a staging or local copy, regression-checked, and only then deployed to live and verified. If you don’t have a staging environment we’ll help you spin one up, or for true emergencies we’ll work carefully on live with a backup taken first. We never push an untested change straight to a production storefront.

Yes. We work on a staging copy, ship the minimal correct fix rather than a sweeping refactor, add a regression check so the bug can’t silently come back, and clear only the caches that need clearing. You get to review the change on staging and sign off before anything reaches production. Because Hyvä is a transparent Tailwind + Alpine stack, fixes are usually small and surgical, not risky theme-wide rewrites.

Yes. If the exact bug we fixed comes back within 14 days, we fix it again at no charge. Every fix ships with a regression check specifically so it can’t silently regress on your next deploy. If the original diagnosis turns out to be wrong, you don’t pay for the wrong fix, only for solving the real root cause. For ongoing peace of mind, an emergency retainer keeps a front-end engineer on call.