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 submitted for the master branch but it was merged into the 3.4 branch instead (closes#35628).
Discussion
----------
[Security] Improve info UserPasswordEncoderCommand
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| License | MIT
| Doc PR | n/a
`php bin/console security:encode-password [password] App\Entity\User`
will result in
`No encoder has been configured for account "AppEntityUser". `
If a full class path is used, it either has to be passed in as a string or has to be escaped by double slashes.
Commits
-------
3604bb7018 Update UserPasswordEncoderCommand.php
This PR was merged into the 5.1-dev branch.
Discussion
----------
[String] Remove the @experimental status
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/pull/35578#discussion_r375955786
| License | MIT
| Doc PR | -
Commits
-------
3d15f91723 [String] Remove the @experimental status
This PR was merged into the 5.1-dev branch.
Discussion
----------
[OptionsResolver] Add new OptionConfigurator class to define options with fluent interface
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#33735
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/12426
- [x] submit changes to the documentation
This PR adds OptionConfigurator to the OptionsResolver
Commits
-------
1ff56407e1 [OptionsResolver] Add new OptionConfigurator class to define options with fluent interface
This PR was squashed before being merged into the 5.0 branch (closes#35616).
Discussion
----------
[Workflow] Make method signature compatible with 4.4
| Q | A
| ------------- | ---
| Branch? | 5.0 <!-- see below -->
| 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#35615 <!-- prefix each issue number with "Fix #", 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):
- 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.
-->
A method signature changed in a non-backwards-compatible way in 5.0.0 - and in only one class. This commit fixes that - and has been tested.
For full details see ticket #35615.
Commits
-------
474be9613b [Workflow] Make method signature compatible with 4.4
This PR was merged into the 5.1-dev branch.
Discussion
----------
[DI] added possibility to define services with abstract arguments
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#31769
| License | MIT
| Doc PR | n/a
feature caused by rfc #31769 from issues list
I hope, this PR will be useful
Abstract argument have to replaced by one of compiler passes or exception will be thrown.
Example:
This service definition
```xml
...
<service id="App\Test\Test">
<argument key="$a" type="abstract">should be defined by TestPass</argument>
</service>
...
```
or this for yaml
```yaml
App\Test\Test:
arguments:
$a: !abstract should be defined by TestPass
```
causes exception like `Argument "$a" of service "App\Test\Test" is abstract (should be defined by TestPass), did you forget to define it?`
if argument was not replaced by compiler pass
```php
...
public function process(ContainerBuilder $container)
{
$test = $container->getDefinition(Test::class);
$test->setArgument('$a', 'test');
}
...
```
Commits
-------
62fefaa59f [DI] added possibility to define services with abstract arguments
This PR was merged into the 5.1-dev branch.
Discussion
----------
[Routing] add priority option to annotated routes
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | yes
| Tickets | Fix #26132
| License | MIT
| Doc PR | -
This PR allows defining the priority of routes using annotations:
`@Route(name="foo", priority=10)`
As requested [in this comment](https://github.com/symfony/symfony/pull/26132#pullrequestreview-352321332), priority is reserved to using annotations. For other formats, the order works fine.
Commits
-------
8522a83217 [Routing] add priority option to annotated routes
This PR was merged into the 5.1-dev branch.
Discussion
----------
[Contracts/Deprecation] Provide a generic function and convention to trigger deprecation notices
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
This PR results from a discussion we had yesterday with @alcaeus, @beberlei and others at the Symfony UG meetup in Berlin (thanks SensioLabs for bringing me there).
It provides a generic function and convention to trigger deprecation notices, which could be a better alternative to the `@trigger_error(..., E_USER_DEPRECATED)` calls that we use currently.
This proposed package would provide a single global function named `deprecated()`.
Its purpose is to trigger deprecations in a way that can be silenced on production environment
by using the `zend.assertions` ini setting and that can be caught during development to generate reports.
The function requires at least 3 arguments:
- the name of the package that is triggering the deprecation
- the version of the package that introduced the deprecation
- the message of the deprecation
- more arguments can be provided: they will be inserted in the message using `printf()` formatting
Example:
```php
deprecated('symfony/blockchain', 8.9, 'Using "%s" is deprecated, use "%s" instead.', 'bitcoin', 'fabcoin');
```
This will generate the following message:
`Since symfony/blockchain 8.9: Using "bitcoin" is deprecated, use "fabcoin" instead.`
Check #35550 to see how using this function could look like on Symfony itself.
Commits
-------
f0f41cbfc5 [Contracts/Deprecation] Provide a generic function and convention to trigger deprecation notices
This PR was merged into the 3.4 branch.
Discussion
----------
[Security] Replace 403 with 401 in `onAuthenticationFailure` method
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
This comment in `onAuthenticationFailure` was misleading since a 401 status code should probably be returned instead of a 403.
Commits
-------
73bc793be2 Replace 403 with 401 in onAuthenticationFailure method
This PR was merged into the 5.1-dev branch.
Discussion
----------
[Form] Add "is empty callback" to form config
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/31572 for 4.4+
| License | MIT
| Doc PR | -
This PR introduces a new feature that allow to resolve a bug.
Currently, the `isEmpty()` behavior of the `Form` class is the same whatever its configuration. That prevents us to specify a different behavior by form type.
But I think that some form types should have dedicated empty values. For example, the `CheckboxType` model data either resolves to `true` (checked) or `false` (unchecked). But `false` is not an empty value in the `Form::isEmpty()` method, so a `CheckboxType` form can never be empty. `false` should not be in that list because for other form types, it's perfectly fine that it's not considered as an empty value.
The problem is better seen in https://github.com/symfony/symfony/issues/31572 with a `ChoiceType` that is never considered as empty (when no radio button is checked).
Being able to specify the "is empty" behavior by form type would also allow users to define their own logic in their custom form types + probably define it ourselves in all our form types in order to get rid of the default common behavior.
Commits
-------
7bfc27e7cf [Form] Add "is empty callback" to form config
This PR was merged into the 5.1-dev branch.
Discussion
----------
[DI] Enable auto alias compiler pass by default
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? |
| Deprecations? | no
| Tickets | Fix#34194
| License | MIT
| Doc PR |
I'm sending this PR to trigger a discussion as @nicolas-grekas suggested in #34194
I'm using this quite a lot in one of my applications and I don't see any reasons why it shouldn't be enabled by default.
Commits
-------
4fde51745b Enable auto alias compiler pass by default
This PR was submitted for the master branch but it was merged into the 4.4 branch instead.
Discussion
----------
[PhpUnitBridge] fix getting the vendor/ dir for tests
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Commits
-------
341dd5dd1d [PhpUnitBridge] fix getting the vendor/ dir for tests
This PR was merged into the 5.1-dev branch.
Discussion
----------
[Messenger] Made final class really final
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
introduced in #35485 (so no BC break)
Commits
-------
cd8a386284 [Messenger] Made final class really final
This PR was merged into the 4.4 branch.
Discussion
----------
[PHPunit bridge] Provide current file as file path
I failed to apply perfectly this comment:
https://github.com/symfony/symfony/pull/33820#discussion_r338746158
It should fix one failing test in the bridge.
| Q | A
| ------------- | ---
| Branch? |4.4
| Bug fix? | not for the end user
| New feature? | no
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | n/a
<!--
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
-------
d5302cb5d2 Provide current file as file path
This PR was merged into the 5.1-dev branch.
Discussion
----------
[Serializer] Add support for stdClass
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix#33047, #33894
| License | MIT
| Doc PR | n/a
Add support for `stdClass`. Alternative to #33894.
Commits
-------
d7bca80007 [Serializer] Add support for stdClass
