This PR was merged into the 3.4 branch.
Discussion
----------
[FrameworkBundle] Don't clear app pools on cache:clear
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no, but behavior change
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #23685
| License | MIT
| Doc PR | -
The cache:clear command currently clears all cache pools by default.
This is not expected and is a bad default behavior (as explained in linked issue).
If we don't want to have that behavior forever, I see no other option than just doing the change, as done here, targeting 3.4.
Commits
-------
b0c04f8354 [FrameworkBundle] Don't clear app pools on cache:clear
This PR was merged into the 3.4 branch.
Discussion
----------
[SecurityBundle] Deprecate auto picking the first provider
when no provider is explicitly configured on a firewall
| Q | A
| ------------- | ---
| Branch? | 3.4 <!-- see comment below -->
| Bug fix? | no
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | yes <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | https://symfony-devs.slack.com/archives/C3A2XAQ20/p1506626210000345 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
From @Pierstoval on Slack:
> Hey, guys, I learnt a few days ago that if you don't specify a user provider in a firewall configuration, the security will use the first one in the list. Don't anyone think specifying the user provider should be mandatory ? Or at least mandatory if we have more than one provider registered?
- [x] UPGRADE files
- [x] CHANGELOG
- [x] Fix other tests
- [x] Removal PR #24380
Commits
-------
2d1e3347a6 [SecurityBundle] Deprecate auto picking the first provider
This PR was squashed before being merged into the 3.4 branch (closes#24239).
Discussion
----------
[HttpFoundation] Deprecate compatibility with PHP <5.4 sessions
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR removes functionality added in Symfony 2.1 as a compatibility layer with sessions from PHP <5.4.
- [x] Fix tests
Commits
-------
3deb3940ab [HttpFoundation] Deprecate compatibility with PHP <5.4 sessions
This PR was merged into the 3.4 branch.
Discussion
----------
Fix deprecations regarding core commands registered as services
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/23624#discussion_r131979501
| License | MIT
| Doc PR | n/a
Current deprecation messages can be confusing (see fixed ticket), this improves them and adds a bunch of missing CHANGELOG/UPGRADE entries on the same topic
Commits
-------
4659975944 Fix deprecations regarding core commands registered as services
This PR was squashed before being merged into the 3.4 branch (closes#23665).
Discussion
----------
Create an interface for TranslationWriter
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | ~~~no~~~ yes
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
We should provide an interface for the TranslationWriter. This allows other libraries (php-translation) that depend on the Translation component provide different implementations.
Commits
-------
c25eafa Create an interface for TranslationWriter
This PR was squashed before being merged into the 3.4 branch (closes#22913).
Discussion
----------
[Yaml] Deprecate tags using colon
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Using a colon in a tag doesn't look like yaml and causes trouble (see https://github.com/symfony/symfony/pull/22878), so I propose to just deprecate these tags in favor of more consistent tags.
```yml
- !php/const:PHP_INT_MAX
- !php/object:O:30:"Symfony\Component\Yaml\Tests\A":1:{s:1:"a";s:3:"foo";}
```
would become
```yml
- !php/const PHP_INT_MAX
- !php/object O:30:"Symfony\Component\Yaml\Tests\A":1:{s:1:"a";s:3:"foo";}
```
Commits
-------
9815af3 [Yaml] Deprecate tags using colon
This PR was squashed before being merged into the 3.4 branch (closes#22948).
Discussion
----------
[Yaml] Recommend using quotes instead of PARSE_KEYS_AS_STRINGS
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | yes <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR |
Sorry for opening this so lately... I just realized that we could get rid of `Yaml::PARSE_KEYS_AS_STRINGS` just by recommending using quotes...
~This way we don't allow a behavior not respecting the spec and we won't need to deprecate `PARSE_KEYS_AS_STRINGS` later.~
~Is it too late for this to be merged in 3.3?~
ping @xabbuh
Commits
-------
b63c55c [Yaml] Recommend using quotes instead of PARSE_KEYS_AS_STRINGS
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug] Deprecate support for stacked errors
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #22804
| License | MIT
| Doc PR | n/a
Per discussion in #22804 this deprecates support for error stacking. // @nicolas-grekas
Commits
-------
04b8b80 Deprecate support for stacked errors
This PR was squashed before being merged into the 3.4 branch (closes#22629).
Discussion
----------
[Security] Trigger a deprecation when a voter is missing the VoterInterface
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
Right now it's possible to add voters to the access decision manager that do not have a `VoterInterface`.
- No Interface, no `vote()` method, and it will give a PHP error.
- No Interface, but `vote()` method, it will still work.
- If I don't implement the interface _and_ have no `vote()` method, I will get weird exception that's not meaningful: `Attempted to call an undefined method named "vote" of class "App\Voter\MyVoter".`
This PR will deprecate the ability to use voters without the interface, it will also throw a proper exception when missing the interface _and_ the `vote()` method. Why when using and not when setting? Due to the fact that the voters can be set lazily via the `IteratorArgument`. The SecurityBundle will trigger a deprecation if the interface is not implemented and an exception if there's not even a `vote()` method present (to prevent exceptions at run-time).
This should have full backwards compatibility with 3.3, but give more meaningful errors. The only behavioral difference, might be that the container will throw an exception instead of maybe succeeding in voting when 1 voter would be broken at the end of the list (based on strategy). This case however, will be detected during development and deployment, rather than run-time.
Commits
-------
9c253e1ff6 [Security] Trigger a deprecation when a voter is missing the VoterInterface
