| Q | A
|-----------------|-----
| Branch? | php-grid-configuration
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no <!-- don't forget to update the UPGRADE-*.md file
-->
| 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.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 -->
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.2 -m "Resolve conflicts between 2.1 and 2.2"
```
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 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.2 -m "Resolve conflicts between 2.1 and 2.2"
```
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.
| Q | A
|-----------------|-----
| Branch? | 2.1 <!-- see the comment below -->
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| 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.1 <!-- see the comment below -->
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| 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.1 <!-- see the comment below -->
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| 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
<!--
- 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? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| 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 | fixes #X
| License | MIT
**Description**
So far it wasnt possible to translate the "Add" and "Delete" button when
creating Product Attributes with the "Select" type.
<img width="1289" height="884" alt="image"
src="https://github.com/user-attachments/assets/1e06ff47-4b88-4663-a7c1-61cca8c67464"
/>
| Q | A
|-----------------|-----
| Branch? | 2.3
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
Extends the admin navbar notifications contract so plugins can surface
clickable, parameterized notifications without overriding the navbar
template.
Each notification returned by a `NotificationProviderInterface` may now
carry five optional keys honored by the default template:
- `message_parameters` — passed to `|trans`
- `uri` (string, optional) — plain URI used as the notification link,
takes precedence over `route` when both are present
- `route` + `route_parameters` — when present, the item renders as `<a
href="{{ path(...) }}">`
- `translation_domain` — passed to `|trans`
- `type` (`info` | `warning` | `danger`, default `danger`) — drives
status-dot color
The loop body in `notifications.html.twig` is now emitted through a twig
hook (`sylius_admin.common.component.navbar.items.notifications.item`,
default node), so plugins can also fully replace the item rendering by
registering their own node with higher priority.
Fully backward compatible: existing providers returning only `message`
render identically.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Navbar notifications are now rendered via pluggable items, supporting
clickable links (URI or route), translated messages with parameters, and
configurable status types (info, warning, danger; default danger).
* **Tests**
* Added tests to ensure notification payloads—including optional fields
and routing—are preserved end-to-end.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/Sylius/Sylius/pull/19015?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
| Q | A
|-----------------|-----
| Branch? | 2.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | https://github.com/Sylius/Sylius/issues/19013
| License | MIT
### Summary
`GET /api/v2/shop/products/{code}` returned **404** for an `enabled`
product whenever
*all* of its associated products (across all its associations) were
disabled.
Root cause: `EnabledWithinProductAssociationExtension` applied
`andWhere('product.associations IS EMPTY OR associatedProduct.id IS NOT
NULL')`
both in `applyToCollection` and `applyToItem`. For an item query, the OR
collapsed
to `false` whenever the product had associations but none of their
associated
products were enabled — excluding the product itself from the result.
### Fix
Removed the `andWhere` from the extension. Eager-loading of enabled
associated
products (`LEFT JOIN ... WITH associatedProduct.enabled = true`) stays
in place
and mirrors the convention used by the neighbouring
`EnabledVariantsExtension`.
| Q | A
|-----------------|-----
| Branch? | 2.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
A missing interface method signature `appendError` is missing in the
`ResponseCheckerInterface`, I don't know why PHPStan did not spot this
but this method is used here :
https://github.com/Sylius/Sylius/blob/2.2/src/Sylius/Behat/Client/ApiPlatformClient.php#L357
therefore the interface method must exists.
