Hyvä onderhoud: je theme veilig up-to-date houden

Hyvä onderhoud: je theme veilig up-to-date houden

Hyvä brengt gemiddeld elke twee weken een nieuwe release uit. Wie een jaar niet update, loopt 25+ versies achter. Dan is een update geen patch meer, maar een migratieproject.

Dat is het echte risico van Hyvä-onderhoud. Niet de updates zelf, maar het uitstellen ervan. Een theme dat netjes wordt bijgehouden, update je in een paar uur. Een theme dat achterstallig is, kost dagen en breekt op plekken die je niet ziet aankomen.

Wij beheren tientallen Hyvä-shops. De shops met een vast updateritme hebben de minste incidenten. De shops die "wel zien wanneer het nodig is" hebben de duurste incidenten. Dit artikel laat zien hoe je in de eerste categorie blijft.

Waarom Hyvä-updates anders werken dan Luma

Luma was traag, maar stabiel in onderhoud. Je deed één keer per jaar een grote Magento-upgrade en daar bleef het bij. Hyvä werkt andersom: kleine, frequente releases.

Dat heeft een reden. Hyvä is een actief ontwikkeld product met een team dat snel itereert. Nieuwe componenten, performance-fixes, accessibility-verbeteringen en compatibiliteit met nieuwe Magento-versies komen continu binnen.

De keerzijde: je moet meebewegen. Een Hyvä-theme is geen "set and forget"-product. Wie van Luma naar Hyvä migreert ruilt eenmalige grote pijn in voor frequent klein onderhoud. Dat is een betere deal, maar alleen als je het onderhoud ook daadwerkelijk doet.

Concreet betekent dit:

• Theme-updates los van Magento-updates (eigen changelog, eigen cadans).
• Module-updates voor hyva-themes/magento2- packages via Composer.
• Compat-modules wanneer je Luma-extensies inbouwt onder Hyvä.

Die compat-modules verdienen extra aandacht. Veel shops draaien third-party-extensies die oorspronkelijk voor Luma zijn gebouwd. Onder Hyvä gebruik je daarvoor hyva-themes/magento2--compat-packages of een eigen compat-laag. Die packages hebben hun eigen updateritme én hun eigen breaking changes. Vergeet je ze, dan breekt een extensie terwijl je Hyvä-core netjes bij is.

Versiebeleid: kies een ritme en houd je eraan

Hyvä volgt semantic versioning. De versienummers vertellen je hoeveel risico een update meebrengt.

Ons advies aan klanten: update minor-versies elk kwartaal, patches maandelijks. Zo blijf je nooit meer dan drie maanden achter. De update blijft klein en de risico's overzichtelijk.

Wacht je langer? Dan stapelen breaking changes op. Een update over acht versies betekent acht changelogs doorlezen, acht keer mogelijke conflicten in je overrides en geen helder beeld meer van wat er precies brak.

Leg het ritme vast. Zet een terugkerende afspraak in de agenda, niet "als we tijd hebben". Onderhoud dat van toeval afhangt, gebeurt niet.

Bescherm je overrides: nooit core editen

Dit is de belangrijkste regel van duurzaam Hyvä-onderhoud. Pas nooit de Hyvä-core aan. Elke directe wijziging in het Hyvä-vendor-package verdwijnt bij de eerste de beste composer update.

Hyvä is gebouwd op het Magento theme-fallback-systeem. Je maakt een eigen theme dat van Hyvä erft. Alles wat je wilt aanpassen, override je in je eigen theme. De core blijft schoon.

Een typische structuur:

app/design/frontend/Coding/default/
├── theme.xml          # parent: Hyva/default
├── web/tailwind/      # eigen Tailwind config
├── Magento_Theme/     # overrides van core-templates
└── ...

In theme.xml wijs je Hyvä aan als parent:

<theme xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <title>Coding Default</title>
    <parent>Hyva/default</parent>
</theme>

Hierdoor pakt Magento eerst jouw template, en valt terug op Hyvä als jij niets overschrijft. Update je Hyvä, dan krijg je automatisch alle core-verbeteringen binnen, terwijl jouw aanpassingen blijven staan.

De valkuil: te veel overriden. Elk template dat je kopieert naar je child theme, moet je bij elke update opnieuw controleren. Want als Hyvä de originele template wijzigt, mist jouw kopie die wijziging.

Daarom de stelregel: override zo min mogelijk, zo gericht mogelijk. Kun je iets oplossen met Tailwind-classes of een kleine config in plaats van een hele template te kopiëren? Doe dat. Minder overrides betekent minder onderhoud. Lees meer over deze aanpak in onze gids over Hyvä installeren op een bestaande Magento-shop.

Changelog volgen: weet wat er verandert voordat je update

Hyvä publiceert per release een changelog. Lezen voor je update is geen optie, het is de hele voorbereiding.

Waar je op let:

• Breaking changes — gemarkeerd in de release notes. Hier zitten de problemen.
• Gewijzigde templates — vergelijk met je eigen overrides. Wat heb je gekopieerd dat nu verandert?
• Tailwind-wijzigingen — nieuwe versies van Tailwind in een Hyvä-release kunnen je classes raken.
• Verwijderde of hernoemde componenten — Alpine.js-componenten en x-data-structuren wijzigen soms.

Praktisch maken wij voor elke shop een lijst van overschreven bestanden. Bij een update draaien we een diff tussen de oude en nieuwe Hyvä-versie, gefilterd op precies die bestanden. Zo zien we in minuten of een override aandacht nodig heeft.

