This PR was merged into the 3.4 branch.
Discussion
----------
[Console] Sync ConsoleLogger::interpolate with the one in HttpKernel
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Adapted from: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Log/Logger.php#L92
Better performance and datetime support (maybe should it be merged in a newer version, but I've targeted 2.7 to prevent future merge conflicts).
Commits
-------
8fcbc55 [Console] Sync ConsoleLogger::interpolate with the one in HttpKernel
This PR was merged into the 3.3 branch.
Discussion
----------
Fixed mistake in exception expectation
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
In some cases, (5 to be exact), the `expectException` is misused while attempting to provide compatibility with the older `setExpectedException` by making use of a non-existent parameter.
Firstly, this makes the tests inconsistent (old PHPUnit version test exception message, while newer one doesn't). Secondly, if PHPUnit interface suddenly starts making use of a 2nd parameter in `expectException`, the existing code might break or cause unexpected side-effects.
Original report: 87bb726712 (commitcomment-24848315)
Commits
-------
03be003 Fixed mistake in exception expectation
This PR was merged into the 2.7 branch.
Discussion
----------
[Form] Updated the source text and translation
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
I noticed that the source text had changed. See the [English version](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Resources/translations/validators.en.xlf)
Ping @magnusnordlander or @vinkla, Is this translation okey?
Commits
-------
7da052f18f Updated the source text and translation
This PR was merged into the 3.4 branch.
Discussion
----------
[Form] [TwigBridge] Added option to disable usage of default themes when rendering a form
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/8495
This adds a possibility to use `only` keyword in `form_theme` tag to disable usage of globally defined form themes, e.g.
`{% form_theme form with ['common.html.twig', 'form/fields.html.twig'] only %}`
Otherwise, in order to completely control the rendering of the forms (for example in custom admin interfaces), one would need to use a form theme which has all the possible twig blocks defined to prevent globally defined themes to interfere with the rendering.
`only` keyword is already used when including a Twig template to transfer only the variables which are explicitly defined in the `include` tag, so it seemed natural to use it here too.
This, of course, means that the user will need to manually `use` all of the templates that are required to render the form, including `form_div_layout.html.twig`
This issue is described in details over at Symfony Demo repo: https://github.com/symfony/symfony-demo/issues/515
TODO:
- [x] submit changes to the documentation
Commits
-------
e0681f9955 [Form] [TwigBridge] Added option to disable usage of default themes when rendering a form
This PR was merged into the 2.7 branch.
Discussion
----------
[Security] Reject remember-me token if UserCheckerInterface::checkPostAuth() fails
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #24525
| License | MIT
| Doc PR | -
I think this is a security hole - a user can remain logged in with a remember me cookie even though they can no longer pass `UserCheckInterface::checkPostAuth()` (could be disabled).
This is a small BC break but shouldn't be an issue as I think it is a bug. I don't think this requires a BC layer but if so, I can add.
Commits
-------
fe190b6ee9 reject remember-me token if user check fails
* 3.3:
[BrowserKit] Handle deprecations triggered in insulated requests
[Bridge\PhpUnit] Handle deprecations triggered in separate processes
[Validator] added magic method __isset() to File Constraint class
[DI] Fix possible incorrect php-code when dumped strings contains newlines
[Translation] minor: remove unused variable in test
never match invalid IP addresses
* 2.8:
[Validator] added magic method __isset() to File Constraint class
[DI] Fix possible incorrect php-code when dumped strings contains newlines
[Translation] minor: remove unused variable in test
never match invalid IP addresses
* 2.7:
[Validator] added magic method __isset() to File Constraint class
[DI] Fix possible incorrect php-code when dumped strings contains newlines
[Translation] minor: remove unused variable in test
never match invalid IP addresses
This PR was squashed before being merged into the 3.4 branch (closes#24535).
Discussion
----------
[TwigBridge] fix BC for FormExtension if renderer is FormRenderer
| 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/24533
| License | MIT
| Doc PR | -
This fixes some issues within FormExtension since the renderer is now a `FormRenderer`.
Commits
-------
4a2f608f1e [TwigBridge] fix BC for FormExtension if renderer is FormRenderer
This PR was merged into the 3.3 branch.
Discussion
----------
[Bridge\PhpUnit] Handle deprecations triggered in separate processes
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #23003, #16726
| License | MIT
| Doc PR | -
As reported in #23003, deprecations triggered in process-isolated test cases are not gathered.
This caught us already: HttpFoundation is still using deprecated code paths, but we missed them because of that issue with the bridge.
Here is the fixed output:
Credits to @paul-m for working on the issue first.
Commits
-------
ca0fedd9e3 [BrowserKit] Handle deprecations triggered in insulated requests
ff379efb59 [Bridge\PhpUnit] Handle deprecations triggered in separate processes
This PR was merged into the 3.4 branch.
Discussion
----------
[OptionsResolver] Support array of types in allowed type
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #17032, #15524
| License | MIT
| Doc PR | TBD
This replaces #17032 with a simpler approach to allow an array of types in the allowed types for the options resolver
Note: This implementation doesn't support nested values (I.E `int[][]`), but if there is a strong need for it, I'll add it in another PR
Commits
-------
d066a23860 Support array of types in allowed type
This PR was submitted for the 3.4 branch but it was merged into the 2.7 branch instead (closes#24519).
Discussion
----------
[Validator] [Twig] added magic method __isset() to File Constraint class
| Q | A
| ------------- | ---
| Branch? | 3.4 or master / 2.7, 2.8 or 3.3 <!-- see comment below -->
| Bug fix? | no
| New feature? | yes <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | #24512 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
In my project I get assert constraints from one of my entity and I use this value in my front end via Twig.
I faced a problem with the property $maxSize of the File Constraint.
As this property is protected I cannot access it via Twig because the magic method __isset is missing, as I read in twig documentation.
<!--
- Bug fixes must be submitted against the lowest 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 3.4,
legacy code removals go to the master branch.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->
Commits
-------
9efb76572a [Validator] added magic method __isset() to File Constraint class
This PR was squashed before being merged into the 2.7 branch (closes#24532).
Discussion
----------
[DI] Fix possible incorrect php-code when dumped strings contains newlines
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | ?
| License | MIT
| Doc PR | no
See discussion #24517
<!--
- Bug fixes must be submitted against the lowest 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 3.4,
legacy code removals go to the master branch.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->
Commits
-------
345f2fc [DI] Fix possible incorrect php-code when dumped strings contains newlines
This PR was merged into the 2.7 branch.
Discussion
----------
[Translation] minor: remove unused variable in test
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | n/a
Commits
-------
c6ed0e4 [Translation] minor: remove unused variable in test
This PR was squashed before being merged into the 3.4 branch (closes#24321).
Discussion
----------
added ability to handle parent classes for PropertyNormalizer
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | yes <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | #24152 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
<!--
- Bug fixes must be submitted against the lowest 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 3.4,
legacy code removals go to the master branch.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->
This adds the ability for PropertyNormalizer to normalize/denormalize properties from parent classes.
Commits
-------
5ecafc5e25 added ability to handle parent classes for PropertyNormalizer
