Every composer update or composer install on a Composer-managed Shopware project can now pull in Twig 3.28 and break your administration panel. Add the Shopware conflicts repository to your project now to prevent this. The fix takes one minute. If your admin is already broken, the same command will repair it.
The Fix Run This in Your Project Root
If you're in a hurry, here's the complete fix. Run this single command in your Shopware project root directory:
This adds the Shopware conflicts repository to your composer.json, installs the shopware/conflicts metapackage, and immediately tells Composer which package versions (including Twig 3.28) are incompatible with Shopware. After this, composer update will automatically skip broken dependency versions.
Who Is Affected?
- Self-hosted, Composer-managed Shopware projects any version
- Anyone running
composer updatewithout a lock file pinning Twig below 3.28 - Anyone installing Shopware using an older version of
shopware-cli - New installations that don't yet include the fix
- Anyone who hasn't yet applied the conflicts repository
- Shops updating via the Web Updater button in the Shopware admin (already patched)
- Updates and installs using the latest version of shopware-cli
- Projects that have already applied the fix above
- Stores on Shopware 6.7.12.1 or later (conflicts repository included by default)
What Happened The Full Story
To understand this issue properly, you need to know a bit about how Shopware handles its PHP dependencies and about a recent change Packagist made to the PHP ecosystem.
Why Twig breaks Shopware's administration
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 Shopware's dependencies, your store gets it immediately without waiting for a new Shopware release.
Twig is a special case. Shopware's extension system including features like sw_include needs access to internal Twig APIs that are not covered by Twig's own backwards compatibility promise. Internal APIs can change in any release, including patch releases. Twig 3.28 changed exactly this kind of internal API, and the Shopware administration relies on it.
Why the usual safety net didn't catch it
Since 2021, Shopware has maintained a shopware/conflicts metapackage. Whenever an incompatible dependency version is found, it's marked as a conflict in that package and Composer automatically skips it. This has worked silently in the background for years, and you've likely benefited from it without ever knowing it existed.
About two weeks before this incident, Packagist changed how package releases are handled: published versions are now immutable. This is a sensible security improvement for the PHP ecosystem as a whole but it means Shopware can no longer update the conflict rules through Packagist in the same way. When Twig 3.28 was released, Shopware could not flag it as incompatible through Packagist's existing mechanism in time.
Shopware's response was to move the conflicts package to their own infrastructure at https://shopware.github.io/conflicts/ which restores full functionality. The trade-off: this repository isn't automatically known to your project. It needs to be added once per project which is exactly what the command above does.
Step-by-Step: How to Apply the Fix Safely
This is the directory containing your composer.json file typically the root of your Shopware installation where you run all Composer commands.
Copy and run the command from the green box above. It does three things in sequence: adds the Shopware conflicts repository to your composer.json, requires the shopware/conflicts metapackage, and immediately updates it so the conflict rules are active.
# Step 1 Add the conflicts repository composer config repositories.shopware-conflicts \ '{"type":"composer","url":"https://shopware.github.io/conflicts/"}' \ --file composer.json # Step 2 Require the conflicts metapackage composer require shopware/conflicts --no-update # Step 3 Apply the conflict rules immediately composer update shopware/conflicts
After the command completes, check that shopware/conflicts appears in your composer.json under require, and that the conflicts repository appears under repositories. You can also run composer show shopware/conflicts to confirm the package is installed.
Commit both files to your version control. This ensures the fix applies across all environments staging, production, and any CI/CD pipelines not just the machine where you ran the command.
If your deployment workflow uses shopware-cli, update it to the latest version before your next Shopware update or installation. Older versions of shopware-cli will break your shop on update. Run shopware-cli update or download the latest release from the official repository.
Timeline What's Happening and What's Coming
shopware/conflicts metapackage introducedShopware creates the conflicts metapackage to automatically block incompatible dependency versions from reaching production stores. Works silently for years without anyone noticing.
A security-motivated change to the Packagist ecosystem. Reasonable for the PHP community overall, but it breaks Shopware's existing mechanism for publishing conflict rules.
Twig 3.28 changes an internal API that Shopware's administration relies on. Without the safety net working, any composer update can now pull in this incompatible version.
Shopware publishes the fix the conflicts repository moves to https://shopware.github.io/conflicts/ and must be manually added to existing projects once. Shopware publishes the one-command fix.
From Shopware 6.7.12.1 onwards, the conflicts repository is included in the project template automatically. The manual step is no longer required for new projects or stores upgraded to this version.
Shopware is working on a permanent fix to make the administration compatible with the new Twig version. Once this ships in a Shopware release, the Twig conflict will be removed from the conflicts package.
shopware/conflicts package only excludes specific versions known to be incompatible with Shopware. All other dependency updates including security patches continue to reach your store exactly as before. You are not giving anything up by adding this repository.
Frequently Asked Questions
Why does Twig 3.28 break Shopware?
Shopware's extension system including features like sw_include uses internal Twig APIs that are not covered by Twig's backwards compatibility promise. Twig 3.28 changed one of these internal APIs that Shopware's administration relies on. Because internal APIs can change in any release (including patch releases), this kind of breakage is possible whenever Shopware hasn't blocked a specific Twig version via the conflicts package.
Do I need to apply the fix even if I'm on an older Shopware version?
Yes. The problem is completely independent of your Shopware version. Composer resolves Twig at install time based on what's available in your configured repositories, not based on your Shopware version. Every Composer-managed Shopware project needs the conflicts repository added, regardless of whether you're on Shopware 6.4, 6.6, or 6.7.
I always update through the Shopware administration do I need to do anything?
No. The Web Updater (the Update button inside your Shopware administration panel) is already patched and is not affected by this issue. However, if you ever need to use the Web Installer to create new projects, download the newest version from shopware.com/download older versions of the Web Installer do not yet include the fix.
I use shopware-cli for deployments what do I need to do?
Update shopware-cli to the latest version before your next Shopware update or installation. Older versions of shopware-cli will pull in Twig 3.28 and break your shop during the update process. Run shopware-cli update or download the latest binary from the official GitHub releases page.
Is the fix permanent, or do I need to keep doing this?
Adding the conflicts repository is a one-time action per project. Once you've committed the updated composer.json and composer.lock, the fix applies to all environments that use those files. From Shopware 6.7.12.1 onwards, the conflicts repository is included automatically in new projects and upgrades so this manual step will not be required for future projects.
Will this affect my ability to receive security updates for dependencies?
No. The shopware/conflicts metapackage only excludes specific versions that are known to be incompatible with Shopware. All other dependency updates including security patches for Twig, Symfony, and all other packages continue to reach your store normally. You are not blocking anything other than the specific incompatible releases.
Can Mavenbird apply this fix for me?
Yes. If you're an existing Mavenbird client on a support retainer, contact us and we'll apply the fix to your staging and production environments, validate your Composer dependency tree, and commit the updated files to your repository. If you're not yet a Mavenbird client, get in touch this is a straightforward engagement and we can typically resolve it the same day.
Need help applying the fix or keeping your Shopware store protected?
Mavenbird's certified Shopware team can apply the fix, validate your dependencies, and set up proactive monitoring so the next Shopware incident doesn't become a production outage.
