A Shopware plugin compatibility check shows how much work a major update will be. I run one before I touch any store that’s moving from 6.4 to 6.7, and it starts with a plain list of what’s installed.
A shop that has run on 6.4 for a few years has probably collected plugins from more than one developer. Nobody remembers why each one is there. The update will find every one of them.
6.4 to 6.7 is three updates
That’s three major versions: 6.5, 6.6 and 6.7. Each one broke a different kind of plugin. These are the changes from Shopware’s own upgrade guides:
- 6.5: PHP 8.1 became the minimum. The storefront moved to Bootstrap 5 and jQuery left the platform, so a theme or plugin that relied on jQuery has to be rewritten or ship its own copy.
- 6.6: PHP 8.2 became the minimum. The admin moved to Vue 3 and webpack 5, and Shopware warns that an admin extension built for 6.6 won’t run on 6.5 or lower.
- 6.7: The admin build moved from webpack to Vite, so a custom
webpack.config.jsneeds avite.config.js. The Vue 2 compatibility layer is gone, and the admin’s state management moved from Vuex to Pinia. Shopware’s Vite guide covers the build change.
A plugin that only touches the storefront meets its changes at 6.5. An admin extension can break at 6.6 and again at 6.7. That’s why I never judge a plugin by its name or its age.
Step 1: get the full list
Everything installed, active or not. The Extensions area in the admin shows it, and so does bin/console plugin:list on the server.
An inactive plugin still sits in your installation, so it needs a decision like any other.
Step 2: sort each one into a bucket
- Custom theme. Storefront code written for your shop. The 6.5 changes, Bootstrap 5 and no jQuery, hit themes first.
- Purchased plugin. Written by a vendor. It declares the Shopware versions it supports in its
composer.jsonand on its Store page, and that declaration is the first answer you get. - Custom plugin. Written for your shop by a developer. The upgrade guides above are the checklist.
Step 3: write down what each plugin does
A plugin name tells you little. The feature tells you what the shop would lose. For each plugin I note which feature it provides and what the shop would lose without it.
If nobody can answer that, it’s a question for the shop owner. It’s better asked before the update than after.
Step 4: replace it or rebuild it
Each feature ends up in one of two places. If a maintained replacement exists, I replace the plugin. If none exists, I rebuild the feature.
I don’t wait for a vendor to ship a compatible version. The vendor’s release plan isn’t your update date.
There’s one exception: plugins that depend on a third-party service, such as a payment provider or a carrier’s API. If the provider hasn’t updated its side, rebuilding the plugin changes nothing, because the service decides what works. That’s the only case where I wait.
PHP comes with the update
Two of those steps also raise the PHP floor: 8.1 for 6.5 and 8.2 for 6.6. Plugin code has to run on the new PHP as well as the new Shopware.
It’s a security question too. Varonis, a security vendor, says PHP 8.1 and older have no official fix for the php2shell flaws. I cover that in who patches your Shopware shop.
What a check usually turns up
In my checks it’s usually 3 to 4 plugins per shop that need a replacement or a rebuild.
Those plugins set the scope of the update.
A messy migration history is a separate problem, and I wrote about one in my 6.3 upgrade story. For how I build plugins so they survive the next update, see my plugin development approach.
Frequently asked questions
Which Shopware changes break plugins between 6.4 and 6.7? 6.5 raised the PHP minimum to 8.1, moved the storefront to Bootstrap 5 and removed jQuery from the platform. 6.6 raised the minimum to PHP 8.2 and moved the admin to Vue 3 and webpack 5. 6.7 moved the admin build from webpack to Vite, removed the Vue 2 compatibility layer and replaced Vuex with Pinia. Each step breaks a different kind of plugin.
Should I wait for the plugin vendor to release a compatible version? No, with one exception. If a maintained replacement exists, I replace the plugin. If none exists, I rebuild the feature. I only wait when the plugin depends on a third-party service, because then the service provider decides what works and a rebuild changes nothing.
How many plugins usually need work in a major update? In my checks it’s usually 3 to 4 plugins per shop that need a replacement or a rebuild.
If your shop is on 6.4 and you want that list built, with a replace-or-rebuild call for every plugin, get in touch. I take this on as a Shopware freelance developer, and the fixed-price audit there covers the plugin inventory with those decisions. More work like this is in my case studies.
