Shopware 6.7 verscheen eind 2024 met wat de officiële documentatie kwalificeert als “major release with multiple breaking changes”. Voor shops op 6.6 is de migratie op termijn verplicht: Shopware onderhoudt parallel alleen de laatste stabiele versie en de vorige, dus te lang op 6.5 of 6.6 blijven snijdt de toegang tot beveiligingscorrecties af. Voor plugins ontwikkeld op 6.6 zijn meerdere kritieke API’s tussen 6.6 en 6.7 van signatuur veranderd of verwijderd.
Dit artikel is een directe praktijkervaring van de migratie 6.6 → 6.7 die wij in 2025-2026 op meerdere shops hebben uitgevoerd, met de echte technische valkuilen die we tegenkwamen en de patches die we moesten produceren om onze eigen plugins en die van derden aan te passen. Het doel: andere teams de maand debugging besparen die wij aan bepaalde stille regressies hebben besteed.
Wat er werkelijk verandert in Shopware 6.7
Voorbij de release-marketing, dit zijn de 6.7-wijzigingen met concrete impact op bestaande plugins.
Herziening van de Payment Handler API. De interface AsynchronousPaymentHandlerInterface is in 6.7 verwijderd. Elke betaalplugin die deze interface in 6.6 implementeerde, moet migreren naar AbstractPaymentHandler. De methodes pay() en finalize() hebben een andere signatuur: de struct AsyncPaymentTransactionStruct is vervangen door PaymentTransactionStruct, minimalistischer en DDD-georiënteerd.
Gewijzigde servicetags. De tag shopware.payment.method.async die synchrone en asynchrone betalingen onderscheidde, is verwijderd ten gunste van een geünificeerde tag shopware.payment.method. Gebruikten uw services.xml de oude tag, dan declareert de payment handler zich niet meer correct en verdwijnt de betaalmethode uit de checkout zonder zichtbare fout.
Adminmigratie Vue 2 → Vue 3. De Shopware 6.7 admin is geporteerd naar Vue 3 (terwijl 6.6 op Vue 2 met compat layer zat). De sw-* componenten (legacy) worden vervangen door de mt-* componenten (Meteor design system). Veel sw-* componenten zijn deprecated gemarkeerd en zullen in een latere 6.x release verwijderd worden. Adminplugins die de sw-* componenten gebruikten, moeten migreren.
Gewijzigd adminvertaalsysteem. De methodes $tc() (translation choice, meervoudsbeheer) zijn vervangen door $t() met native meervoudsbeheer. Uw admintemplates die {{ $tc('mijn.plugin.label') }} deden, moeten overstappen naar {{ $t('mijn.plugin.label') }}.
Adminbuild via Vite. De admin compileert voortaan via Vite met een manifest.json die anders gestructureerd is dan in 6.6. Plugins die hun admin-JS via het historische mechanisme injecteerden, moeten hun buildpipeline aanpassen om het juiste manifest te genereren, anders laadt de admin een lege JS in plaats van uw code.
Storefront: Bootstrap 5.3 gegeneraliseerd. De overstap naar Bootstrap 5.3 in de storefront activeert de native ondersteuning van data-bs-theme, wat dark mode implementaties vereenvoudigt: onderwerp van onze plugin DataFirefly Dark Mode die deze conventie benut. Custom thema’s gebaseerd op Bootstrap 5.2 of ouder kunnen SCSS-variabelen hebben die niet meer mappen.
PHP- en MySQL-compatibiliteit. 6.7 vraagt PHP 8.2+ (PHP 8.1 eruit, PHP 8.3 aanbevolen) en MySQL 8.0+ of MariaDB 11.4 LTS. Hostings die nog op MySQL 5.7 of MariaDB 10.x zitten, moeten hun DB migreren vóór de applicatieve upgrade.
De breaking changes plugin per plugin die wij tegenkwamen
Op de shops die wij migreerden, dit zijn de concrete bugs ontdekt bij de upgrade 6.6 → 6.7.
MoptWorldline (betaling Worldline / SaferPay). De Worldline-betaalplugin in versie 6.6 implementeerde AsynchronousPaymentHandlerInterface. Bij de overgang naar 6.7 laadt de plugin niet meer correct en verdwijnen de Worldline-betaalmethodes uit de checkout. De patch vraagt migratie naar AbstractPaymentHandler en herschrijven van de methodes pay() en finalize() met de nieuwe PaymentTransactionStruct signatuur. Geschat werk: 2-4 dagen voor een ervaren Shopware-ontwikkelaar.
Custom adminplugins met sw-* componenten. Op onze eigen plugins gebruikten meerdere custom admincomponenten sw-card, sw-button, sw-text-field, enzovoort. In 6.7 bestaan deze componenten nog maar zijn ze deprecated gemarkeerd. De componenten mt-card, mt-button, mt-text-field vervangen ze. De migratie is mechanisch maar vraagt een exhaustieve review van alle adminbestanden.
Snippets en vertalingen. De snippetbestanden in 6.6 gebruikten soms de gepluraliseerde structuur die $tc() consumeerde. In 6.7 met $t() werken bepaalde snippetstructuren niet meer identiek. Systematisch testen, vooral op snippets met tellers (“1 product” / “N producten”).
Customer custom field en synchronisatie. Onze Dark Mode plugin voor Shopware slaat de gebruikersvoorkeur op in een custom field df_dark_mode_preference op de customer-entiteit. De 6.7-migratie behield de custom fields compatibiliteit, maar de synchronisatie-API heeft een licht andere signatuur. Systematisch testen na de upgrade.
OpenSearch 2.19+ verplicht. Gebruikt uw shop fulltext-zoeken met OpenSearch (ex-Elasticsearch in eerdere Shopware-versies), dan vraagt 6.7 minimaal OpenSearch 2.19. De OpenSearch 1.x versies worden niet meer ondersteund. OpenSearch-clustermigratie in te plannen vóór de applicatieve upgrade.
De migratiechecklist in 8 stappen
Voor een beheerste migratie 6.6 → 6.7, dit is de volgorde die wij intern volgen.
Stap 1 — Audit van de geïnstalleerde plugins. Lijst alle geactiveerde plugins op uw shop op. Controleer voor elk op de store of op GitHub of een 6.7-compatibele versie bestaat. Niet-bijgewerkte plugins zijn grote risico’s: tijdelijk uitschakelen, of intern patchen, of vervangen.
Stap 2 — Audit van het custom thema. Gebruikt u een custom thema (en niet het native Storefront-thema), controleer dan de compatibiliteit met Bootstrap 5.3, de wijzigingen in de base layout structuur, en het Vite-adminsysteem als uw thema custom admin-JS injecteert.
Stap 3 — Update van de infrastructuuromgeving. PHP 8.2+, MySQL 8 of MariaDB 11.4 LTS, OpenSearch 2.19+ indien gebruikt, recente Node.js (18+ of 20 LTS). Te doen vóór de applicatieve Shopware-upgrade.
Stap 4 — Complete backup. Database + files-map + config/ bestanden. De stap die men geneigd is te verwaarlozen tot het moment waarop de upgrade onherstelbaar iets breekt. Systematisch te doen vóór elke wijziging.
Stap 5 — Migratie op stagingomgeving. Kloon de productie naar een identieke staging, doe de 6.7-upgrade op de staging, valideer exhaustief voordat u de productie aanraakt. Geen optie: op de shops die wij migreerden had 30% kritieke bugs die uitsluitend in staging werden ontdekt.
Stap 6 — Applicatieve Shopware-upgrade. Via de SUM (Shopware Update Manager) in CLI: bin/console system:update:prepare, daarna bin/console system:update:finish. Lees de officiële documentatie goed voor de opties (skip-asset-build, enzovoort). Reken op 30 min tot 2 uur afhankelijk van de databasegrootte.
Stap 7 — Hercompilatie thema en admin. Na de core-upgrade het thema hercompileren (bin/console theme:compile) en de admin rebuilden (bin/build-administration.sh). Op Shopware 6.7 compileert de admin via Vite; het historische commando theme:compile volstaat niet meer voor de admin.
Stap 8 — Exhaustieve test na de upgrade. Volledig traject: catalogusnavigatie, productpagina, toevoegen aan winkelwagen, checkout, betaling (elke betaalmethode individueel getest), klantzone, admin (elke geïnstalleerde module). Op B2B-shops ook offertes, hiërarchische accounts en prijzen per klant testen.
De stille valkuilen die we werkelijk tegenkwamen
Voorbij de gedocumenteerde breaking changes, dit zijn de subtiele bugs die niet onmiddellijk zichtbaar zijn na de upgrade.
De payment handler die zich niet meer declareert. Zoals hierboven vermeld registreert een betaalplugin met de oude tag shopware.payment.method.async zich niet meer in 6.7. De betaalmethode verdwijnt uit de checkout, maar er wordt geen fout opgeworpen: het corresponderende payment_method_id bestaat nog in de database, alleen wordt de handler niet meer geïnstantieerd. Symptoom aan klantzijde: de methode wordt in de admin getoond (configuratie / sales channels / payment methods) maar verschijnt niet in de checkout.
Het custom admincomponent dat leeg rendert. Een component die $tc() gebruikte zonder gekoppelde vertaling (geval van hardcoded labels) rendert niets meer in 6.7. Geen fout in de console, gewoon een lege placeholder. Te detecteren via handmatige review van de custom adminschermen na de upgrade.
Het Vite-manifest dat niet gegenereerd wordt. Werd uw custom adminplugin in 6.6 gebuild met een aangepast script (webpack of directe rollup), dan kan die build het door Shopware 6.7 verwachte manifest.json niet genereren. Symptoom: de admin laadt maar uw plugin-JS wordt niet uitgevoerd. Oplossing: de build aanpassen om een Vite-compatibel manifest te exporteren.
De gepluraliseerde snippets die niet meer vertalen. Had u snippets met structuur {count} | één ding | {count} dingen geconsumeerd door $tc(), dan vraagt de overstap naar $t() een andere syntax. Niet-gemigreerde snippets tonen de ruwe templatestring in plaats van de vertaling.
Het custom field dat niet meer bestaat in de API. Enkele wijzigingen aan de DAL-API (Data Abstraction Layer) in 6.7 hebben de serialisatie van bepaalde complexe custom fields (multi-select, JSON) veranderd. De waarden in de database bestaan nog, maar worden anders gelezen. Te testen op de kritieke custom fields.
Conclusie: een noodzakelijke migratie, maar te anticiperen
De migratie Shopware 6.6 → 6.7 is geen simpele minor update. Ze introduceert significante breaking changes die echt werk vragen aan de plugins (betaling met name), de custom admin en de infrastructuur. Shops die deze migratie in 1 dag doen “omdat we gewoon op Update hebben geklikt”, ontdekken de bugs weken later in productie, soms met directe impact op de omzet (kapotte betaling, onbruikbare admin).
De realistische tijdsinvestering voor een shop met 5-10 plugins van derden en een custom thema is 5 tot 15 mandagen voor een ervaren Shopware-ontwikkelaar, plus enkele dagen acceptatietests. Het onderwerp anticiperen, de upgrade in staging doen, exhaustief testen vóór de productie: dat onderscheidt een beheerste migratie van een migratie in crisis.
Voor de aanverwante technische onderwerpen: blader door onze categorieën E-commerce nieuws en Prestaties & Core Web Vitals. En zoekt u goed onderhouden, performance-first Shopware 6.7 plugins: onze Dark Mode plugin is vanaf de release compatibel met Shopware 6.7 en illustreert de technische patterns uitgelijnd op de nieuwe architectuur (anti-FOUC, customer custom field, JS-events voor synchronisatie met derden).
Lees ook: de checklist migratie PrestaShop 1.7 naar 8 en PrestaShop 9 vs PrestaShop 8.
