為 Shopware 6.8 作準備：開發者早期指引

At our October Hacktoberfest in Schöppingen, we came together with the community to share what we’ve been working on and explore what comes next.
Preparing for Shopware 6.8 was part of that conversation: I walked through the latest developments, with a practical focus on what you can start doing today.
From testing upcoming changes behind feature flags to checking compatibility and sharing feedback, there are steps that can make the next upgrade easier.
In this blog post, we’ll walk through those learnings and show how to make preparation part of regular development work, rather than leaving it until release day.

Our goal is to make 6.8 the smoothest, most predictable and easiest-to-upgrade Shopware 6 major release so far.
Compatibility tooling, testable feature flags and community feedback give agencies and plugin developers more time to understand the changes and prepare their projects.

You can already join the conversation in Discord #feedback-6_8.
Trying the available tools and sharing difficult cases now gives our team valuable input while the implementation and upgrade approach can still evolve.

Shopware 6.8 is planned for 2027, with timing and scope subject to change as planning is still at an early stage.
That gives you a useful preparation window: start identifying the work now and include it in next year’s plans.

Start with a clear picture of the project

The first step is to map each installation: its Shopware version, hosting requirements, plugins, custom code and integrations.
That picture helps identify which changes could affect customer journeys or business processes, and provides the basis for a sequence of tasks and an initial estimate.

The budget needs to cover both preparation and the major upgrade itself.
Compatibility work, testing and coordination with plugin vendors take time even when the final version change becomes smaller.
Making that work visible early helps merchants plan costs and schedule changes around their business.

Tooling can help reveal dependencies and missing work.
The project plan still needs someone who understands how the shop operates.

Use that to decide where to start:

Check the customer journeys and integrations that could behave differently.
Use the major-version flag and compatibility checks to find affected code.
Identify preparation work you can release separately, before the major upgrade.

Test the behavior customers depend on

Code can continue to run while an integration behaves differently.
Some problems only become visible later, when a customer uses a particular discount or an order reaches another system.
Feature flags offer an early way to explore these changes in a test environment, alongside automated tests and checks of real customer journeys.
The following examples show where changed behavior could affect a shop and what teams can check in advance.

For these checks, a successful request is only the starting point.
A small change in the tax calculator is a good example: the code can still run, while the amounts your payment integration receives have changed.
Build assertions around the result the customer or connected system depends on, rather than only checking that checkout returns successfully.

Caching and personalized content

The cache rework keeps HTTP caching active for cacheable pages even when customers are logged in or have items in their carts, allowing more efficient responses.
With CACHE_REWORK enabled in a test environment, compare personalized content across different customers and cart states.
Check cache invalidation separately.
Customizations that assume these responses are never cached could accidentally place customer-specific information in a shared response.
Testing those assumptions protects both privacy and correctness.

Taxes and discounts

We’re correcting rounding edge cases where the cart calculation could produce slightly incorrect amounts.
The proportional cart tax changes reuse existing item taxes for percentage discounts, surcharges and split quantities.
Even a one-cent correction can matter when orders are passed to payment, ERP or accounting systems, so we’re introducing the change behind a feature flag before making it part of the major upgrade.

Use the same cart before and after enabling the flag, with a percentage discount and products at different tax rates.
Compare the line-item taxes and final totals, then follow those values into the payment request and your downstream integrations.
Include split quantities if your shop uses them.
A difference of a cent is exactly the sort of result that can slip past a test which only checks whether an order was created.

Document generation

The experimental DOCUMENT_GENERATION_REWORK separates document data preparation from rendering, making different document types and output formats easier to extend.
Existing Twig templates remain, while PHP integrations need review against the new extension points.
Test custom data and generated output.
The planned transition retains the old implementation as a fallback in 6.8, with removal planned for 6.9.

Adding more formats has made the old system harder to extend, so testing only the PDF would leave part of that change unchecked.
For example, take an invoice with custom data added by your plugin and generate it in every format you support, such as PDF and accessible HTML.
Check that the data reaches each output and that your Twig customizations still render as intended.

Flow execution

FLOW_EXECUTION_AFTER_BUSINESS_PROCESS is already available for testing and is planned to become the default in 6.8.
For HTTP requests, it allows the customer response to be sent before flow actions finish, reducing the impact of expensive or failing flows on checkout completion.
Execution remains in the same process.
Review assumptions about tags, state changes and other flow results being available immediately; transaction-critical work belongs in synchronous subscribers.

