* 3.4:
Fix json-encoding when JSON_THROW_ON_ERROR is used
[HttpFoundation] work around PHP 7.3 bug related to json_encode()
[Security] added support for updated \"distinguished name\" format in x509 authentication
This PR was merged into the 3.4 branch.
Discussion
----------
Fix json-encoding when JSON_THROW_ON_ERROR is used
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
As hinted in #31860 by @lt
Commits
-------
d18f42c409 Fix json-encoding when JSON_THROW_ON_ERROR is used
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpFoundation] work around PHP 7.3 bug related to json_encode()
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #31447
| License | MIT
| Doc PR | -
I know, this doesn't make any sense.
`json_encode` embeds global state behind the scene :(
For reference, I asked on php-internals what they think about this:
https://externals.io/message/105653#105838
Commits
-------
e6e63017f0 [HttpFoundation] work around PHP 7.3 bug related to json_encode()
This PR was merged into the 4.2 branch.
Discussion
----------
Fix inconsistency in json format regarding DST value
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
In absence of a known time zone we might or might not have DST.
If DST doesn't exist (eg, server has timezone set on GMT) the current test fails,
Becasue PHP doesn't dump `dst_savings` in the `IntlTimeZone` objects.
This patch takes care of this known point.
Sponsored-by: Platform.sh
Commits
-------
38a5b2c943 Fix inconsistency in json format regarding DST value
The `$expected` template seems not to be consistent.
It will change when the DST value is 0 (it'll not have `dst_savings` for
example)
This patch takes care of the issue, by adding proper condition.
Sponsored-by: Platform.sh
This PR was submitted for the master branch but it was squashed and merged into the 3.4 branch instead (closes#31407).
Discussion
----------
[Security] added support for updated "distinguished name" format in x509 authentication
RFC 2253 (https://tools.ietf.org/html/rfc2253)
issue: https://github.com/symfony/symfony/issues/31406
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #31406
| License | MIT
| Doc PR |
Commits
-------
bdbac2c6e6 [Security] added support for updated \"distinguished name\" format in x509 authentication
This PR was squashed before being merged into the 4.2 branch (closes#31786).
Discussion
----------
[Translation] Fixed case sensitivity of lint:xliff command
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | -
| License | MIT
| Doc PR | (not needed)
I was checking some errors of `lint:xliff` (https://travis-ci.org/EasyCorp/EasyAdminBundle/jobs/540053551#L657) and saw this:
```
ERROR in src/Resources/translations/EasyAdminBundle.sr_RS.xlf
* There is a mismatch between the language included in the file name ("EasyAdminBundle.sr_RS.xlf") and the "sr-rs" value used in the "target-language" attribute of the file.
ERROR in src/Resources/translations/EasyAdminBundle.zh_CN.xlf
* There is a mismatch between the language included in the file name ("EasyAdminBundle.zh_CN.xlf") and the "zh-cn" value used in the "target-language" attribute of the file.
```
This was suspicious, so I checked the XLIFF standard and it says (http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#target-language):
```
target-language:
Unlike the other XLIFF attributes, the values are not case-sensitive.
```
So, it's valid that `zh-cn` is the target language and `zh-CN` is the file extension. This PR fixes that.
Commits
-------
ec690b2145 [Translation] Fixed case sensitivity of lint:xliff command
This PR was merged into the 4.2 branch.
Discussion
----------
Simplify code - catch \Throwable capture all exceptions
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | no
| License | MIT
| Doc PR |
---
This is a legacy when we did support PHP 5.X
Commits
-------
648c6949fc Simplify code - catch \Throwable capture all exceptions
This PR was squashed before being merged into the 3.4 branch (closes#31813).
Discussion
----------
fix type hint for salt in PasswordEncoderInterface
See issue #31812
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #31812
| License | MIT
| Doc PR | none
Pretty self-explanatory
Commits
-------
0e741f9600 fix type hint for salt in PasswordEncoderInterface
This PR was submitted for the 4.2 branch but it was merged into the 3.4 branch instead (closes#31802).
Discussion
----------
update italian validator translation
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | none
This PR just takes the italian translation for validators up to date with english one.
Commits
-------
2b95fcaa6b update italian validator translation
This PR was merged into the 3.4 branch.
Discussion
----------
Use willReturn() instead of will(returnValue())
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
In a recent PR, fabbot complained about the usage of will(returnValue()) in test cases that I haven't changed. In this PR, I've applied the PHP CS Fixer's `php_unit_mock_short_will_return` fixer on the whole codebase.
Commits
-------
4fb67df612 Use willReturn() instead of will(returnValue()).
This PR was merged into the 3.4 branch.
Discussion
----------
[github] define 4.4 as the feature branch
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
And let's use master for preparing 5.0.
Commits
-------
30b560c4df [github] define 4.4 as the feature branch
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpFoundation] Do not set X-Accel-Redirect for paths outside of X-Accel-Mapping
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
https://github.com/symfony/symfony/pull/31604 but refactored for 3.4
Commits
-------
a662f61e08 [HttpFoundation] Do not set X-Accel-Redirect for paths outside of X-Accel-Mapping
Currently BinaryFileResponse, when configured with X-Accel-Redirect sendfile type,
will only substitute file paths specified in X-Accel-Mapping. But if the provided
file path does not have a defined prefix, then the resulting header will include
the absolute path. Nginx expects a valid URI, therefore this will result in an
issue that is very hard to detect and debug as it will not show up in error logs
and instead the request would just hang for some time and then be re-served
without query parameters(?).
This PR was submitted for the master branch but it was merged into the 3.4 branch instead (closes#31612).
Discussion
----------
Use AsserEquals for floating-point values
Use AssertEquals for these two specific case will do a better job,
since it'll convert both '0.1' and result of `getContent()` into PHP's
internal representation of floating-point and compares them and it should be fine.
Using `AssertSame` for this tests brings floating-point serialization
into consideration which of course will be php.ini specific.
Sponsored-by: Platform.sh
| Q | A
| ------------- | ---
| Branch? | master for features / 3.4, 4.2 or 4.3 for bug fixes <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/roadmap):
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against the master branch.
-->
Commits
-------
0cef5f3ec9 Use AsserEquals for floating-point values
Use AssertEquals for these two specific case will do a better job,
since it'll convert both '0.1' and result of `getContent()` into PHP's
internal representation of floating-point and compares them and it should be fine.
Using `AssertSame` for this tests brings floating-point serialization
into consideration which of course will be php.ini specific.
In order not missing the type assertion point that `AssertSame` does,
we also perform `assertInternalType('string'...`
Sponsored-by: Platform.sh