Shopware 6.7.11: Vite Dev Server and Twig UX

With Shopware 6.7.11.0 (Release News June 2026), the classic Twig storefront gets its biggest frontend update in a long time: a Vite dev server without an additional proxy, a new component system based on Twig UX Components, theme configurations as native CSS custom properties and a global window.Shopware event system. This article explains the changes from a developer perspective, places them within the Vite migration and shows how to modernize your Shopware theme step by step.

What changes in Shopware 6.7.11 for the storefront

Unlike the headless variant with Vue and Nuxt, the server-side rendered Twig storefront remains the foundation here. Shopware modernizes it gently from within instead of replacing it. The four central changes in 6.7.11.0, according to the release notes (Shopware Documentation):

These building blocks interlock: components can be developed in isolation, their styles controlled via CSS variables from the theme, their behavior coupled via the global event system, and the entire cycle runs through the fast Vite dev server. Anyone who has accompanied a migration from Shopware 6.6 to 6.7 knows the pattern: Shopware prepares the architecture for the next major leap.

Important for context: this is an evolution, not a break. The server-side rendered storefront is preserved with all its advantages, such as good indexability for search engines and short time-to-first-byte values with clean caching. The new tools layer on top without requiring you to fundamentally change your architecture. That is exactly what makes the switch attractive: you modernize at your own pace and keep control instead of following a forced big-bang change.

Vite dev server: no more proxy setup

Until now, local storefront development ran via composer watch:storefront. That command started a hot proxy placed in front of the actual shop, rebuilt assets and refreshed the browser. It worked but added friction: an extra port, a proxy layer and a full theme build on every change. In Shopware 6.7.11, composer watch:storefront is marked as deprecated in favor of the new dev server (Shopware Documentation).

# New in 6.7.11: Vite dev server, no proxy required
composer storefront:dev-server

# Previous command, deprecated as of 6.7.11
composer watch:storefront

The new storefront:dev-server relies on the Vite dev server. Changes to SCSS and JavaScript are served directly through Vite, without a fronting proxy. You open your normal storefront path, the dev server hooks in and serves the changed modules (Shopware Release News June 2026). Why this is noticeable becomes clear from the admin migration: Vite builds the core administration in around 18 seconds, a saving of over 50% (Shopware Documentation) compared to the previous Webpack build.

Vite has become the standard in the frontend world: in the State of JS 2025 developer survey, the tool reached around 92% satisfaction (State of JS 2025) and has been among the most positively rated build tools for years. The reason lies in its dev model: instead of rebuilding the entire bundle, Vite only re-serves the changed file via native ES module loading, which significantly speeds up hot module replacement (Vite documentation).

Technically, the storefront dev server builds on the infrastructure Shopware already established for the administration. There, the Symfony bundle pentatrion_vite loads the correct asset files based on a generated entrypoints.json produced by its counterpart vite-plugin-symfony (Shopware Documentation). In development mode, a dedicated manifest file is used so that several bundles can serve their assets in parallel. For you as a merchant, this mainly means fewer moving parts in the local setup and a dev server that hooks seamlessly into the existing storefront request.

One practical detail rounds off the picture: the theme.json now supports single-file references from other bundles via a bundle-relative syntax like @BundleName/path/to/file, for both style and script entries (Shopware Documentation). This makes it easier to organize theme assets cleanly and pull them in selectively from several extensions instead of maintaining monolithic collection files.

Twig UX components: reusable building blocks

The new component system is the strategically most important part of the release. Twig UX Components bring a concept to the storefront that is familiar from modern frontend frameworks: encapsulated, parameterizable building blocks that can be reused anywhere instead of overriding large templates via block overrides.

