This PR was merged into the 3.4 branch.
Discussion
----------
[SecurityBundle] Minor fixes in configuration tree builder
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | ~
| License | MIT
| Doc PR | ~
Commits
-------
1bd779d7c8 [SecurityBundle] Minor fixes in configuration tree builder
This PR was merged into the 3.4 branch.
Discussion
----------
Add Spanish translation
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
@javiereguiluz I know it's not very significant, but in order to make distinction between `must be` and `should be`, shouldn't translation no. 94 be changed to `Este valor debería estar entre...`?
Commits
-------
9e67b57baa Add Spanish translation
This PR was merged into the 3.4 branch.
Discussion
----------
[Form] NumberToLocalizedStringTransformer return int if scale = 0
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35775
| License | MIT
<!--
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/releases):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- 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 master.
-->
Commits
-------
2993fc9fc5 Return int if scale = 0
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] add German translation
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Commits
-------
9d837ecb34 add German translation
This PR was merged into the 3.4 branch.
Discussion
----------
[DomCrawler][Form] Fix PHPDoc on get & offsetGet
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
`FormFieldRegistry::get()` returns mixed. For example, it can return an array when the field is a collection.
Commits
-------
f8735cc47b [DomCrawler][Form] Fix PHPDoc on get & offsetGet
This PR was merged into the 5.1-dev branch.
Discussion
----------
[FrameworkBundle] Add missing items in the unused tag pass whitelist
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | n/a <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | n/a
We have some missing tags in the whitelist. I've added a script that adds the missing ones, and added a test to avoid forgetting about updating the whitelist.
Commits
-------
d1bcc0fc5e [FrameworkBundle] Add a script that checks for missing items in the unused tag whitelist
This PR was merged into the 3.4 branch.
Discussion
----------
[3.4][DoctrineBridge] Use new Types::* constants and support new json type
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
All `Type::*` constants were moved and deprecated. This PR makes sure we use the good ones when they exist so we are prepared for their removal. It allows to be deprecation free. If deprecated constants could be detected, we would have failing tests 😄
Also, `json_array` was deprecated and renamed to `json`, so I added support for this new type.
Some new components also use these constants on upper branches, so I will submit PRs there.
Commits
-------
3e35fa59ea [DoctrineBridge] Use new Types::* constants and support new json type
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] Remove specific check for Valid targets
| Q | A
| ------------- | ---
| Branch? | 3.4 <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | N/A <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | N/A
As covered by `ClassMetadataTest::testAddConstraintDoesNotAcceptValid`, this check is useless, as `Valid` already accepts only properties as targets.
This check is a [leftover of a time](9b07b0c672) `Valid` was extending `Traverse` which was allowing classes & properties.
The `Valid` targets are properly checked by the lines above, the same way as other constraints.
Commits
-------
0086562c77 [Validator] Remove specific check for Valid targets
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[ExpressionLanguage] Fixed collisions of character operators with object properties
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | n/a
Expression `foo.not in [bar]` compiles to invalid php code:
```
$foo->not in[$bar]
```
Added check for absence of a dot before of the character operators.
PS. I apologize for not starting the issue before create PR. I considered this bug is minor, but obvious.
Commits
-------
4b83ae7547 [ExpressionLanguage] Fixed collisions of character operators with object properties
This PR was merged into the 3.4 branch.
Discussion
----------
[DoctrineBridge][DoctrineExtractor] Fix indexBy with custom and some core types
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/35542 and https://github.com/symfony/symfony/issues/35604
| License | MIT
| Doc PR | -
For https://github.com/symfony/symfony/issues/35604:
To guess the collection key type, the `getPhpType()` method is called. But it does not handle most objects and arrays core types. This is why an indexBy datetime does not work.
For https://github.com/symfony/symfony/issues/35542:
When the php type cannot be guessed, null is returned. In this case, we cannot pass a valid builtin type to PropertyInfo Type, so we should return null.
Commits
-------
018ec1ae5c [DoctrineBridge][DoctrineExtractor] Fix indexBy with custom and some core types
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[PhpUnitBridge] Use trait instead of extending deprecated class
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | Fix#32086
| License | MIT
| Doc PR |
Use `TestListenerDefaultImplementation` instead of deprecated `BaseTestListener` for `CoverageListenerForV6`
As this is my very first pull request for this project, I'd be very glad for hints and suggestions in case I missed something.
Commits
-------
034e1de6e6 [PhpUnitBridge] Use trait instead of extending deprecated class
This PR was merged into the 3.4 branch.
Discussion
----------
[Ldap] force default network timeout
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
The default network timeout is infinite, which makes no sense and can block workers.
Note that LDAP supports also "timelimit" options, but those are max-durations for LDAP queries. We cannot limit them by default.
Commits
-------
63f9e013a1 [Ldap] force default network timeout
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] Add the missing translations for the Polish ("pl") locale
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| License | MIT
Fabbot indicates a typo, but there is no typo. The English word `address` is `adres` in Polish (with a single d and a single s).
Commits
-------
8c4de564a8 [Validator] Add the missing translations for the Polish ("pl") locale
This PR was merged into the 3.4 branch.
Discussion
----------
fix anchor
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | none
| License | MIT
| Doc PR | none
This is a continuation of PR #35703 that was merged a bit too early.
It accepts suggestion made there and, moreover, fixes anchor link (that changed from old roadmap page)
Commits
-------
5825e3c58c fix anchor
This PR was merged into the 3.4 branch.
Discussion
----------
[Console] Don't load same-namespace alternatives on exact match
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35479
| License | MIT
| Doc PR | -
<!--
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):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- 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 master.
-->
Commits
-------
707c5bade0 [Console] Don't load same-namespace alternatives on exact match found
This PR was squashed before being merged into the 3.4 branch (closes#35657).
Discussion
----------
[Security] Fix exception name in doc comments
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Commits
-------
f10098e9f1 [Security] Fix exception name in doc comments
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpFoundation][FrameworkBundle] fix support for samesite in session cookies
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35520
| License | MIT
| Doc PR | -
This PR cherry-picks #28168 on 3.4, with a rationale given by @ConneXNL in https://github.com/symfony/symfony/issues/35520#issuecomment-582296847:
> I hope I am wrong but I see the impact of not making any changes to Symfony 3.4 will have a tons of sites break if we cannot set the cookie's samesite setting (in the framework session and remember me) before Chrome pushes this update.
>
> Very soon all existing cookies are no longer going to work with cross-domains if you do not specify 'None' for the cookie_samesite. All external APIs that use cookies and are running SF 3.4 will break and devs will have no quick solution to fix their auth process.
>
> If you are using PHP 7.4, yes you can most likely use ini_set to workaround this issue.
>
> However, ini_set('cookie_samesite') does not work in PHP Version <= 7.2.
I am not even sure PHP 7.3 supports the value 'None' as php.watch/articles/PHP-Samesite-cookies says it has support for 'Lax' and 'Scrict'.
>
> This effectively means SF 3.4 on PHP 7.2 (or PHP 7.3) is no longer supported for cross domain APIs with cookies. People would have to either update PHP to 7.4 (if they even can?) or go to Symfony 4 (with a dead live site is going to be a complete disaster).
>
> Since the impact of the change that chrome is about to roll out is so fundamentally changing our way to set cookies, I consider configuring samesite configuration in the framework an absolute requirement, not a feature, especially since SF 3.4 is still supported.
>
> What am i missing?
>
> Note: SF3 HTTPFoundation already supports the new cookie settings, it's just the framework that doesn't support it.
Our BC policy embeds the promise that one should be able to keep the same app on a newest infrastructure (eg that's why supporting a PHP version is a bug fix). I think we can consider this for browsers here also. WDYT?
Commits
-------
f46e6cb8a0 [HttpFoundation][FrameworkBundle] fix support for samesite in session cookies
This PR was merged into the 3.4 branch.
Discussion
----------
[DoctrineBridge] Fixed submitting ids with query limit or offset
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix https://github.com/symfony/symfony/pull/34900#discussion_r375246113 <!-- prefix each issue number with "Fix #", 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):
- Always add tests and ensure they pass.
- Never break backward compatibility (see https://symfony.com/bc).
- 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 master.
-->
Commits
-------
9bb194098f [DoctrineBridge] Fixed submitting ids with query limit or offset
This PR was merged into the 3.4 branch.
Discussion
----------
[Form] Fix handling of empty_data's \Closure value in Date/Time form types
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#33188
| License | MIT
| Doc PR | -
Basically this would solve the posibility to pass a `\Closure` to the `empty_data` option for Date/Time form types.
> https://symfony.com/doc/current/reference/forms/types/form.html#empty-data
> If a form is compound, you can set empty_data as an array, object or **closure**. See the [How to Configure empty Data](https://symfony.com/doc/current/form/use_empty_data.html) for a Form Class article for more details about these options.
Also related to https://github.com/symfony/symfony/pull/29182
Commits
-------
4939f0e323 Fix handling of empty_data's \Closure value in Date/Time form types
This PR was squashed before being merged into the 3.4 branch (closes#35552).
Discussion
----------
[Translation][Debug] Add installation and minimal example to README
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | -
At SymfonyCon, we decided to test out removing some component documentation from the official docs. These were duplicating quite some information of the main guides and were confusing people that used the components in the framework.
I think it's good to reintroduced the composer installation command and a very minimal example in the README's of the component. This doesn't require maintenance and can kickstart people to gain knowledge on how to use the component.
For now, we've (re)moved the Debug and Translation component docs, so that's why I've only modified those README's.
cc @symfony/team-symfony-docs
Commits
-------
b52b7b9fd6 [Translation][Debug] Add installation and minimal example to README
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] check for __get method existence if property is uninitialized
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35544
| License | MIT
Resolve bug #35544.
On PHP 7.4, check if object implements `__get` magic method if property is reported as uninitialized before returning null.
Commits
-------
427bc3aa18 [Validator] try to call __get method if property is uninitialized
This PR was merged into the 3.4 branch.
Discussion
----------
[DependencyInjection] Fix typo in test name
Rename testThrowsExceptionWhenAddServiceOnACompiledContainer to testNoExceptionWhenAddServiceOnACompiledContainer.
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes (technically)
| New feature? | no
| Deprecations? | no
| Tickets | #35505
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
Commits
-------
9cbfad5853 [DependencyInjection] #35505 Fix typo in test name
This PR was merged into the 3.4 branch.
Discussion
----------
[Yaml][Inline] Fail properly on empty object tag and empty const tag
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Rework of https://github.com/symfony/symfony/pull/35208 to not end up in `parseScalar` with an empty string or a boolean (and thus, avoid unfriendly error such as `Trying to access array offset on value of type bool`).
Ping @xabbuh
Commits
-------
bdf02c0a7e [Yaml][Inline] Fail properly on empty object tag and empty const tag
This PR was merged into the 3.4 branch.
Discussion
----------
[PhpUnitBridge] Fix running skipped tests expecting only deprecations
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
If a test class has unsatisfied `@requires` and contains test methods expecting deprecation only, you get:
> Fatal error: Uncaught Error: Call to a member function beStrictAboutTestsThatDoNotTestAnything() on null in ./symfony/symfony-dev/vendor/symfony/phpunit-bridge/Legacy/SymfonyTestsListenerTrait.php:229
Spotted in #34925's build.
Commits
-------
6b02362c5b [Phpunit] Fix running skipped tests expecting only deprecations
This PR was merged into the 3.4 branch.
Discussion
----------
[FrameworkBundle] Check non-null type for numeric type
$maxAge and $sharedAge can both be zero
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| License | MIT
Commits
-------
2797867ae9 Check non-null type for numeric type
This PR was merged into the 3.4 branch.
Discussion
----------
[DomCrawler] Skip disabled fields processing in Form
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#28179
| License | MIT
Commits
-------
c73b042044 bug symfony#28179 [DomCrawler] Skip disabled fields processing in Form
This PR was merged into the 3.4 branch.
Discussion
----------
[Console] SymonfyStyle - Check value isset to avoid PHP notice
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#34093
| License | MIT
| Doc PR | n/a
This PR addresses the issue when a default value is not a valid choice. Currently this would throw a notice which outputs to the console.
This fix is a similar implementation to the `QuestionHelper`: https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/Console/Helper/QuestionHelper.php#L63
Example console command and output can be found in the issue: #34093
Commits
-------
c9072c70ef Check value isset to avoid PHP notice
This PR was squashed before being merged into the 3.4 branch (closes#35305).
Discussion
----------
[HttpKernel] Fix stale-if-error behavior, add tests
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #24248
| License | MIT
| Doc PR |
This PR adds the first tests for `stale-if-error` logic in `HttpCache`.
It also fixes an observation from #24248: For responses that have been cached as `public` with an `ETag` but without a lifetime, in case of an error the stale response will be served forever (= as long as the error persists), even beyond the configured `stale-if-error` grace period.
Furthermore, it tries to improve compliance with RFC 7234: Stale responses must not be sent (under no condition) if one of
* `no-cache`
* `must-revalidate`
* `proxy-revalidate` or
* `s-maxage` (sic) is present.
This can be found in the corresponding chapters of Section 5.2.2 for these directives, but is also summarized in [Section 4.2.4](https://tools.ietf.org/html/rfc7234#section-4.2.4) as
> A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2).
Because disabling of `stale-if-error` for `s-maxage` responses probably has a big impact on the usefulness of that feature in practice, it has to be enabled explicitly with a new config setting `strict_smaxage` (defaulting to `false`).
Commits
-------
ad5f427bed [HttpKernel] Fix stale-if-error behavior, add tests
This PR was merged into the 3.4 branch.
Discussion
----------
[Security] Use supportsClass in addition to UnsupportedUserException
| Q | A
| ------------- | ---
| Branch? | 3.4+
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35045
| License | MIT
| Doc PR | ~
This PR fixes the issue where user providers rely on just the UnsupportedUserException from `refreshUser()`, causing a flow where users are wrongfully re-authenticated.
There's one issue where `refreshUser()` can do far more sophisticated checks on the user class, which it will never reach if the class is not supported. As far as I know it was never intended to support instances that are rejected by `supportsClass()`, though people could've implemented this (by accident). So the question is more if we should add a BC layer for this; for example:
```php
try {
$refreshedUser = $provider->refreshUser($user);
$newToken = clone $token;
$newToken->setUser($refreshedUser);
if (!$provider->supportsClass($userClass)) {
if ($this->shouldCheckSupportsClass) {
continue;
}
// have to think of a proper deprecation here for 6.0
@trigger_error('Provider %s does not support user class %s via supportsClass() while it does support it via refreshUser .. please set option X and fix %s::supportsUser() ', E_USER_DEPRECATED);
}
```
This would prevent behavior from breaking but also means we can't fix this on anything less than 5.1.
Commits
-------
d3942cbe17 Use supportsClass where possible
This PR was merged into the 3.4 branch.
Discussion
----------
[PhpUnitBridge][SymfonyTestsListenerTrait] Remove some unneeded code
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Risky errors when there are no assertions are added before the test end listeners are called (ie, before the code in endTest is executed) so forcing beStrictAboutTestsThatDoNotTestAnything to false when there is a expectedDeprecation annotation is enough.
If the goal is to reset the value to the original value, then I think we should not do it since we basically "lie" to the next listeners. Let's assume that when a test expect a deprecation, it can have 0 assertions. Also this flag is not used anymore by PHPUnit after we reset it.
Ref https://github.com/symfony/symfony/pull/21786 btw
Commits
-------
fb48bbc05b [PhpUnitBridge][SymfonyTestsListenerTrait] Remove some unneeded code
