This PR was merged into the 3.4 branch.
Discussion
----------
Fix type annotation in ExpressionLanguage\Token
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
The expected argument `$type` should be a string - the strict comparison would always fail with the current annotated types (`array|int`).
See the constructor + constants for reference:
7db7dcc431/src/Symfony/Component/ExpressionLanguage/Token.php (L33)7db7dcc431/src/Symfony/Component/ExpressionLanguage/Token.php (L25-L30)
Commits
-------
bfde15b728 Fix type annotation
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Lock] Fix StoreFactory to accept same DSN syntax as AbstractAdapter
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35350
| License | MIT
| Doc PR |
Updates `Symfony\Component\Lock\Store\StoreFactory` to accept same DSN syntax as `Symfony\Component\Cache\Adapter\AbstractAdapter` which is used to create Redis class instance.
Commits
-------
4ebbe3d86b [Lock] Fix StoreFactory to accept same DSN syntax as AbstractAdapter
* 3.4:
disallow FrameworkBundle 4.4+
propagate validation groups to subforms
[Form] [Validator] Add failing testcase to demonstrate group sequence issue
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpClient] fix using proxies with NativeHttpClient
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
As spotted by @stof in https://github.com/symfony/symfony/pull/38368#issuecomment-702272737, we cannot use local DNS resolution with HTTP proxies.
Commits
-------
28f301bf03 [HttpClient] fix using proxies with NativeHttpClient
This PR was merged into the 4.4 branch.
Discussion
----------
[Routing] fix using !important and defaults/reqs in inline route definitions
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#33224
| License | MIT
| Doc PR | -
Commits
-------
826db225b7 [Routing] fix using !important and defaults/reqs in inline route definitions
This PR was merged into the 3.4 branch.
Discussion
----------
[BrowserKit] Cookie expiration at current timestamp
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
In `Symfony\Component\BrowserKit\Cookie` a cookie is expired if the `expires` timestamp is in the past. I would like to change it to also be expired if the `expires` timestamp equals the current exact timestamp. This would still be in line with [RFC 6265](https://tools.ietf.org/html/rfc6265#section-4.1.2.1), as it states `The Expires attribute indicates the maximum lifetime of the cookie, represented as the date and time at which the cookie expires`.
Reason for this change: Cookies usually both have `expires` and `Max-Age` set, and Symfony sets `Max-Age` to zero if a cookie is expired (in `Symfony\Component\HttpFoundation\Cookie`). When converting cookies between string and object representations, `Max-Age` is the preferred source of truth for the expiration, but `Max-Age` set to zero is converted to an `expires` timestamp at this exact second, currently making the cookie not expired in `Symfony\Component\BrowserKit\Cookie`, even though it should be.
I noticed this discrepancy in my tests when checking if a cookie no longer existed after deleting it, yet it was still there, because `Cookie` thought it would only expire after the `expires` timestamp had passed. I am also thinking of raising an issue for `Symfony\Component\HttpFoundation\Cookie`, as importing and exporting an expired cookie (via strings) changes the `expired` value. I thought this change was a simpler one for now, and should have no negative/unexpected impact.
Commits
-------
9d187c0d1a Adjust expired range check
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[HttpClient] Allow bearer token with colon
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | n/a
The JetBrains Hub (YouTrack API) creates tokens with a `perm:` prefix. This doesn't work right now, because HttpClient doesn't allow a colon in the bearer token.
As far as I can see, there is no reason to disallow the use of the semicolon in the bearer token, so this PR fixes it.
Example of a token: `perm:c3RlcGhhbg==.NTUtMw==.NiZw16agafhsQAShTvclhb78hyJh2H`
Commits
-------
82ed1ec20a [HttpClient] Allow bearer token with colon
This PR was merged into the 4.4 branch.
Discussion
----------
[Form] Fix custom formats deprecation with HTML5 widgets
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/37698
| License | MIT
| Doc PR | -
1. The options resolver only show the deprecations for user defined (overidden) options.
2. The default value of the `html5` option is enough to pass the logical condition of the callback.
That means that only setting the `format` option (like in the reproducer) does not trigger the deprecation while it should. I think we need a feature in the options resolver component to handle those kind of cases 🤷♂️
Meanwhile, we can fix the issue by "deprecating" all the concerned options of the logical condition of the callback.
Commits
-------
d28182f99b [Form] Fix custom formats deprecation with HTML5 widgets
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Translator] Optional Intl dependency
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#38279
| 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/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.
-->
i decided to cast $locale at construct, given its property is documented to be string
Commits
-------
a2eb263457 [Translator] Optional Intl dependency