In short: Shopware is fundamentally rebuilding its content system: layouts will be defined as data (Content API) instead of Twig markup, the technical foundation - storefront components based on Twig UX Components - already shipped with 6.7.11, and a new page builder is in its discovery phase. The most important message for anyone with upgrade trauma: nothing existing gets broken - Shopping Experiences and the new system are meant to coexist for a long time. Customer-facing features are not expected before 2027.
Why Shopware is rethinking its content system
Shopping Experiences were a big step in 2019 - but years of feedback are unambiguous, and I can confirm every point from projects:
- Merchants want real WYSIWYG, more elements, more designable areas (header, footer, entire page types) and publishing workflows.
- Developers fight with extensibility: custom CMS elements require administration components, and template customizations are notoriously brittle during upgrades - the eternal TCO debate.
The answer is conceptually radical: layout becomes data. Instead of Twig blocks with embedded business logic, a data structure (freely nestable elements) describes how a page is built. The frontend - classic storefront, composable frontend, whatever - renders that data.
What the data model really means
Three consequences stand out to me:
- Upgrades get cheaper. Migrating data is plannable; repairing scattered template overrides is not. That is exactly where every larger Shopware update bleeds today.
- Frontend freedom without a rebuild. The "Twig or React or Vue" debate becomes secondary when the layout lives in data. Any frontend that can read the data can render the store.
- AI compatibility by design. You can teach an AI model a data structure; you cannot teach it nested Twig overrides. Shopware says this openly: the data model also prepares AI-assisted content creation - the line to Experience Studio from SCD is obvious.
The concept also includes tangible features: layout parts as shared references (edit once, updated everywhere - one of the oldest feature requests), the proven data mapping (build a layout once, assign it to thousands of products) and complete store layouts including header and footer per sales channel - configurable without code.
What is already here: the storefront components from 6.7.11
This is not a pure future concept: the foundation shipped with 6.7.11 and is usable today - including outside the coming content system, in perfectly normal templates:
- Twig UX Components with a clear public API: properties in, defined markup out, slots as extension points - instead of "override some block and hope".
- JS and SCSS handling per component with a Vite build and automatic loading: a component's JavaScript is only loaded if the component is actually rendered on the page (native ES module loading with an import map).
- The end of runtime SCSS compilation for components: theme configuration arrives as native CSS custom properties - faster, more robust, no PHP SCSS compile on config changes anymore.
- A global event system plus intercepting events: for example manipulating form data before submission instead of overriding entire JS plugins.
For plugin and theme developers the message is clear: whoever builds new elements as components today is already building them the way the coming content system expects.
My assessment: what to do now
As a merchant: No panic and no standstill. Shopping Experiences stay, the systems coexist. But if a redesign or relaunch is due in 2026/2027, the question "do we still build this classically or wait for the new system?" belongs in the planning - the answer depends on your time horizon, and that is exactly what honest technical consulting is for.
As a developer: Learn components now and use them for new work; leave existing code in peace. Shopware's GitHub discussion and prototype are public - if you want to shape the direction, the window is open right now.
As a skeptic: Justified. Shopware promises coexistence and "nothing breaks" - the promise is only proven in execution. But the way this is being introduced (ship the foundation first, community feedback before feature releases, customer features not before 2027) is considerably more mature than some upheavals of the past. That makes me cautiously optimistic.