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.
| Q | A
|-----------------|-----
| Branch? | 2.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | https://github.com/Sylius/Sylius/pull/18324
| License | MIT
This PR removes hard-coded references to the **Symfony Form CSRF field**
(`_token`)
from form templates and replaces them with dynamic rendering in the form
theme,
based on block prefixes. This ensures compatibility with Symfony Forms'
configurable
CSRF protection (`framework.form.csrf_protection.field_name`).
**Out of scope** of this PR:
- Hardcoded Security firewall CSRF parameters
(`_csrf_admin_security_token`,
`_csrf_shop_security_token`) in login templates — separate issue, will
be
addressed in a follow-up PR
- Hardcoded `_csrf_token` field name used by manual CSRF protection in
delete/cancel/transition actions — Sylius convention, not configurable
in Symfony
| Q | A
|-----------------|-----
| Branch? | 2.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
## Description:
When the request path equals the configured API route exactly (e.g.
/api/v2 — the Swagger UI docs URL), PathPrefixProvider::getPathPrefix()
produced an empty $pathElements array and
triggered a PHP warning on $pathElements[0].
This surfaced after upgrading api-platform/symfony to 4.3.x, where
SwaggerUiProcessor normalizes the OpenAPI doc — which calls
IriConverter::getIriFromResource() with request_uri =
/api/v2 and hits this code path.
Fix: return null early when no path segments remain after stripping the
API route prefix.
Tests: added two regression tests covering path == apiRoute and path ==
apiRoute . '/'.
| Q | A
|-----------------|-----
| Branch? | 2.2
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | n/a
| License | MIT
| Q | A
|-----------------|-----
| Branch? | 2.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| License | MIT
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Broadened dependency compatibility to support multiple versions of the
database migration bundle.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/Sylius/Sylius/pull/19007)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
| Q | A
|-----------------|-----
| Branch? | 2.3 <!-- see the comment below -->
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| 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
-->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Chores**
* Updated continuous integration to test against versions 2.2 and 2.3
* Removed CI workflows for deprecated versions 1.14 and 2.1
* Standardized Node.js version to 24.x across all CI jobs
* Updated pull request template branch guidance to target 2.2 and 2.3
branches
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
