Symfony 7 and Sylius 2.0: What Changes for Developers

Sylius 2.0 supports both Symfony 6.4 LTS and Symfony 7.1+.

For developers who've been running Sylius 1.x on Symfony 5 or 6, this means a significant stack modernization. Let's break down what Symfony 7 brings to the table and what it means concretely for your Sylius projects.

Symfony 7: What's Different

Symfony 7 was released in November 2023. It's the "clean" major version that removes everything deprecated in the 6.x cycle. If you've been ignoring deprecation notices, Symfony 7 is where they become fatal errors.

PHP 8.2 Minimum

Symfony 7 requires PHP 8.2+, and Sylius 2.0 aligns with that minimum. If your production servers still run PHP 8.1, you'll need to upgrade your runtime first.

This is generally a good thing: PHP 8.2 brings readonly classes and significant performance improvements, and if you move to PHP 8.3 you also get typed class constants and the json_validate() function.

All Deprecations Removed

Every method, class, and configuration option that was marked @deprecated in Symfony 6.x is gone in Symfony 7. The most impactful removals for Sylius projects include:

• Security: The old security.encoders configuration is removed. You must use security.password_hashers.
• Mailer: SwiftMailer integration has been removed (the library itself was abandoned by its maintainers in 2021). symfony/mailer is the standard replacement in Sylius 2.0.
• Routing: Docblock annotations (@Route in comments, relying on SensioFrameworkExtraBundle) are no longer supported. Use PHP 8 attributes #[Route], which Symfony has supported since 5.2.
• DI: Some container configuration shortcuts have been removed.

New Attributes-First Approach

Symfony 7 doubles down on PHP attributes everywhere: routing, security voters, event subscribers, DI configuration. If your Sylius project still uses YAML or annotation-based configuration for custom controllers and services, now is the time to modernize.

What This Means for Sylius 2.0

Twig Hooks Become the Recommended Customization Approach

This change is Sylius-specific, provided by the sylius/twig-hooks package (which itself supports Symfony 6.4 and 7.x). The old pattern of overriding entire Twig templates by placing files in templates/bundles/ still works but is discouraged in favor of Twig Hooks: a system where you register small template fragments that hook into specific extension points.

Twig Hooks primarily replaces the older Sylius Template Events and Sonata Block Events systems. The benefit: your customizations are more granular and survive Sylius core updates more cleanly. The cost: existing template overrides need to be rewritten if you want to follow the new approach.

Symfony Workflow Replaces winzou

Sylius 1.x relied on winzou/state-machine-bundle for order, payment, and shipping workflows. Sylius 2.0 uses Symfony's native Workflow component.

Key differences for developers:

• Configuration moves from winzou_state_machine to framework.workflows
• Callbacks become event subscribers listening to workflow.transition events
• Guards use Symfony's expression language instead of service callbacks
• The Workflow component has better tooling: the workflow:dump command generates visual diagrams

Note: the winzou/state-machine-bundle package has been moved to the suggested dependencies in Sylius 2.0 and can still be installed manually if needed, but the core Sylius workflows have all migrated to Symfony Workflow.

Symfony UX Replaces jQuery

The frontend migration isn't just a Sylius decision: it aligns with the broader Symfony ecosystem direction. Symfony UX (Turbo + Stimulus) is the official approach to frontend interactivity in Symfony applications.

For Sylius developers, this means:

• No more jQuery dependency
• Interactive features use Stimulus controllers instead of inline JS
• Page updates use Turbo Frames and Streams for partial page refreshes
• The asset pipeline changes (Webpack Encore configuration updates; Sylius 2.0 still uses Webpack Encore)

API Platform 4

Sylius 2.0 moves from API Platform 2.7 to API Platform 4, which brings:

• Simplified resource configuration (new XML schema metadata/resources-3.0)
• State providers and processors replacing the older data providers and data persisters
• Improved OpenAPI documentation generation
• Improved JSON:API and GraphQL support at the API Platform level (note: Sylius 2.0 doesn't expose GraphQL endpoints by default, but you can enable them)

If you've written custom API Platform data providers, data persisters, or data transformers, they'll need to be rewritten as state providers, state processors, or serializer context builders. Namespaces change accordingly (for example, classes under Sylius\Bundle\ApiBundle\DataProvider move to Sylius\Bundle\ApiBundle\StateProvider). Sylius also prefixes all its serialization groups with sylius: in 2.0, so any custom resource that extends Sylius groups needs to be updated.

Practical Migration Path

Here's the approach I recommend:

Phase 1: Prepare on Sylius 1.x (1–2 weeks, depending on project state)

Before touching Sylius 2.0, clean up your current codebase:

1. Upgrade to the latest Sylius 1.x release (1.14 LTS if you're not already there)
2. Run PHPUnit with SYMFONY_DEPRECATIONS_HELPER=strict
3. Fix all Symfony deprecations: encoders → password hashers, annotations → attributes, SwiftMailer → symfony/mailer
4. Make sure your tests pass green

Phase 2: Audit (1–2 days)

Run a comprehensive audit of your project to understand the full migration scope:

• Count template overrides
• List winzou state machine customizations
• Check plugin compatibility
• Inventory frontend customizations

This is where Sylius Upgrade Analyzer helps. The CLI tool automates this entire audit, scanning your codebase with 49 analyzers organized into 5 thematic families (Templates & Frontend, Deprecations & Breaking Changes, Plugins, Grid & Resource, API Platform) and producing a report with effort estimations. It runs locally, so your code doesn't leave your machine.

Phase 3: Backend Migration (1–4 weeks)

Tackle backend changes in order of dependency:

1. Update composer.json to require Sylius 2.0
2. Migrate state machine configuration and callbacks
3. Update payment gateway integrations
4. Fix any remaining deprecated API usages

Phase 4: Frontend Migration (1–4 weeks)

This can often run in parallel with backend work:

1. Replace Semantic UI classes with Bootstrap 5
2. Convert jQuery code to Stimulus controllers
3. Update asset build configuration
4. Test all interactive features (cart, checkout, admin)

Phase 5: Plugin Updates & QA (1–2 weeks)

Update all plugins, run full regression tests, and validate payment flows. Remember that plugin compatibility varies: some (like several BitBag plugins) already have stable 2.x releases, others are still being ported.

The Bottom Line

Symfony 7 + Sylius 2.0 is a major modernization. The resulting stack is cleaner, more maintainable, and better aligned with the PHP ecosystem's direction. The migration effort is real but manageable with proper planning.

The biggest risk isn't any single change: it's underestimating the combined scope. Audit first, plan methodically, and you'll come out the other side with a much better codebase.