# Diff tussen twee Hyvä-versies, beperkt tot je overrides
diff -r vendor/hyva-themes/magento2-default-theme-old \
        vendor/hyva-themes/magento2-default-theme-new \
        | grep -E "$(jouw_override_paden)"

Geen changelog gelezen? Dan update je blind. En blind updaten op productie is hoe shops op vrijdagmiddag offline gaan.

Testen: nooit direct op productie

Een Hyvä-update raakt de frontend. Frontend-bugs zie je niet in logs, je ziet ze in de browser. Daarom is visueel testen niet optioneel.

Onze testvolgorde:

1. Lokaal of staging — update eerst in een omgeving die productie spiegelt.
2. composer update + recompile — setup:upgrade, setup:di:compile, setup:static-content:deploy.
3. Tailwind rebuild — npm run build in de theme-directory.
4. Kritieke flows handmatig — homepage, categorie, product, cart, checkout.
5. Console-check — JavaScript-errors van Alpine.js verschijnen alleen in de browserconsole.

Let extra op de checkout. Dat is de plek waar een gebroken Alpine-component direct omzet kost. Een knop die niet meer reageert op mobiel zie je niet in een logfile, wel in je conversiecijfers.

Voor shops met veel maatwerk voegen we visuele regressietests toe. Screenshots van voor en na, automatisch vergeleken. Dat vangt subtiele layout-shifts die je bij handmatig klikken mist.

Pas na een schone test gaat de update naar productie. Bij voorkeur niet op vrijdag.

Houd ook altijd een rollback-plan klaar. In de praktijk betekent dat: een database-backup voor de deploy, je composer.lock onder versiebeheer, en de mogelijkheid om in één commando terug te schakelen naar de vorige Hyvä-versie. Een update zonder uitweg is geen update, het is een gok. Als de checkout op productie tóch hapert, wil je binnen minuten terug zijn op de oude versie en niet onder druk gaan debuggen terwijl klanten afhaken.

Wat achterstallig onderhoud echt kost

"We updaten wel als het nodig is" is de duurste strategie. Hier is waarom.

Een rekenvoorbeeld uit de praktijk. Een kwartaalupdate kost ons doorgaans 2 tot 4 uur. Een shop die anderhalf jaar niet is bijgewerkt: 3 tot 5 volle dagen, plus regressietesten, plus het risico op spoedwerk als iets breekt. De goedkope route is de saaie route: klein en vaak.

Reken het door over een jaar. Vier kwartaalupdates kosten samen ruwweg 12 tot 16 uur, gespreid en planbaar. Eén grote inhaalslag na anderhalf jaar verwaarlozing kost al snel 30 tot 40 uur, ongepland, vaak met spoed en onder stress. Dezelfde shop, een veelvoud aan kosten — alleen omdat het onderhoud is uitgesteld. Daar komen de indirecte kosten nog bovenop: omzetverlies bij een gebroken checkout, gemiste Magento security-patches en developers die uren kwijt zijn aan het reconstrueren van waarom een override bestaat.

Hoe wij Hyvä-onderhoud aanpakken

Wij behandelen Hyvä-onderhoud als doorlopend proces, niet als incident. Concreet:

• Vast updateritme per shop, vastgelegd en ingepland.
• Override-inventaris zodat we bij elke release precies weten wat aandacht nodig heeft.
• Staging-first met handmatige en visuele tests voor productie.
• Senior developers die de Hyvä-changelog en het Hyvä-ecosysteem kennen — geen ticket dat door een juniortrechter gaat.

Wij zijn Hyvä Certified en bouwen al jaren op het platform. Dat betekent dat we breaking changes vaak al kennen voordat ze jouw shop raken.

Wil je weten hoeveel versies jouw theme achterloopt en wat een inhaalslag kost? Neem contact op — we doen een gratis check op je huidige Hyvä-versie en je overrides, en geven een concreet onderhoudsplan.

Veelgestelde vragen

Hoe vaak moet ik mijn Hyvä-theme updaten?

Patches maandelijks, minor-versies per kwartaal. Zo loop je nooit meer dan drie maanden achter en blijft elke update klein en goedkoop. Major-versies plan je apart in als migratieproject, want die bevatten breaking changes.

Verlies ik mijn maatwerk als ik Hyvä update?

Niet als je theme correct is opgezet. Al je aanpassingen horen in een eigen child theme dat van Hyvä erft via het theme-fallback-systeem. De Hyvä-core blijf je nooit direct aanpassen. Update je dan, blijven je overrides staan en krijg je alle core-verbeteringen erbij.

Kan ik een Hyvä-update direct op productie draaien?

Doe dat niet. Een Hyvä-update raakt de frontend, en frontend-bugs zie je niet in logs maar in de browser. Test eerst op staging, controleer de kritieke flows (vooral checkout) en kijk de browserconsole na op Alpine.js-errors. Pas daarna naar productie.

Wat gebeurt er als ik lang niet update?

De risico's stapelen. Twintig versies achterlopen is geen twintig kleine updates maar één grote, onvoorspelbare sprong. Bovendien blokkeert een verouderd theme vaak je Magento security-patches. Een kwartaalupdate kost een paar uur; een anderhalf jaar oude achterstand al snel meerdere dagen.

Hoe weet ik welke versie ik nu draai?

Check je composer.lock of draai composer show hyva-themes/magento2-default-theme. Vergelijk dat met de laatste release in de officiële Hyvä-changelog. Wil je een complete check inclusief je overrides en een onderhoudsplan? Dat doen wij gratis.