Migrate Shopware Plugins to 6.7: Symfony 7 and Vite

Shopware 6.7 is no ordinary minor update. If you run your own plugins or apps, you face a hard technical cut: the framework jumps to Symfony 7.3 (Shopware Release Notes 6.7.0.0), the administration build switches from Webpack to Vite (Shopware Developer Documentation), the Vue 2 compatibility layer has been removed (Shopware Release Notes 6.7.0.0), and all core properties now carry native PHP types. For your Shopware extensions, that means: without changes they no longer run cleanly on 6.7. This guide shows which changes affect you concretely, how to maintain separate plugin versions for 6.6 and 6.7, and which checklist helps you approach the migration systematically.

Why 6.7 Is a Hard Cut for Extensions

Earlier jumps such as 6.5 to 6.6 usually offered a transition period with deprecation warnings and compatibility layers. Shopware 6.7, by contrast, bundles several major upgrades into one release and removes exactly those bridges. The framework runs on Symfony 7.3 (Shopware Release Notes 6.7.0.0), and PHP 8.2, 8.3, and 8.4 are supported (Shopware Release Notes 6.7.0.0) - older PHP versions drop out. At the same time, the Vue 2 compatibility layer in the admin has been removed without replacement (Shopware Release Notes 6.7.0.0). For extensions this means: the convenient middle path is gone, and each front must be addressed directly. Anyone who knows the architecture of their extensions can estimate the effort realistically.

Symfony 7.3: Stricter Type Declarations in the Backend

Symfony is the foundation beneath the Shopware backend. With the jump to Symfony 7.3, the rules for type declarations tighten considerably. In versions 6 and 7, Symfony added native PHP return types to nearly all methods; if these are missing in your derived classes, PHP responds with incompatible declaration errors (Symfony Upgrade Documentation). In addition, every major version removes all features previously marked as deprecated - if you did not clean up in the last minor 6.4, you pay the price during the upgrade (Symfony Upgrade Documentation).

In practice this affects every class that decorates a Shopware or Symfony service, implements an interface, or overrides a core method. Signatures that previously worked without parameter and return types must now match the parent class exactly. The following example shows the difference on a typical service decorator:

// Until 6.6: loosely typed service method
public function enrich($product, $context)
{
    return $this->decorated->enrich($product, $context);
}

// From 6.7 / Symfony 7.3: native types are mandatory
public function enrich(
    SalesChannelProductEntity $product,
    SalesChannelContext $context
): SalesChannelProductEntity {
    return $this->decorated->enrich($product, $context);
}

• Service decorators: Do parameter and return types match the decorated class exactly?
• Event subscribers: Do the method signatures match the current event classes?
• Interface implementations: Are all native return types added that Symfony 7 expects (Symfony Upgrade Documentation)?
• Deprecated calls: Are you still using functions that were removed in Symfony 7.0 (Symfony Upgrade Documentation)?

Native PHP Types on Core Properties

Alongside Symfony, Shopware tightens typing in its own code: in 6.7, all PHP class properties have a native type (Shopware Release Notes 6.7.0.0). Native property types have existed in PHP since version 7.4 (PHP.net), yet the Shopware core did not use them everywhere for a long time. If you extend a core class and previously inherited or redeclared its property without a type, you must now specify the type exactly - otherwise the class breaks on load.

The principle behind it is standard PHP: type declarations are checked at runtime, and a mismatching value triggers a TypeError (PHP.net). If you also set declare(strict_types=1), PHP no longer accepts automatic type coercion (PHP.net). For extensions this means more care in declarations - but also fewer silent errors, because type conflicts become visible immediately. Especially for revenue-critical e-commerce features, this is a gain in stability.

// Until 6.6: an untyped property could be overridden freely
class CustomLineItem extends LineItem
{
    protected $customFields;
}

// From 6.7: the core property is typed -> declaration must match
class CustomLineItem extends LineItem
{
    protected ?array $customFields = null;
}

Vite Instead of Webpack: The Admin Build Breaks

The most visible change for admin extensions is the switch of the build system. Shopware replaces Webpack with Vite (Shopware Developer Documentation). The reason is pragmatic: the Vite build produces the core admin in around 18 seconds, saving over 50 percent of the previous build time (Shopware Developer Documentation). For you as an extension maintainer, however, the switch is not backward compatible - a custom webpack.config.js is no longer read.

