Action required: Add the Shopware conflicts repository to your project before your next composer update
A new Twig release (3.28) is not compatible with the Shopware administration. Normally, we would prevent Composer from installing it in the background, without you ever noticing. However, as part of recent improvements Packagist made to strengthen the security of the PHP ecosystem, the workflow we use to publish dependency conflicts no longer works as expected. For this reason, every composer update can pull in Twig 3.28 and break your administration. This situation changes with Shopware 6.7.12.1, until you are using that version, you need to adapt your composer.json manually.
The fix takes one minute. Run this in your project root:
This adds our conflicts repository to your project and installs the shopware/conflicts metapackage. It tells Composer which package versions are known to be incompatible with Shopware, including the broken Twig release, and keeps them out of your installation. After that, you can update as usual.
Read on for who exactly is affected, what to do if your shop already broke, and how this situation came to be.
Who is affected?
Affected:
Self-hosted, Composer-managed Shopware projects, regardless of the Shopware version you are on. This issue is independent of your Shopware version, because Composer resolves dependencies at install time.
Anyone running composer update or composer install without a lock file that pins Twig to a version below 3.28, which the default behaviour being that it’s not pinned.
Anyone installing Shopware with an older version of shopware-cli.
New installations that don't include the fix yet.
Not affected:
Shops updated through the update button in the administration (Web Updater). The Web Updater is already patched.
Updates and installation done with the latest version of shopware-cli. Please update your shopware-cli before your next Shopware update or installation.
Projects that have already applied the fix above.
If you don't run any Composer commands, nothing breaks. But the next dependency update will pull in the incompatible version, so please apply the fix now rather than later.
My administration is already broken. What now?
If you updated over the weekend and your administration stopped working, the cause is most likely Twig 3.28. Apply the same fix in your project root:
Composer will downgrade Twig to the last compatible version, and your administration will work again.
Why does a Twig patch release break Shopware?
Shopware intentionally does not pin its PHP dependencies to exact versions. Patch releases are installed automatically on composer install and composer update. This is by design: when a security fix is published for one of our dependencies, you get it immediately, without waiting for a new Shopware release.
Twig is a special case. Shopware's extension system, for example features like sw_include, needs access to internal Twig API that is not covered by Twig's backwards compatibility promise. Internal API can change in any release, including patch releases. Twig 3.28 changed such an internal API, and the Shopware administration relies on it.
Why didn't the usual safety net catch this?
It has, for years. Since 2021, we maintain the shopware/conflicts metapackage. Whenever we find a dependency release that is incompatible with Shopware, we mark it as a conflict in that package, and Composer automatically skips it. This has worked quietly in the background the whole time. You have most likely benefited from it without ever knowing it exists.
About two weeks ago at the time of writing, Packagist changed how package releases are handled: published versions are now immutable. That is a reasonable change for the ecosystem as a whole, but it means we can no longer update the conflict rules the way we did before. When Twig 3.28 was released this weekend, we could not flag it as incompatible through Packagist anymore.
We have moved the conflicts package to our own infrastructure at https://shopware.github.io/conflicts/ to restore the functionality. The trade-off: this repository is not known to your project automatically. It needs to be added once on project level, which is exactly what the command above does.
What happens next?
At the time of writing, we are working on a fix that makes the Shopware administration compatible with the new Twig version. It will ship with one of the next Shopware releases, and the Twig conflict will be removed afterwards.
Going forward from Shopware 6.7.12.1, the conflicts repository will be included automatically, so this remains a one-time manual step for existing projects.
In the future we will find a more reliable, cleaner solution to the underlying challenges.
Frequently asked questions
Do I need to do this even if I'm on an older Shopware version?
Yes. The problem is independent of your Shopware version. Composer resolves Twig at install time, so every Composer-managed project needs the conflicts repository.
I always update through the administration. Do I need to do anything?
The Web Updater is already patched, so your updates are safe. Just make sure to download the newest version of the Web Installer from shopware.com/download if you are creating new projects using the Web Installer.
I use shopware-cli for updates. What do I need to do?
Update shopware-cli to the latest version before your next Shopware update. Older versions of shopware-cli will break your shop on update.
Is this a permanent extra step?
No. Adding the repository is a one-time action per existing project. Future Shopware versions and the current project template include it out of the box.
Will I still get security updates for dependencies?
Yes. Nothing changes about how dependency updates reach you. The conflicts package only excludes specific versions that are known to be incompatible with Shopware.
Need help?
If you run into problems applying the fix, reach out on our community Discord or through the Shopware Forum.
