Shopware 6.7.14.0: new communication for deprecations and BC changes

AI-generated sample image, may differ from reality.

Shopware will in future distinguish more clearly between genuine deprecations and other backward compatibility changes. This is meant to give developers better migration signals and make upgrades easier to plan.

On 24 August 2026, Shopware announced a change in how technical API changes are communicated, with a view to version 6.7.14.0. Genuine deprecations remain marked as such. Other breaking or BC changes will additionally be described with structured PHP attributes. This is particularly relevant for plugin and extension developers, because it makes it easier to tell migration paths and release planning apart; you can find the original announcement as the vendor describes it.

What does Shopware 6.7.14.0 change about deprecations and BC changes?

Shopware keeps genuine deprecations as a warning signal and introduces structured PHP attributes for other backward compatibility changes that describe the type of change. This separates migration notices from mere compatibility adjustments and gives developers a more precise picture.

Technically, this means that methods or API endpoints that are actually being removed or are obsolete remain marked with deprecation notices. Changes that are relevant for compatibility but do not remove anything in the deprecation sense are documented additionally or alternatively through PHP attributes. The aim is less noise in deprecation logs and better signals for automated checks. The change mainly affects internal documentation and tooling, which until now often treated deprecations and BC notices the same way.

Who is affected by the new labelling in practice?

Primarily plugin and extension developers; secondly, shop operators with custom adjustments or third-party plugins. The distinction helps prioritise changes and reduces false migration urgency.

Plugin developers will see more clearly whether an API can really be removed or whether only behavioural details have changed. Shop operators running their own customisations or integrations benefit because upgrade checklists produce fewer false positives. For pure shop administrators, little changes in the frontend; the change is mainly relevant for code quality, CI pipelines and release planning.

Which technical adjustments should plugin developers expect?

Expect PHP attributes in core source code and APIs that provide semantic hints (e.g. on breaking changes without a classic deprecation). Developers need to parse attributes and adapt CI checks to filter the right migration signals.

More specifically, plugins should in future check for PHP attributes that contain backward compatibility information. This may mean extending static analysis tools, Composer checks or your own upgrade scripts to read these attributes. Shopware itself will continue to use classic deprecation mechanisms; the attributes serve as additional structured metadata. The original source describes the change in the vendor’s own words. Technically, attributes have been available since PHP 8; if your environment uses older PHP versions, adjustments or compatibility layers are required.

How does this affect update and migration planning?

The distinction reduces upgrade uncertainty: you can see faster which changes are genuine removals and which are merely refinements of behaviour or API. This makes roadmap priorities more reliable.

Operationally, migration lists can be prioritised more finely. Genuine deprecations remain red flags; BC changes can be marked as yellow flags with explanatory attributes. Use this to run automated tests specifically on deprecations and to integrate attribute checks into CI. Experienced teams will evaluate attributes in release notes and pull requests to estimate effort more accurately. Note that Shopware presents this primarily as a change in communication, not in its API break policy. The actual impact still depends on the specific changes in the respective version notes.

What should you do now?

Check your plugins for deprecation logs and extend tests and CI so that PHP attributes are read and evaluated. Draw up a priority list: fix immediately (deprecations), review later (BC attributes).

Concrete steps:

• Audit: collect deprecation notices from logs and identify code that contains or could contain PHP attributes.
• Adapt CI: add static analysis checks that evaluate attributes so that BC changes are not treated as deprecations.
• Write tests: add unit and integration tests covering critical API calls; label tests that need to react to deprecations.
• Communication: inform external plugin developers or integration partners about the new labelling, ideally with links to release notes.
• Fallback plan: keep pinning core versions and a test environment for major updates as a guideline.

For more depth, you can use our Shopware category for technical notes or search the Technology section for guides on CI integrations. As a guideline: when you switch to PHP 8 attributes, test tools for reading the attributes in a staging environment before moving changes into production.

Is it worth switching now or should you wait for field reports?

The switch pays off step by step: prioritise deprecations immediately and attribute-driven checks as needed. Switching completely to attributes makes sense as soon as your CI toolchain is compatible.

Pragmatically: continue monitoring and logging deprecations first. Then gradually add attribute evaluation to automated tests. If you run many third-party plugins, a staged approach is advisable: initial scanning, adapting critical plugins, then broader integration into CI. Don’t wait for field reports, but don’t invest straight away in major overhauls of the build pipeline either; test in an isolated environment first.

Frequently asked questions

Do all plugins need to be adapted immediately?

Not necessarily. Genuine deprecations take priority. First check whether your plugin triggers deprecation logs. BC changes that are only marked by attributes can be assessed and migrated in a second step.

Which PHP version is required for attributes?

PHP attributes are available from PHP 8. If you use older PHP versions, you need a compatibility layer or should plan a PHP upgrade. The Shopware announcement names attributes as the mechanism and assumes that the target environment supports them.

Are there ready-made tools for reading the new attributes?

Static analysis and CI tools can be adapted; ready-made plugins for Shopware are not guaranteed at the time of publication. Plan time for adjustments or your own script solutions.

Does the change affect the Store review process?

Not directly. The change concerns technical labelling and developer communication. Store reviews keep their own criteria; any effects depend on the specific quality requirements of the store operators.

Conclusion

Recommendation: prioritise deprecations immediately and gradually add attribute evaluation to your CI. Start with an audit of the logs, add tests and inform integration partners. Use the new attributes to assess upgrade risks more precisely, and test the adjustments in staging environments first.