Instead of the old Webpack configuration in the build/ directory, 6.7 expects a vite.config.mts directly in the src/ directory of your administration (Shopware Developer Documentation). Webpack dependencies leave the package.json, Vite dependencies are added. Apps are unaffected because their build is decoupled from the Shopware core anyway (Shopware Developer Documentation). We described the new dev server in our article on the Vite dev server and Twig UX in 6.7.11.

Vue 2 Compatibility Layer Removed

With 6.7, the Vue 2 compatibility layer is finally removed (Shopware Release Notes 6.7.0.0). The admin has run on Vue 3 since 6.6, but in compatibility mode - that buffer is now gone. Components still relying on Vue 2 behaviour must be ported to real Vue 3. At the same time, state management moves from Vuex to Pinia, with Shopware.State replaced by Shopware.Store (Shopware Release Notes 6.7.0.0).

// Until 6.6: Vuex access inside the admin module
const product = Shopware.State.get('swProductDetail').product;

// From 6.7: Pinia store
const product = Shopware.Store.get('swProductDetail').product;

The change mainly affects extensions with their own admin modules, detail pages, or data grids. Pure storefront plugins without administration components are affected much less here - for them, Symfony 7.3 and the native PHP types take centre stage. If you are modernizing the storefront in parallel, you often combine the switch with techniques such as the View Transitions API for smooth page navigation.

Further Breaking Changes at a Glance

Besides the four big topics, there is a series of smaller but equally hard changes that affect individual extensions. The following overview summarizes the most common touchpoints (Shopware UPGRADE-6.7). We handle the adjustment of these points as part of custom plugin development.

• Payment handlers: The new AbstractPaymentHandler replaces the previous sync and async interfaces (Shopware UPGRADE-6.7).
• Entity extensions: getEntityName() is now abstract and must be implemented (Shopware UPGRADE-6.7).
• Scheduled tasks: Handlers expect a LoggerInterface as the second constructor argument (Shopware UPGRADE-6.7).
• OAuth2 API: Non-spec-compliant token requests are no longer accepted; scopes must be passed as a string (Shopware UPGRADE-6.7).

Separate Plugin Versions for 6.6 and 6.7

The most important practical advice: do not try to build a single plugin version for both 6.6 and 6.7. Because the admin build is not backward compatible, from 6.7 you need a separate plugin version with the matching build files anyway (Shopware Developer Documentation). A clean version cut has proven effective: the 6.6 branch stays frozen as 1.x and receives only maintenance, while the 6.7 branch starts as 2.x. As an experienced Shopware agency, we accompany this cut from planning to release.

You control this via the Shopware compatibility constraint in composer.json. The frozen branch pins shopware/core to ~6.6.0, the new branch to ~6.7.0. That way each shop version automatically installs the matching plugin version:

{
    "name": "swag/example",
    "require": {
        "shopware/core": "~6.7.0"
    },
    "extra": {
        "shopware-plugin-class": "Swag\\Example\\SwagExample"
    },
    "version": "2.0.0"
}

1. Pin the 1.x branch to shopware/core: ~6.6.0 and ship only security-relevant fixes
2. Branch off 2.x for 6.7 and implement Symfony signatures, native types, and the Vite build there
3. Port admin components from Vue 2 patterns to Vue 3 and Pinia
4. Test both branches against the respective Shopware version in a CI pipeline
5. Document the changelog and system requirements clearly per branch

Splitting extensions into two clean branches early means migrating with a plan instead of under pressure - and keeping both customer groups operational.

XICTRON development team

Make Your Extensions Ready for Shopware 6.7

The following checklist bundles all the steps to move an extension safely to 6.7. It works as a basis for your own planning - or as a scope of work we handle for you. If a platform or version switch is due in parallel, our Shopware migration guide helps with overall planning, and the article on the PHP 8.5 migration adds the runtime perspective. Also use the update for content tasks such as accessible alt text for product images.

• All extensions inventoried and sorted by storefront/admin share
• Service decorators and event subscribers checked for native Symfony 7 signatures
• Extended core properties given native PHP types
• Deprecated calls identified in debug mode and replaced
• webpack.config.js replaced by vite.config.mts and a clean build achieved
• Admin components ported to Vue 3, Vuex access switched to Pinia
• Payment handlers rebuilt on AbstractPaymentHandler (where relevant)
• Separate 6.6 and 6.7 branches created with matching composer.json compatibility
• Both branches tested end-to-end in a staging environment
• Changelog, system requirements, and rollback plan documented

In our experience, the effort depends heavily on the admin share: pure storefront plugins are often migrated within a few days, while extensive admin extensions with their own modules and data grids need more time for the Vue 3 port (project experience). Also plan buffer for testing both branches in a staging environment (project experience).