Shopware 6.7 è uscita a fine 2024 con quella che la documentazione ufficiale qualifica come « major release with multiple breaking changes ». Per i negozi in 6.6, la migrazione è obbligatoria a termine — Shopware mantiene in parallelo solo l’ultima versione stabile e quella precedente, quindi restare su 6.5 o 6.6 troppo a lungo taglia l’accesso alle patch di sicurezza. Per i plugin sviluppati in 6.6, diverse API critiche hanno cambiato firma o sono state rimosse tra 6.6 e 6.7.
Questo articolo è un feedback diretto sulla migrazione 6.6 → 6.7 che abbiamo condotto su diversi negozi nel 2025-2026, con le vere insidie tecniche incontrate e le patch che abbiamo dovuto produrre per adattare i nostri plugin proprietari e di terze parti. L’obiettivo: evitare ad altri team il mese di debugging che abbiamo passato su alcune regressioni silenziose.
Ciò che cambia veramente in Shopware 6.7
Al di là del marketing release, ecco i cambiamenti 6.7 che hanno un impatto concreto sui plugin esistenti.
Refactor dell’API Payment Handler. L’interfaccia AsynchronousPaymentHandlerInterface è rimossa in 6.7. Tutti i plugin di pagamento che implementavano questa interfaccia in 6.6 devono migrare verso AbstractPaymentHandler. I metodi pay() e finalize() hanno una firma diversa: la struct AsyncPaymentTransactionStruct è sostituita da PaymentTransactionStruct, più minimalista e orientata DDD.
Tag di servizio modificati. Il tag shopware.payment.method.async che distingueva i pagamenti sincroni e asincroni è rimosso a favore di un tag unificato shopware.payment.method. Se i tuoi services.xml usavano il vecchio tag, il payment handler non si dichiara più correttamente e il metodo di pagamento sparisce dal checkout senza errore visibile.
Migrazione admin Vue 2 → Vue 3. L’admin di Shopware 6.7 è portato su Vue 3 (mentre la 6.6 era su Vue 2 con compat layer). I componenti sw-* (legacy) sono in corso di sostituzione con i componenti mt-* (Meteor design system). Molti componenti sw-* sono marcati come deprecated e saranno rimossi in una release 6.x successiva. I plugin admin che usavano i componenti sw-* devono migrare.
Sistema di traduzione admin modificato. I metodi $tc() (translation choice, gestione del plurale) sono stati sostituiti da $t() con gestione nativa del plurale. I tuoi template admin che facevano {{ $tc('mio.plugin.label') }} devono passare a {{ $t('mio.plugin.label') }}.
Build admin via Vite. L’admin ora compila via Vite con un manifest.json strutturato diversamente rispetto alla 6.6. I plugin che iniettavano il loro JS admin tramite il meccanismo storico devono adattare la loro build pipeline per generare il manifest corretto, altrimenti l’admin carica un JS vuoto invece del tuo codice.
Storefront: Bootstrap 5.3 generalizzato. Il passaggio a Bootstrap 5.3 nello storefront attiva il supporto nativo di data-bs-theme, il che semplifica le implementazioni di modalità scura — argomento del nostro plugin DataFirefly Dark Mode che sfrutta questa convenzione. I temi custom basati su Bootstrap 5.2 o anteriori possono avere variabili SCSS che non si mappano più.
Compatibilità PHP e MySQL. La 6.7 richiede PHP 8.2+ (PHP 8.1 fuori, PHP 8.3 raccomandato) e MySQL 8.0+ o MariaDB 11.4 LTS. Gli hosting ancora in MySQL 5.7 o MariaDB 10.x devono migrare il loro DB prima dell’upgrade applicativo.
I breaking change plugin per plugin che abbiamo incontrato
Sui negozi che abbiamo migrato, ecco i bug concreti scoperti all’upgrade 6.6 → 6.7.
MoptWorldline (pagamento Worldline / SaferPay). Il plugin di pagamento Worldline in versione 6.6 implementava AsynchronousPaymentHandlerInterface. Al passaggio 6.7, il plugin non si carica più correttamente e i metodi di pagamento Worldline spariscono dal checkout. La patch richiede di migrare verso AbstractPaymentHandler e riscrivere i metodi pay() e finalize() con la nuova firma PaymentTransactionStruct. Lavoro stimato: 2-4 giorni per uno sviluppatore Shopware esperto.
Plugin admin custom con componenti sw-*. Sui nostri plugin MySmartBook e altri, diversi componenti admin custom usavano sw-card, sw-button, sw-text-field, ecc. In 6.7, questi componenti esistono ancora ma sono marcati deprecated. I componenti mt-card, mt-button, mt-text-field li sostituiscono. La migrazione è meccanica ma richiede una revisione esaustiva di tutti i file admin.
Snippet e traduzioni. I file di snippet in 6.6 usavano talvolta la struttura pluralizzata che $tc() consumava. In 6.7 con $t(), alcune strutture di snippet non funzionano più in modo identico. Da testare sistematicamente, soprattutto sugli snippet con contatori (« 1 prodotto » / « N prodotti »).
Custom field customer e sincronizzazione. Il nostro plugin Dark Mode per Shopware memorizza la preferenza utente in un custom field df_dark_mode_preference sull’entità customer. La migrazione 6.7 ha preservato la compatibilità dei custom field, ma l’API di sincronizzazione ha una firma leggermente diversa. Da testare sistematicamente dopo l’upgrade.
OpenSearch 2.19+ obbligatorio. Se il tuo negozio usa la ricerca fulltext con OpenSearch (ex-Elasticsearch nelle versioni Shopware precedenti), la 6.7 richiede OpenSearch 2.19 minimo. Le versioni OpenSearch 1.x non sono più supportate. Migrazione del cluster OpenSearch da prevedere prima dell’upgrade applicativo.
La checklist di migrazione in 8 fasi
Per una migrazione 6.6 → 6.7 controllata, ecco l’ordine che seguiamo internamente.
Fase 1 — Audit dei plugin installati. Elenca tutti i plugin attivi sul tuo negozio. Per ciascuno, verifica sullo store o su GitHub se esiste una versione compatibile 6.7. I plugin non aggiornati sono rischi maggiori: da disattivare temporaneamente, o patchare internamente, o sostituire.
Fase 2 — Audit del tema custom. Se usi un tema custom (e non il tema Storefront nativo), verifica la compatibilità con Bootstrap 5.3, i cambiamenti di struttura base layout, e il sistema Vite admin se il tuo tema inietta JS admin custom.
Fase 3 — Aggiornamento ambiente infrastruttura. PHP 8.2+, MySQL 8 o MariaDB 11.4 LTS, OpenSearch 2.19+ se utilizzato, Node.js recente (18+ o 20 LTS). Da fare prima dell’upgrade applicativo Shopware.
Fase 4 — Backup completo. Database + cartella files + file config/. È la fase che si tende a trascurare fino al momento in cui l’upgrade rompe irrimediabilmente qualcosa. Da fare sistematicamente prima di qualsiasi cambiamento.
Fase 5 — Migrazione su ambiente di staging. Clonare la prod su uno staging identico, fare l’upgrade 6.7 sullo staging, validare esaustivamente prima di toccare la prod. Non è un’opzione — sui negozi che abbiamo migrato, il 30% ha avuto bug critici scoperti unicamente in staging.
Fase 6 — Upgrade applicativo Shopware. Tramite il SUM (Shopware Update Manager) in CLI: bin/console system:update:prepare, poi bin/console system:update:finish. Leggere bene la documentazione ufficiale per le opzioni (skip-asset-build, ecc.). Contare 30 min a 2 h a seconda della dimensione del database.
Fase 7 — Ricompilazione tema e admin. Dopo l’upgrade core, ricompilare il tema (bin/console theme:compile) e fare rebuild dell’admin (bin/build-administration.sh). Su Shopware 6.7, l’admin si compila via Vite; il comando storico theme:compile non basta più per l’admin.
Fase 8 — Test esaustivo post-upgrade. Percorso completo: navigazione catalogo, scheda prodotto, aggiunta al carrello, checkout, pagamento (ogni metodo di pagamento testato individualmente), area cliente, admin (ogni modulo installato). Sui negozi B2B, testare anche preventivi, account gerarchici, prezzi per cliente.
Le insidie silenziose che abbiamo incontrato dal vivo
Al di là dei breaking change documentati, ecco i bug sottili che non si vedono immediatamente dopo l’upgrade.
Il payment handler che non si dichiara più. Come accennato sopra, un plugin di pagamento con vecchio tag shopware.payment.method.async non si registra più in 6.7. Il metodo di pagamento sparisce dal checkout, ma nessun errore viene sollevato — il payment_method_id corrispondente esiste ancora in DB, semplicemente l’handler non viene più istanziato. Sintomo lato cliente: il metodo viene visualizzato nell’admin (configurazione / sales channel / payment method) ma non appare al checkout.
Il componente admin custom che renderizza vuoto. Un componente che usava $tc() senza alcuna translation associata (caso delle label hardcoded) non renderizza più nulla in 6.7. Nessun errore nella console, semplicemente un placeholder vuoto. Da rilevare con revisione manuale degli schermi admin custom dopo l’upgrade.
Il manifest Vite che non si genera. Se il tuo plugin admin custom era buildato con uno script personalizzato in 6.6 (webpack o rollup diretto), questo build potrebbe non generare il manifest.json atteso da Shopware 6.7. Sintomo: l’admin carica ma il tuo JS plugin non viene eseguito. Soluzione: adattare il build per esportare un manifest compatibile Vite.
Gli snippet pluralizzati che non si traducono più. Se avevi snippet con struttura {count} | una cosa | {count} cose consumati da $tc(), il passaggio a $t() richiede una sintassi diversa. Gli snippet non migrati visualizzano la stringa template grezza invece della traduzione.
Il custom field che non esiste più in API. Alcune modifiche dell’API DAL (Data Abstraction Layer) in 6.7 hanno cambiato la serializzazione di alcuni custom field complessi (multi-select, JSON). I valori in DB esistono ancora, ma vengono letti diversamente. Da testare sui custom field critici.
Conclusione: una migrazione necessaria ma da anticipare
La migrazione Shopware 6.6 → 6.7 non è un semplice update minore. Introduce breaking change significativi che richiedono lavoro reale sui plugin (pagamento in particolare), sull’admin custom e sull’infrastruttura. I negozi che fanno questa migrazione in 1 giornata « perché abbiamo solo cliccato su Update » scoprono i bug in produzione settimane più tardi, talvolta con impatto diretto sul fatturato (pagamento rotto, admin inutilizzabile).
L’investimento di tempo realistico per un negozio con 5-10 plugin di terze parti e un tema custom è di 5-15 giorni-uomo per uno sviluppatore Shopware esperto, più qualche giorno di collaudo. Anticipare l’argomento, fare l’upgrade in staging, testare esaustivamente prima della prod, è ciò che distingue una migrazione controllata da una migrazione in crisi.
Per gli argomenti tecnici correlati, sfoglia le nostre categorie Notizie e-commerce e Performance & Core Web Vitals. E se cerchi plugin Shopware 6.7 ben mantenuti e performance-first, il nostro plugin Dark Mode è compatibile Shopware 6.7 fin dall’uscita e illustra i pattern tecnici allineati sulla nuova architettura (anti-FOUC, custom field customer, eventi JS per sincronizzazione di terze parti).