| Q | A
|-----------------|-----
| Branch? | 2.0
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
<!--
- Bug fixes must be submitted against the 1.13 branch
- Features and deprecations must be submitted against the 1.14 branch
- Features, removing deprecations and BC breaks must be submitted
against the 2.0 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
-->
Extracted from https://github.com/Sylius/Sylius/pull/17034
| Q | A
|-----------------|-----
| Branch? |2.0
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
<!--
- Bug fixes must be submitted against the 1.13 branch
- Features and deprecations must be submitted against the 1.14 branch
- Features, removing deprecations and BC breaks must be submitted
against the 2.0 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.0
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | n/a
| License | MIT
<!--
- Bug fixes must be submitted against the 1.13 branch
- Features and deprecations must be submitted against the 1.14 branch
- Features, removing deprecations and BC breaks must be submitted
against the 2.0 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.0
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | n/a
| License | MIT
| Q | A
|-----------------|-----
| Branch? | 2.0
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Related tickets |
| License | MIT
<!--
- Bug fixes must be submitted against the 1.13 branch
- Features and deprecations must be submitted against the 1.14 branch
- Features, removing deprecations and BC breaks must be submitted
against the 2.0 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
-->
In the future Sylius stack, some default Twig hooks are defined to
render a form with `form_widget(form)`.
Indeed, most of the time, for custom resources we create for an
e-commerce, we do not need to improve the default form template
rendering. Moreover, the user could see this as an issue of his
configuration cause the creation/edition page will be empty even if he
has defined his Form builder.
So in this PR, I've added the same twig hooks as Sylius stack to make
the transition easier and to allow empty configuration of Twig hooks to
render a form a Sylius developer in an end application.
Moreover, I've disabled this default Twig hooks form rendering in out of
the box Sylius resources.
An example with default form rendering
| Q | A
|-----------------|-----
| Branch? | 2.0
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | n/a
| License | MIT
| Q | A
|-----------------|-----
| Branch? | 2.0
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | n/a
| License | MIT
| Q | A
|-----------------|-----
| Branch? | 2.0
| Bug fix? | no
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Related tickets | n/a
| License | MIT
<!--
- Bug fixes must be submitted against the 1.13 branch
- Features and deprecations must be submitted against the 1.14 branch
- Features, removing deprecations and BC breaks must be submitted
against the 2.0 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.0
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | none
| License | MIT
$publicDir is a value of `%sylius_core.public_dir%` which is a string
value (usually a `sylius_core.public_dir:
'%kernel.project_dir%/public'`), not a bool value. Which now causes
assets to be installed into a wrong directory.
Pre-fix:
```bash
➜ bin/console sylius:install:assets --no-interaction;
Installing Sylius assets for environment dev.
Created "/Users/username/Code/Sylius-Standard/1/assets" directory.
Created "/Users/username/Code/Sylius-Standard/1/bundles" directory.
```
Post-fix:
```bash
➜ bin/console sylius:install:assets --no-interaction;
Installing Sylius assets for environment dev.
Created "/Users/username/Code/Sylius-Standard/public/assets" directory.
Created "/Users/username/Code/Sylius-Standard/public/bundles" directory.
```
This PR has been generated automatically.
For more details see
[upmerge_pr.yaml](/Sylius/Sylius/blob/1.13/.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/payment-request -m "Resolve conflicts between 2.0 and payment-request"
```
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.0
| Bug fix? | kinda
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Related tickets | -
| License | MIT
This PR has been generated automatically.
For more details see
[upmerge_pr.yaml](/Sylius/Sylius/blob/1.13/.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/payment-request -m "Resolve conflicts between 2.0 and payment-request"
```
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.
