Sylius 2.3 brings changes you will notice both when managing your store and when planning its further development. You can prepare promotions for different markets more conveniently, control access to the panel and the API separately, and use a dark theme in the admin panel. The development team, meanwhile, gets Symfony 8 support, list configuration in PHP and a stable Payment Request mechanism for building payment integrations.
Version 2.3 was released on 28 September 2026. We look at the most important new features and explain what to check before upgrading an existing store.
Promotions tailored to each sales channel
If you sell in several markets, a single campaign may need different conditions. In one country you trigger the discount when two products are bought, in another only when four are. The way the discount is calculated can differ in the same way.
In Sylius 2.3, promotion rules and actions can be configured separately for individual channels within a single promotion. A rule determines when a customer qualifies for the offer, and an action defines the effect, for example applying a discount. A channel lets you separate the sales contexts the store handles.
For the marketing team, this means a shared campaign can be kept in one place, with conditions adapted to selected channels. You reduce the need to create separate promotions just to change one condition in a specific market.
Before launching such a campaign, it is worth writing out sample carts for each channel. Check when the discount should appear, when it should disappear and how it should work with other offers. The new configuration makes campaigns easier to manage, but whether it matches your pricing policy still needs to be verified.
Separate access to the admin panel and the API
An integration with an external system and an employee handling orders use the store in different ways. The integration communicates through the API, the interface for exchanging data between applications. The employee may only need the admin panel.
Sylius 2.3 introduces separate access settings for these two areas. You can create an administrator account with API-only access for an integration, or give an employee the panel without enabling API access. The system also protects you from accidentally removing your own access to the panel.
This is a useful separation when tidying up technical accounts. When reviewing integrations, you can establish what a given account is for and who is responsible for maintaining it. The access switches alone do not, however, replace control over the scope of permissions to specific data and operations. These also need to be matched to how the account is used.
Dark theme for the admin panel
A new switch in the top bar of the panel lets you choose a light or dark theme. The initial setting follows the operating system’s preferences, and a manual choice is remembered for future visits.
The change applies to the admin panel. It does not change how the store looks to shoppers. If your team spends a lot of time on orders, products and promotions, they can adapt the tool’s appearance to their own preferences.
For a store with an extensive panel, it is worth checking your own views and add-ons too. Custom tables, charts and status labels should remain readable in both colour schemes.
Symfony 8: environment upgrades can be planned in stages
Sylius 2.3 adds support for Symfony 8 while remaining compatible with Symfony 6.4 and 7.4. This matters for projects where upgrading the framework first requires adapting plugins or custom code. You can separate the Sylius upgrade from a later move to Symfony 8.
Sylius 2.3 itself requires PHP 8.3 or newer. This does not mean that every combination of newer dependencies will work on that minimum version. The target environment has to be chosen to suit the whole set of libraries the store uses.
From a business point of view, the most important thing is being able to organise the work. First the team establishes whether the current extensions are compatible with Sylius 2.3, and then plans further modernisation. This separates the scopes of change and makes it easier to find the cause of any problem during testing.
Product and order lists configured in PHP
“Grids” are configurable data lists, such as product or order listings. Their definitions specify columns, filters and available actions. These are exactly the elements that are often adapted to a particular store’s day-to-day work.
Around 35 lists in the Sylius core now have definitions in PHP. For developers, this means better editor hints, the possibility of using static analysis and easier refactoring. When you need to add a column with information useful to the customer service team, the configuration can be checked with the same tools used in the rest of the application.
YAML is still supported. The configuration format can be chosen globally or separately for a specific list, so migration can be carried out gradually. There is one important rule to remember, though: PHP and YAML definitions of the same list are not merged. When moving a list to PHP, you need to include the whole configuration you want to keep.
If you have custom filters, columns or actions, an inventory of them should be part of the upgrade plan. A standard list displaying correctly after deployment does not yet confirm that all your custom improvements are available.
Payment Request as a stable foundation for payment integrations
The Payment Request mechanism is no longer experimental and is now covered by Sylius’s backward compatibility rules. This is important news for teams building payment integrations and for plugin authors: they can base their development on an interface covered by the project’s standard maintenance rules.
In practice, the uncertainty resulting from the experimental status is reduced. When you plan a new integration, the team can treat Payment Request as a stable foundation for its implementation.
This change does not mean that any payment provider is added automatically, nor does it confirm that every existing plugin is compatible. You still need to check the specific module and test the whole transaction flow: starting the payment, the provider’s response, returning to the store and updating the order status. Separate scenarios should cover an interrupted payment and a retry.
How to prepare your store for the upgrade to Sylius 2.3
The scope of work depends mainly on your current version, the extensions you use and the number of custom modifications. The official upgrade guide from 2.2 to 2.3 is a good starting point for a technical assessment. For an older store, you also need to take into account changes from earlier releases.
- Check the environment and dependencies. Verify the PHP and Symfony versions and plugin compatibility. Include the production and test environments and the application build process.
- Collect your custom modifications. Pay special attention to payments, promotions, administrator accounts and list configuration. The upgrade guide points out, among other things, new methods in interfaces that may require changes in your own implementations.
- Prepare a test environment. Reproduce the most important sales and integration scenarios there, using the appropriate accounts and test data.
- Test the purchase process. Go from adding a product to the cart, through a promotion and choosing delivery, to payment and passing the order to external systems.
- Check your team’s work. Verify permissions, data lists and your own panel elements. With several channels, repeat the tests for the conditions that apply in each of them.
- Plan the deployment and monitoring. Agree on an upgrade window, a way to restore the previous state, and monitoring of errors and orders after the new version goes live.
When the new features will be especially useful
Sylius 2.3 is worth analysing especially if you are expanding sales into several markets, extending integrations or often changing the tools available in the panel. Promotions configured per channel meet the needs of the sales team, and separating access to the panel and the API helps organise how the system is used.
For the technical team, the stabilisation of Payment Request and the direction of configuration in PHP also matter. Combined with support for newer Symfony versions, they provide a basis for planning further work on the store.
The timing of the upgrade is best decided after checking the dependencies and the scope of changes. If you want to assess what Sylius 2.3 will bring to your store, let’s talk about the upgrade and further development. We will start with your current configuration, integrations and the processes that matter most to your team.
Sources
https://sylius.com/blog/news/sylius-2-3-is-here
https://github.com/Sylius/Sylius/releases/tag/v2.3.0
https://github.com/Sylius/Sylius/blob/v2.3.0/UPGRADE-2.3.md