{# Reusable component with props #}
{% props label, value, variant = 'default' %}

<span class="price-badge price-badge--{{ variant }}">
  <span class="price-badge__label">{{ label }}</span>
  <span class="price-badge__value">{{ value }}</span>
</span>

{# Embed the component anywhere #}
<twig:PriceBadge label="In stock" value="{{ product.calculatedPrice }}" variant="highlight" />

The advantage over the classic block system: instead of globally overriding central templates and risking colliding plugin adjustments, components encapsulate their markup, style and behavior logic. This lowers maintenance effort and makes updates more predictable. Anyone who frequently works with nested shopping experiences and page builder elements benefits in particular because recurring UI patterns can be consolidated.

• Encapsulation instead of global overrides reduces side effects between plugins and theme.
• Props make components parameterizable and thus reusable in many contexts.
• Dedicated SCSS and JS handling per component, compiled via Vite (Shopware Documentation).
• Gradual introduction possible: existing templates remain, new areas are built as components.

The economic core is maintainability over time. Anyone who maintains a theme for years knows the problem of colliding block overrides: an update to the standard storefront breaks an old adjustment, and debugging eats hours. Components with clearly defined props shift this burden because their interface stays stable while the implementation behind it is free to change. This makes future updates more predictable and reduces the risk of accumulating technical debt in the frontend.

Theme values as native CSS custom properties

Until now, theme configurations such as brand colors or spacing were mapped via SCSS variables and compiled into fixed values during the build. Changes typically required a theme recompile. In 6.7.11, the same values are additionally available as native CSS custom properties with identical names (Shopware Documentation).

/* Before: SCSS variable, resolved at build time */
.product-box__price {
  color: $sw-color-brand-primary;
}

/* New: native CSS custom property, resolvable at runtime */
.product-box__price {
  color: var(--sw-color-brand-primary);
}

CSS custom properties are supported by all modern browsers and are considered a baseline feature (Can I Use). According to the HTTP Archive Web Almanac, they have long been part of the standard repertoire of modern websites (HTTP Archive Web Almanac). The practical gain for Shopware: visual settings can be used more flexibly and independently from SCSS compilation, for example for runtime themes, dark mode variants or context-dependent accent colors, without needing a full theme build.

window.Shopware: the global event system

The fourth major feature is a global JavaScript event system via the central window.Shopware object. Until now, plugin communication was strongly tied to the respective plugin instance. The new system uses a native event-emitter pattern with additional capabilities such as interceptable events and thereby eases communication between storefront components (Shopware Documentation).

// Listen to a global storefront event
window.Shopware.on('checkout.line-item-updated', (payload) => {
  console.log('Cart updated', payload);
});

// Emit your own event
window.Shopware.emit('mini-cart.opened', { itemCount: 3 });

In addition, a new method window.PluginManager.callPluginMethod(pluginName, methodName, ...args) allows calling a specific method on all instances of a plugin (Shopware Documentation). This is useful when, for example, a global state change affects several plugin instances on a page. For more complex, interactive storefronts, this creates a cleaner architecture than before, without having to switch to a pure headless architecture with the Store API.

Components, CSS variables and a global event system together result in a frontend that feels like a modern framework yet stays server-side rendered, keeping its SEO and performance advantages.

XICTRON development team

Placing it within Shopware's Vite migration

The storefront changes are part of a larger movement: Shopware is gradually replacing its build stack from Webpack with Vite. In the administration, this switch is already well advanced. Vite builds the core administration in around 18 seconds, which means a saving of over 50% (Shopware Documentation), and can be activated via the ADMIN_VITE feature flag.

Important: there is no abrupt big-bang switch planned for the storefront. The more UI is moved to the component system, the larger the share of JS compiled by Vite becomes. The transition therefore happens organically as components gradually replace classic templates (Shopware Documentation). Plugin developers in the administration will migrate their webpack.config.js to a vite.config.mts over time; hot module replacement there initially applies to Vue files until the single-file component migration is complete (Shopware Documentation).

To keep the transition smooth, Shopware developed specialized Vite plugins. An override-component plugin automatically registers *.override.vue files, and a vue-globals plugin prevents multiple Vue instances by destructuring from Shopware.Vue (Shopware Documentation). These details primarily concern the administration but show the pattern: Shopware encapsulates the complexity of the migration in tooling instead of pushing it onto every individual extension.

Besides the four major frontend topics, 6.7.11 also brings smaller but useful improvements. For example, single-hit search redirects now trigger on exact matches for the ean and manufacturerNumber fields, configurable via shopware.storefront.redirect_on_single_hit_fields (Shopware Documentation). Such detail improvements add up in practice to noticeably better user guidance, for example when customers search specifically for article numbers.

For development teams, the changes add up to a noticeably better daily workflow. A fast inner loop means: a change to the code, a glance at the browser, move on. That preserves focus and shortens the time between idea and visible result. Components with stable interfaces also make collaboration easier because several people can work on different building blocks in parallel without getting in each other's way in central templates. And CSS custom properties make design adjustments traceable because values are defined in one place and referenced everywhere.

• Faster feedback cycle thanks to the Vite dev server without a proxy
• Fewer merge conflicts thanks to encapsulated components instead of global overrides
• Consistent design through centrally defined design tokens
• Cleaner communication between components via the global event system
• Future-proof foundation for the announced content system

How XICTRON modernizes your storefront

The changes are not an end in themselves but lower maintenance costs in the long run and speed up ongoing development. As a Shopware agency, we accompany the switch in clearly delimited steps so that your shop stays stable throughout.

1. Inventory: We analyze the theme, block overrides, custom JS and existing Webpack adjustments and identify modernization candidates.
2. Dev server switch: We set up storefront:dev-server and adjust local and CI workflows to speed up the inner loop.
3. Component extraction: Recurring UI patterns are carefully moved into Twig UX components without replacing existing templates all at once.
4. Token migration: Frequently changed design tokens are switched to CSS custom properties, while SCSS remains usable in parallel.
5. Event architecture: Plugin communication is moved to the global window.Shopware event system where it makes sense.
6. Quality assurance: Visual regression tests and a clean maintenance and update process secure the result.

If you want to think about performance holistically, we complement the frontend modernization with server-side measures such as caching strategies and edge delivery as well as a look at Core Web Vitals and Lighthouse scores. This results in a frontend that is not only faster to develop but also faster for your customers.