| 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.
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.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.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | fixes#18986
| 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
-->
| Q | A
|-----------------|-----
| Branch? | 2.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | fixes#18986
| License | MIT