This PR was squashed before being merged into the 3.4 branch (closes#22187).
Discussion
----------
[DependencyInjection] Support local binding
| Q | A
| ------------- | ---
| Branch? | master
| 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 | https://github.com/symfony/symfony/issues/22167, #23718
| License | MIT
| Doc PR |
> A great idea came out on Slack about local bindings.
> We could allow injecting services based on type hints on a per service/file basis:
> ```yml
> services:
> _defaults:
> bind:
> BarInterface: '@usual_bar'
>
> Foo:
> bind:
> BarInterface: '@alternative_bar'
> $quz: 'quzvalue'
> ```
>
> This way, `@usual_bar` will be injected in any parameter type hinted as `BarInterface` (in a constructor or a method signature), but only for this service/file.
> Note that bindings could be unused, giving a better solution than https://github.com/symfony/symfony/pull/22152 to https://github.com/symfony/symfony/pull/21711.
>
> As named parameters are usable in arguments, bindings could be usable in arguments too:
> ```yml
> services:
> Foo:
> arguments:
> BarInterface: '@bar'
> ```
~Named parameters aren't supported yet.~
Edit:
> Note that bindings could be unused
Current behavior is throwing an exception when a binding is not used at all, in no services of a file if it was inherited from `_defaults` or in no services created from a prototype.
It will pass if the bindings are all used in at least one service.
Commits
-------
81f2652 [DependencyInjection] Support local binding
This PR was merged into the 3.3 branch.
Discussion
----------
[Console] Log exit codes as debug messages instead of errors
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Fixes PR #21003
This patch stops logging `exit_codes != 0` to _error_ and logs it to _debug_ instead, since it's not an error. The console application exited without uncaught exceptions, and the console application deliberately returned a specific exit code, therefore it shouldn't be logged as an error.
A valid use case would be to let a caller script in bash (the script spawning the console command) know what action to take based on the exit code. More specifically, exit codes other than 1, 2, 127+n isn't necessarily considered an error.
Monolog is hooked to our mailbox, so we can see what is happening in our production environment. However, it's currently being spammed for no reason because of #21003.
tl;dr: user-programmed exit codes (return <int> in `execute()`) should NOT log an error message to monolog. I find it a bit iffy to leave the `console.terminiate` event listener in since it now logs to `debug` instead. I'm unsure if people want/need this, so I might as well remove the terminate listener entirely.
Commits
-------
cadbed3 [Console] Log exit codes as debug messages instead of errors
This PR was merged into the 3.4 branch.
Discussion
----------
[DI] Generate one file per service factory
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #23601
| License | MIT
| Doc PR | -
See #23678 for background on this proposal.
Commits
-------
4037009490 [DI] Generate one file per service factory
This PR was squashed before being merged into the 3.4 branch (closes#23807).
Discussion
----------
[Debug] Trigger a deprecation when using an internal class/trait/interface
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | yes <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | not truly <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/23800
| License | MIT
| Doc PR |
Trigger a deprecation when the user uses an internal class/trait/interface.
The deprecation is not triggered when an `@internal` is used in the same vendor.
Commits
-------
b89ba29 [Debug] Trigger a deprecation when using an internal class/trait/interface
This PR was merged into the 3.4 branch.
Discussion
----------
[Workflow] Add transition completed event
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/8213
---
Because the "entered" event is the only event dispatched after the new marking is applied, and publish's an event upon entering into a "Place" (as opposed to completing a transition), it is not sufficient for a lot of use cases and is causing bugs.
Example:
Enabled Transitions:
1. A -> B
2. B -> C
3. C -> B
Transition 1 and transition 3, will dispatch an "entered" event on Place B, forcing post transition behaviour to be the same for both transition 1 and 3.
A user might need different behaviour depending on the transition, rather the the destination.
A concrete use case would be when applying an "undo" transition to a subject. One may or may not want to re-trigger all the events associated with the original transition to that Place.
I propose adding a "completed" event (ie. Transition completed) in addition to the entered event.
Commits
-------
c254cac [Workflow] Added an transition completed event
This PR was merged into the 3.3 branch.
Discussion
----------
[Cache] Hash cache key on save
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | ye
| Fixed tickets | n.A.
| License | MIT
| Doc PR | n.A.
Cache keys are not hashed right now in adapters extending from `AbstractAdapter`. This PR fixes this. I am not familiar enough with the cache test suite so I don't know where to add an regression test.
Commits
-------
94b1b12 Hash cache keys on save
This PR was merged into the 3.3 branch.
Discussion
----------
[HttpKernel] Remove isset call used for legacy
| Q | A
| ------------- | ---
| Branch? | 3.3 <!-- see comment below -->
| Bug fix? | no
| New feature? | no <!-- 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 | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
Added in #9628 in which the request stack dependency was nullable. Forgotten to be removed in #14634.
Commits
-------
e0a6010 [HttpKernel] Remove isset call used for legacy
This PR was squashed before being merged into the 3.4 branch (closes#23801).
Discussion
----------
Continuation of #23624
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
See https://github.com/symfony/symfony/pull/23624#discussion_r131539736
cc @chalasr
Also included service injection for init:acl + set:acl and simplification of lint:xliff + lintt:yaml.
Btw, i think init:acl needs to be renamed to acl:init :)
Commits
-------
5f637c1 Continuation of #23624
This PR was merged into the 2.7 branch.
Discussion
----------
Github template: Remove EOM 3.2 from branch suggestion
| Q | A
| ------------- | ---
| Branch? | 2.7 <!-- see comment below -->
| Bug fix? | no
| New feature? | no <!-- 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 | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
As 3.2 is EOM since the 31 July (appart for security fixes of course)
Commits
-------
30eed99 Github template: Remove EOM 3.2 from branch suggestion
This PR was merged into the 3.3 branch.
Discussion
----------
[Profiler] Fix request_collector check in main layout
| Q | A
| ------------- | ---
| Branch? | 3.3 <!-- see comment below -->
| Bug fix? | yes
| New feature? | no <!-- 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 | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
I minor issue I hit when debugging and disabling some collectors some time ago.
Commits
-------
c35cdba [Profiler] Fix request_collector check in main layout
This PR was merged into the 2.7 branch.
Discussion
----------
[Security] Fix security.interactive_login event const doc block
| Q | A
| ------------- | ---
| Branch? | 2.7 <!-- see comment below -->
| Bug fix? | no
| New feature? | no <!-- 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 | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
I'd suggest to reuse the explanation we give about this event [on the docs](http://symfony.com/doc/2.7/components/security/authentication.html#security-events) because the current one in the code is misleading: this event is not triggered for http basic/digest authentication for instance.
Commits
-------
f6c83cf [Security] Fix security.interactive_login event const doc block