Shopware 6.7.11 Developer Check: Twig UX Components, Vite Dev Server and a Better Storefront Architecture

In short: Shopware 6.7.11.0 (released June 16, 2026) is the most interesting storefront release in a long time: a new component system based on Twig UX Components, a Vite-based dev server replacing composer watch:storefront, theme configuration as native CSS custom properties and a global JavaScript event system. None of it forces an immediate rebuild - but whatever you build new from now on should be built on the new foundation.

The new component system: Twig UX Components

The classic Shopware storefront has lived for years with scattered template blocks: a feature sits in a Twig template, its SCSS somewhere else, its JavaScript somewhere else again. With 6.7.11, Shopware introduces a component system based on Twig UX Components - including SCSS and JS handling directly attached to the component.

That is remarkable for two reasons:

1. Reusability: A component encapsulates template, styling and behavior in one place. That reduces exactly the kind of copy-paste between templates that nobody maintains later in grown themes.
2. The direction is right: The component system is the technical foundation for the future content system. Building component-based today means building in the direction Shopware is moving - and components are usable in existing templates right away, no big bang required.

Important context: the classic Twig storefront setup is not dead - quite the opposite. Shopware is visibly investing in the Twig storefront instead of betting everything on headless. For the many shops running a classic theme, that is good news.

Vite dev server: no more proxy setup

The second everyday win: a new Vite-based dev server replaces the previous composer watch:storefront (now deprecated):

composer storefront:dev-server

Changes to SCSS and JavaScript files reach the browser without an additional proxy. Anyone who has ever fought the old watcher proxy, its ports and its quirks knows how much friction this removes from daily theme work.

Theme configuration as CSS custom properties

Theme configuration values are now available as native CSS variables:

.btn-primary {
    background: var(--sw-color-brand-primary);
}

All configuration fields without scss: false are exposed automatically as custom properties. This is the first visible step away from PHP-based SCSS compilation: visual settings can be used without a theme compile in between. Mid-term this means faster theme changes and fewer "why is my style not applied?" moments.

Global JavaScript event system

Also new is a global event system on window.Shopware:

window.Shopware.emit('Filter:Change', { foo: 'bar' });
window.Shopware.on('Filter:Change', ({ foo }) => { /* ... */ });

Until now, plugin events were bound to instances, which made communication between storefront plugins unnecessarily awkward. The global system is the cleaner base - and according to Shopware the foundation for future interceptable events, for example to modify request parameters before submission.

Deprecations and duties for plugin developers

What you should have on your list:

• composer watch:storefront is deprecated - switch to the new dev server.
• RegisterScheduleTaskMessage is deprecated - call TaskScheduler::registerTask() directly instead.
• Four block names in the listing options configuration were renamed - themes overriding these blocks should check.
• pluginTranslationExists() gives way to the locale-aware pluginTranslationExistsForLocale().
• theme.json now supports single-file references for style and script - useful for including individual files instead of whole directories.

On top of that come smaller but practical improvements: plugin installations now run in dependency order, the Sync API gets seven new foreign-key resolvers, and mail templates can be rendered sales-channel-aware.

My assessment

6.7.11 is not a release that breaks existing themes - but it is one that sets the direction for the next two years. My recommendation: do not rebuild existing code in a hurry, but develop every new storefront feature as a component from now on, adopt the Vite dev server into your daily workflow and clear the deprecations in your next regular maintenance window. Doing this on the side now means far less legacy baggage at the next major jump.