This PR was squashed before being merged into the 3.4 branch (closes#32539).
Discussion
----------
[Validator] Add missing Hungarian translations
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| 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 | - <!-- 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 branch 4.4.
- Legacy code removals go to the master branch.
-->
It has 2 messages translated to Hungarian introduced in https://github.com/symfony/symfony/pull/27738 and https://github.com/symfony/symfony/pull/32435. AFAIK it should be based on 3.4, but tell me if I should rebase any of the commits.
Commits
-------
2fee9124ba [Validator] Add missing Hungarian translations
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] Add Lithuanian translation for Range validator
| Q | A
| ------------- | ---
| Branch? | 3.4 <!-- see below -->
| Bug fix? | no
| 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 | - <!-- required for new features -->
Translation for #32435.
<!--
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 branch 4.4.
- Legacy code removals go to the master branch.
-->
Commits
-------
20ef151eb3 [Validator] Add Lithuanian translation for Range validator
This PR was merged into the 3.4 branch.
Discussion
----------
[Form] Name related PHPDoc fixes
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | relates to #32179
| License | MIT
| Doc PR | n/a
As I started working on #32179 in #32237, I noticed some PHPDoc inconsistencies around the form's name. I have researched the issue thoroughly and here's my proposal:
1. All "factory" methods (`FormFactory::create*`, `ResolvedFormType::createBuilder`, `FormBuilder::create|add`, `Form::add`) currently accept string and integer names. This should not be deprecated, because it's very convenient and natural to pass ints when adding children to types like `ChoiceType` or `CollectionType`.
1. None of the "factory" methods explicitly accepts `null` as a name, although passing `null` works the same as passing `''`. I consider passing `null` in this case to be ugly, so I corrected the builder's constructors mentioning `null` as a possible argument. One should pass an empty string `''` when creating such a form. We could also deprecate passing `null` in a PR targeting 4.4.
1. Currently the name becomes a string in the builder's (or config builder's) constructor. Which means that `FormConfigInterface::getName` always returns a string and thus the form's `$name` property is always a string. All related checks and PHPDocs should be corrected.
1. The "children accessors" (`Form::has|get|remove`, `FormBuilder::has|get|remove`) should accept both strings and ints because they are array-accessible by design (so it does not really matter, if the key is a string or an int). If it's valid to have `$collectionForm->add(1, ItemType::class)`, then it should be valid to do `$collectionForm->get(1)`. And it works in code, but is not mentioned in the PHPDoc.
ping @nicolas-grekas , @xabbuh , @HeahDude
Commits
-------
eae95c4e49 PHPDoc fixes
This PR was merged into the 3.4 branch.
Discussion
----------
[DependencyInjection] Added tests to cover the possibility of having scalars as services
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #32411
| License | MIT
| Doc PR | N/A
Commits
-------
60939d988d Added tests to cover the possibility of having scalars as services.
This PR was merged into the 3.4 branch.
Discussion
----------
Don't assume port 0 for X-Forwarded-Port
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | none added
| Fixed tickets |
| License | MIT
| Doc PR | -
If you use X-Forwarded-Host but don't provide X-Forwarded-Port, it will default to `0.0.0.0:` which then assumes port `0` instead of following its default assumption based on the scheme.
Commits
-------
adcdd938a4 PHP 5 compat
6c49a0c758 Add test case
c266d6c737 Update Request.php
23db9be884 Don't assume port 0 for X-Forwarded-Port
This PR was merged into the 3.4 branch.
Discussion
----------
[Translator] Load plurals from mo files properly
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/10152#issuecomment-55522675
| License | MIT
| Doc PR |
Plurals were not handled correctly when loading mo files.
```
msgid "foo"
msgid_plural "foos"
msgstr[0] "bar"
msgstr[1] "bars"
```
Before, the mo entry above was treated as two entries, which doesn't make sense:
```
'foo' => 'bar'
'foos' => '{0} bar|{1} bars'
```
With this PR, it is treated as one entry:
```
'foo|foos' => 'bar|bars'
```
This PR does the same as #31266, just for mo files instead of po files. Note, however, that the old behavior differed between po and mo files: `'foos' => 'bar|bars'` for po files and `'foos' => '{0} bar|{1} bars'` for mo files.
Commits
-------
97d28b5e4e Load plurals from mo files properly
This PR was squashed before being merged into the 3.4 branch (closes#31266).
Discussion
----------
[Translator] Load plurals from po files properly
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/10152#issuecomment-55522675
| License | MIT
| Doc PR |
Plurals were not handled correctly when loading po files.
```
msgid "foo"
msgid_plural "foos"
msgstr[0] "bar"
msgstr[1] "bars"
```
Before, the po entry above was treated as two entries, which doesn't make sense:
```
'foo' => 'bar'
'foos' => 'bar|bars'
```
With this PR, it is treated as one entry:
```
'foo|foos' => 'bar|bars'
```
Commits
-------
6b69a99230 [Translator] Load plurals from po files properly
This PR was merged into the 3.4 branch.
Discussion
----------
[Intl] Remove --dev from intl compile autoloader
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no
| 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 -->
Remove implicit composer default (`jakzal/php-intl` uses latest composer during compile)
Commits
-------
8ffc61692d [Intl] Remove --dev from intl compile autoloader
This PR was merged into the 3.4 branch.
Discussion
----------
[Intl] Init compile tmp volume
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no
| 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 -->
Fixes
```
Symfony\Component\Filesystem\Exception\IOException: Failed to create "/tmp/icu-data": mkdir(): Permission denied.
```
if the initial volume does not exists docker creates it as root, but the container runs for the current user.
Commits
-------
5e26d96a6b [Intl] Init compile tmp volume
This PR was merged into the 3.4 branch.
Discussion
----------
[DI] fix processing of regular parameter bags by MergeExtensionConfigurationPass
| 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 | -
Spotted in and needed by #32294
Commits
-------
b06d0003a3 [DI] fix processing of regular parameter bags by MergeExtensionConfigurationPass
This PR was merged into the 3.4 branch.
Discussion
----------
[DependencyInjection] Annotated correct return type for getInEdges()/getOutEdges()
| 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
This changed annotation was quite helpful when analyzing `PhpDumper` for #32266.
Commits
-------
28882f52cb Annotated correct return type for getInEdges()/getOutEdges().
This PR was squashed before being merged into the 3.4 branch (closes#32215).
Discussion
----------
[HttpFoundation] Throw exception when the "session" extension is not loaded
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #31305
| License | MIT
Should I target `3.4` or `master` instead? This change does not alter behavior, but makes the failure more clear.
Commits
-------
b0c663071b [HttpFoundation] Throw exception when the \"session\" extension is not loaded
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] remove invalid test cases
| 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 |
Spotted while working on #32179 for the Validator component. Using property paths for comparison when validating arrays simply does not work.
Commits
-------
d1261e78a4 remove invalid test cases
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] pass error code as a string
| 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 |
Commits
-------
901fe0d7c5 pass error code as a string
This PR was merged into the 3.4 branch.
Discussion
----------
[Serializer] Fixed PHP of DenormalizableInterface::denormalize
It can return an array of objects
| 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 |
Commits
-------
379bbee370 [Serializer] Fixed PHP of DenormalizableInterface::denormalize
This PR was merged into the 3.4 branch.
Discussion
----------
Catch JsonException and rethrow in JsonEncode
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | adjustment to implementation of previous PRs for issue #31447
| License | MIT
| Doc PR | not applicable
PR #31860 provided handling of PHP 7.3 `JSON_THROW_ON_ERROR` behavior in the various `JsonEncode` and related classes/methods.
PR #31869 adjusted that. In particular, it adjusted ` src/Symfony/Component/Serializer/Encoder/JsonDecode.php` so that it catches any `JsonException` and re-throws it as `NotEncodableValueException`. That preserves the previous behavior of `JsonDecode:decode` - it always throws `NotEncodableValueException` when something goes wrong.
IMO `JsonEncode:encode` needs the same logic. At the moment, if a caller specifies `JSON_THROW_ON_ERROR` then the method can throw `JsonException`, but actually the "standard" for `JsonEncode:encode` is that it throws `NotEncodableValueException`
Adjust `JsonEncode:encode` to catch `JsonException` and rethrow it as `NotEncodableValueException`
Commits
-------
9c76790ee8 Catch JsonException and rethrow in JsonEncode