DBAL 4.x has stricter type checking that doesn't accept DateTimeImmutable
in datetime fields. Until the codebase is fully compatible with DBAL 4.x,
we need to use DBAL 3.x for DoctrineBundle 2.x tests.
(cherry picked from commit 4abdd1c2a0)
This option was removed in DoctrineBundle 3.0 as it became a no-op
when using native lazy objects (introduced in ORM 3.x/DBAL 4.x).
(cherry picked from commit 2c0b64e89c)
| Q | A
|-----------------|-----
| Branch? | 2.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no<!-- don't forget to update the UPGRADE-*.md file
-->
| Related tickets | extracted from
https://github.com/Sylius/Sylius/pull/18803, partially
https://github.com/Sylius/Sylius/issues/18490
| License | MIT
<!--
- Bug fixes must be submitted against the 2.2 branch
- Features and deprecations must be submitted against the 2.3 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Refactor**
* Migrated state machine service configurations from XML format to
PHP-based configuration files for improved maintainability and
consistency.
* Updated the service loader to support PHP file-based configuration
instead of XML.
* **Tests**
* Streamlined test coverage to focus on YAML-based service configuration
validation paths.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
| Q | A
|-----------------|-----
| Branch? | 2.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | https://github.com/Sylius/Sylius/pull/18971,
https://github.com/Sylius/Sylius/issues/18760
| License | MIT
This re-targets the already-open #18971 (originally against `symfony-8`)
onto `2.3`, since `2.3` is the development branch for the next release.
The original commit is cherry-picked as-is to preserve authorship.
`symfony/proxy-manager-bridge` and `friendsofphp/proxy-manager-lts` are
removed — they are no longer needed, as lazy services rely on PHP's
native lazy proxies from `symfony/var-exporter` (default since Symfony
6.4).
Adds an `UPGRADE-2.3.md` note under **Dependencies**.
<!--
- Bug fixes must be submitted against the 2.2 branch
- Features and deprecations must be submitted against the 2.3 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added upgrade guidance for dependency changes in version 2.3.
* **Chores**
* Removed proxy manager bridge dependencies; lazy services now use
native PHP lazy proxies for improved performance and reduced external
dependencies.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
| Q | A
|-----------------|-----
| Branch? | 2.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no<!-- don't forget to update the UPGRADE-*.md file
-->
| Related tickets | https://github.com/Sylius/Sylius/pull/18903,
https://github.com/Sylius/Sylius/issues/18760
| License | MIT
This PR backports the robo removal already done on the `symfony-8`
branch (#18903) to `2.3`, as it makes sense to have it on `2.3` already
<!--
- Bug fixes must be submitted against the 2.2 branch
- Features and deprecations must be submitted against the 2.3 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Refactored CI/CD workflows to dynamically discover and test packages
instead of using a task runner approach.
* Simplified package test execution with per-package working directories
and conditional test execution.
* Removed external task runner dependency to streamline the build
pipeline.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
| Q | A
|-----------------|-----
| Branch? | 2.2
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? |
| Related tickets |
| License | MIT
<!--
- Bug fixes must be submitted against the 2.2 branch
- Features and deprecations must be submitted against the 2.3 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
| Q | A
|-----------------|-----
| Branch? | 2.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
I encountered an issue where I'm using my own specific
`sylius.resolver.product_variant`, I discovered that the component
Product Summary was using the default resolver instead of the composite
one.
The PR is aiming to fix this.
| Q | A
|-----------------|-----
| Branch? | 2.3
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Related tickets | mentioned in #18142
| License | MIT
## Summary
This PR implements **Alternative A** proposed in #18142 — a dedicated
`CatalogPricesCalculatorInterface` to semantically separate catalog
display pricing from cart/order pricing.
The original PR introduced a plain service alias without any PHP-level
distinction. After review feedback from @diimpp, the approach was
refined: instead of an invisible alias, we introduce a **real PHP
contract** that communicates intent and enables clean decoration via
Symfony's DI.
## Problem
Sylius currently uses a single `sylius.calculator.product_variant_price`
for both catalog display and cart/order processing. Decorating it to
customize catalog display (e.g. B2B list prices, EU OSS VAT, Omnibus
compliance) inevitably affects cart totals, order recalculation, and the
promotion engine — a tight coupling that every other major PHP
e-commerce framework (Magento, Shopware, PrestaShop, WooCommerce) has
already solved.
## Solution
### New interface
```php
namespace Sylius\Component\Core\Calculator;
/**
* Calculates prices for catalog display purposes (product listings, detail pages, API responses).
*
* This is intentionally distinct from ProductVariantPricesCalculatorInterface used in cart/order
* processing, allowing independent customization of display pricing (e.g., B2B list prices,
* EU Omnibus Directive compliance, geo-pricing, OSS VAT destination-based rules).
*
* Decorate this interface to customize catalog display pricing without any risk of side effects
* on cart totals, order processing, or promotion engines.
*/
interface CatalogPricesCalculatorInterface extends ProductVariantPricesCalculatorInterface
{
}
```
`ProductVariantPriceCalculator` implements both interfaces — **zero
functional change** for existing installations.
### Catalog-facing consumers updated
| Service / Class | Context |
|---|---|
| `sylius.twig.extension.price` / `PriceExtension` | Twig price filters
|
| `sylius_api.normalizer.product_variant` / `ProductVariantNormalizer` |
API serialization |
| `sylius_shop.twig.component.product.price` / `PriceComponent` | Shop
price component |
| `sylius_shop.twig.component.product.card` / `CardComponent` | Shop
product card |
| `sylius.provider.product_variant_map.price` /
`ProductVariantPriceMapProvider` | JS variant switching |
| `sylius.provider.product_variant_map.original_price` /
`ProductVariantOriginalPriceMapProvider` | JS variant switching |
| `sylius.provider.product_variant_map.lowest_price` /
`ProductVariantLowestPriceMapProvider` | JS variant switching |
### Cart/order consumers intentionally unchanged
| Service | Context |
|---|---|
| `sylius.order_processing.order_prices_recalculator` | Cart/order
processing |
| `sylius.filter.promotion.price_range` | Promotion engine |
## Result
Developers can now decorate **only catalog display pricing** without
touching cart totals:
```php
$services
->decorator(CatalogPricesCalculatorInterface::class)
->class(MyB2BCatalogPriceCalculator::class)
;
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Deprecations**
* Passing the legacy product-variant pricing calculator into
catalog-facing classes now emits deprecation warnings; implementors
should migrate to the new catalog-focused calculator interface (required
in Sylius 3.0).
* **Refactor**
* Introduced a catalog-focused price calculator interface and adapted
core components to accept it.
* **Chores**
* Core service wiring updated to use the new catalog calculator for
catalog/listing/price components.
* **Documentation**
* Added upgrade guide section with migration instructions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Add a dedicated interface for catalog-facing price calculations, distinct from
ProductVariantPricesCalculatorInterface which is used in cart/order processing.
This semantic contract allows developers to decorate catalog display pricing
independently (e.g. EU OSS VAT, B2B list prices, Omnibus Directive compliance)
without risk of side effects on cart totals or order processing.
ProductVariantPriceCalculator now implements both interfaces, preserving full
backward compatibility while satisfying both injection points.
| Q | A
|-----------------|-----
| Branch? | 2.3
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
<!--
- Bug fixes must be submitted against the 1.14 or 2.1 branch
- Features and deprecations must be submitted against the 2.2 branch
- Make sure that the correct base branch is set
To be sure you are not breaking any Backward Compatibilities, check the
documentation:
https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->
Currently, we are not able to define product attributes and product
options in several locales.
This PR allows us to use the same system we already defined in Taxon
fixtures.
Example:
```yaml
dress_option:
name: product_option
options:
custom:
- name: 'Dress height'
code: 'dress_height'
values:
dress_height_petite: 'Petite'
dress_height_regular: 'Regular'
dress_height_tall: 'Tall'
translations:
fr_FR:
values:
dress_height_petite: 'Petite'
dress_height_regular: 'Moyenne'
dress_height_tall: 'Grande'
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Product attributes and options now support per-locale display names
and per-locale option value labels via a translations configuration.
* **Fixtures**
* Fixture schemas accept a translations section for attributes and
options.
* Sample fixtures updated with en_US/fr_FR translations for attributes
and option values.
* **Tests**
* Added/updated tests verifying locale-dependent names and
locale-specific option value labels.
[](https://app.coderabbit.ai/change-stack/Sylius/Sylius/pull/19004)
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR has been generated automatically.
For more details see
[upmerge_pr.yaml](/Sylius/Sylius/blob/2.3/.github/workflows/upmerge_pr.yaml).
**Remember!** The upmerge should always be merged with using `Merge pull
request` button.
In case of conflicts, please resolve them manually with usign the
following commands:
```
git fetch upstream
gh pr checkout <this-pr-number>
git merge upstream/2.3 -m "Resolve conflicts between 2.2 and 2.3"
```
If you use other name for the upstream remote, please replace `upstream`
with the name of your remote pointing to the `Sylius/Sylius` repository.
Once the conflicts are resolved, please run `git merge --continue` and
push the changes to this PR.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added admin "show" pages for products, customers, orders, shipments
and catalog promotions.
* Checkout blocks placing orders when selected payment method is
unavailable for the active channel.
* **Bug Fixes**
* Address updates accept province-name-only inputs.
* Flash alert class mapping corrected.
* Restored missing admin show titles and missing-translation UI
indicators.
* **Tests**
* Added UI/API and unit tests plus fixtures for channel-based payment
eligibility and province/address behaviors.
* **Documentation**
* Updated upgrade notes covering locale resolution and payment-method
eligibility.
* **Chores**
* Mailer manager services made public.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