Consider a flow that adds a tag to an order or customer.
If your checkout response reads that tag to decide what to display, it can no longer assume the tag is already there.
Test the response itself as well as the eventual database state: the flow may complete correctly while the page has already been rendered without its result.

Explore the growing compatibility toolkit

The major-version flag, V6_8_0_0=1, can expose upcoming incompatibilities where the corresponding checks are implemented.
A flagged CI run alongside the normal run helps reveal what needs attention while retaining coverage of current behavior.
Coverage is expanding, so interpret the results alongside behavioral tests and the official 6.8 upgrade guidance, which is still a work in progress.

We’re also making compatibility information more precise.
Released PHP attributes describe planned API changes more clearly, while the accompanying future-compatibility PHPStan rules remain experimental and opt-in.
An open polyfill proposal explores easier support for several Shopware versions in one plugin release.

Administration extensions already have experimental ESLint and type-checking support.
Runtime guards are still being developed.
Storefront template guards and warning prototypes are also progressing, with questions around multi-version support still being worked through.

The Administration code already provides examples of this approach.
Its ESLint rules can flag a deprecated sw-button and point you to mt-button.
Use the rules shipped with your installed Shopware version; this illustrates what the tooling can do today.

The existing Shopware CLI project upgrade workflow already supports local upgrade preparation.
The aim is to bring the 6.8 compatibility checks together in a unified diagnostic experience through Shopware CLI, making preparation easier for developers.
As these building blocks develop through the rest of 2026, concrete feedback can help us improve them.

Run PHPUnit, PHPStan and the available Administration checks as separate CI steps until the unified command is released.

Build compatibility into regular maintenance

For plugin developers, a reliable CI pipeline is the foundation.
Each new Shopware release provides an opportunity to run the checks, investigate failures and review fixes.
Testing across the supported version range then provides the basis for releasing a compatible update.

AI agents can help analyze failures and propose changes.
Developers still need to review, test and approve them.
Smaller batches, perhaps alongside each monthly release, are easier to inspect than a single large set of changes shortly before the major upgrade.
Agency teams can use the same rhythm for custom project code.

My recommendation is to get CI in place before handing changes to an agent.
A small, tested fix each month is much easier to review than a pull request that rewrites the plugin just before 6.8.

Separate the preparation steps

You don’t need to wait for a Shopware 6.8 upgrade project to start preparing.
Where your current Shopware version, extensions and hosting support it, upgrade PHP and the database in advance, then release compatible plugin updates and custom-code changes separately.
Test each change before moving to the next one.
That keeps the major upgrade smaller and makes problems easier to trace.

Prepare PHP.
PHP 8.5 is the planned minimum for 6.8.
Move only when the currently installed Shopware version, extensions and dependencies support it.
Resolve Symfony deprecations on compatible current releases ahead of the planned move to Symfony 8.x or later.
Prepare the database.
The planned minimums are MySQL 8.4 or MariaDB 11.4, depending on the engine you use.
Confirm current-release and hosting support, and test custom migrations before upgrading separately.
Update plugins.
Prefer releases supporting both the current and target Shopware versions where available.
Check vendor plans and identify gaps early.
Adapt custom code.
Address deprecations and review affected integrations, themes and components.
Planned Twig 4 and Symfony UX Twig Component 3 changes also deserve attention, especially for custom extensions.
Validate changed behavior.
Test relevant flags individually, keep the major-flag CI run, and verify customer journeys and integrations in staging.
Complete the major upgrade.
Bring the prepared components together and validate the full shop.
Separating earlier changes makes unexpected results easier to trace.

Share the cases that need more support

Early testing can improve both your own plan and the tools available to everyone.
Share a reproducible example, the Shopware versions you need to support, and what makes a migration difficult in Discord #feedback-6_8.

The greatest opportunity to influence the approach is before scope settles and the first release candidate arrives.
Start with one project, try the available checks and bring the findings back to the team.
Those small steps can turn preparation into steady progress and reduce surprises when it is time to upgrade.

A useful report might show a plugin that needs two different class declarations to support old and new interfaces, or a template warning that flags an intentional compatibility fallback.
Include a small code example, the failing check and the versions you need to keep working.
These are the kinds of cases I’d like you to share: they show us where to focus our efforts to make Shopware 6.8 the smoothest upgrade to date.