This PR was merged into the 4.4 branch.
Discussion
----------
[Lock] Fix tests
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | nno <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | none <!-- 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):
- 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 4.4.
- Legacy code removals go to the master branch.
-->
cc @fabpot fix lock tests.
Commits
-------
2c5089b235 [Lock] Fix tests
This PR was merged into the 4.4 branch.
Discussion
----------
[VarDumper] Let browsers trigger their own search on double CMD/CTRL + F
| Q | A
| ------------- | ---
| Branch? | 4.4 <!-- see below -->
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #29748 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
Simple way to enhance DX & mitigate #29748
Commits
-------
d2430584cd [VarDumper] Let browsers trigger their own search on double CMD/CTRL + F hit
This PR was squashed before being merged into the 4.4 branch (closes#32198).
Discussion
----------
[Lock] Split "StoreInterface" into multiple interfaces with less responsability
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | Contribute to #28694 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | TODO <!-- 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):
- 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 4.4.
- Legacy code removals go to the master branch.
-->
We are removing the StoreInterface in order to split into multiple interface, it will help reduce de responsability of the StoreInterface.
Firstly, since not all stores needs to have all the methods of the StoreInterface, we can split this like this in order to limit the methods that are needed for each store.
Secondly, we add supportsX methods in order to avoid throwing exception when a store does not supports a feature it's easier an instance of the special interface or not, and it can return true/false on the support method.
**Really big thanks to** @jderusse for working with me on this, 1-2 hours of talking together, and another 1-2 hours of pre-review :). now giving it to the whole community !
*some time has been sponsored by* @izisolutions
Commits
-------
91fcbea977 [Lock] Split \"StoreInterface\" into multiple interfaces with less responsability
This PR was squashed before being merged into the 4.4 branch (closes#31511).
Discussion
----------
[Validator] Allow to use property paths to get limits in range constraint
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | Part of #31503
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/11793
Similar as #22576, but for the `Range` constraint.
Commits
-------
2b509904c8 [Validator] Allow to use property paths to get limits in range constraint
This PR was squashed before being merged into the 3.4 branch (closes#31620).
Discussion
----------
[FrameworkBundle] Inform the user when save_path will be ignored
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no / maybe??
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #31611
| License | MIT
When a project is created, framework.yaml or config.yml has handler_id set to ~. This uses the native php SessionHandler object which is instantiated with the save_path setting from php.ini or php-fpm.d/www.conf. If you set a save_path, it is silently ignored. When using mod_php for apache or php-fpm running as apache/nginx this is typically not a big deal (except your session files are stored someplace other than you actually wanted). However if using php-fpm and running as a non-standard user for the distro, it will fail silently. Sessions won't be saved because the setting has no effect. This throws a warning in those cases to inform the user.
_It could be a BC because it changes the default configuration however fixes a 'long standing bug' if you will. Not sure what you want to do about that part._
Commits
-------
a0901294d4 [FrameworkBundle] Inform the user when save_path will be ignored
This PR was merged into the 4.4 branch.
Discussion
----------
[DI] deprecate booting the kernel twices
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #31233 <!-- #-prefixed issue number(s), 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):
- 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 4.4.
- Legacy code removals go to the master branch.
-->
This adds a check to see if the kernel has been booted twices in a single test, and throw a deprecation
Commits
-------
905bec4577 [DI] throw an exception when the kernel has been booted twices
This PR was merged into the 3.4 branch.
Discussion
----------
Don't assume port 0 for X-Forwarded-Port
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | none added
| Fixed tickets |
| License | MIT
| Doc PR | -
If you use X-Forwarded-Host but don't provide X-Forwarded-Port, it will default to `0.0.0.0:` which then assumes port `0` instead of following its default assumption based on the scheme.
Commits
-------
adcdd938a4 PHP 5 compat
6c49a0c758 Add test case
c266d6c737 Update Request.php
23db9be884 Don't assume port 0 for X-Forwarded-Port
This PR was merged into the 4.4 branch.
Discussion
----------
[Console] don't redraw progress bar more than every 100ms by default
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no (behavior change)
| BC breaks? | no (behavior change)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Follow up of https://github.com/symfony/symfony/pull/26339
Looks like something we can and should do on 4.4 to me.
Commits
-------
df551e945c [Console] don't redraw progress bar more than every 100ms by default
This PR was merged into the 5.0-dev branch.
Discussion
----------
[MonologBridge] Monolog 2 compatibility
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #27857
| License | MIT
| Doc PR | N/A
See #27857 for the discussion.
This PR adds return types to methods that need to have one in Monolog 2.
Notes:
* The PR will break userland handlers that extend handlers from Monolog Bridge.
* I was unable to come up with a php 7.1 compatible version of `SwiftMailerHandler` that works with Monolog 1 and Monolog 2 because a method we're overriding now has a `string` type-hint on a parameter that wasn't there before. I've „solved“ this with a version switch, but I feel dirty doing this. 🙈 If you have a better solution, please enlighten me.
Commits
-------
ca1cfec6a9 Monolog 2 compatibility.
This PR was merged into the 4.4 branch.
Discussion
----------
[Console] Added Application::reset()
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Symfony leaks a lot in CLI when using the EventDispatcher. I'm working on it.
But instead of fixing the root cause, it can be legit to go quick and to reset all services.
So IMHO, this services should be exposed, and always available
Commits
-------
15ba5791cd [Console] Added Application::reset()
This PR was merged into the 4.4 branch.
Discussion
----------
[WebserverBundle] Deprecate the bundle in favor of symfony local server
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | none <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | to do <!-- required for new features -->
<!--
Write a short README entry for your feature/bugfix here (replace this comment block.)
This will help people understand your PR and can be used as a start of the Doc PR.
Additionally:
- Bug fixes must be submitted against the lowest 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 the master branch.
-->
Since most of the feature added to the symfony local server (using php-fpm) will be handy for all developers and as said in https://github.com/symfony/symfony/issues/25748#issuecomment-485740082, I agree that we should deprecate the WebserverBundle in favor of the [Symfony Local Server](https://symfony.com/doc/current/setup/symfony_server.html) cc @stof @fabpot
Commits
-------
7307907585 [WebserverBundle] Deprecate the bundle in favor of symfony local server
This PR was merged into the 4.4 branch.
Discussion
----------
[SECURITY] AbstractAuthenticationListener.php error instead info. Rebase of #28462
| Q | A
| ------------- | ---
| Branch? | 4.4
| -- | --
| Bug fix? | yes
| New feature? | no
| BC breaks? | no I think
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ...
| License | MIT
Rebase of #28462. Origin description:
> ```
> [2018-09-13 20:43:38] security.INFO: Authentication request failed. {"exception":"[object] (Symfony\\Component\\Security\\Core\\Exception\\AuthenticationServiceException(code: 0): An exception occurred while executing
> ...
> Doctrine\\DBAL\\Driver\\PDOException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.phone' in 'field list' at
> ```
>
> Definitely I think this is NOT info, but error.
> And since it's info, it's not logged in production because of `fingers_crossed` with `action_level: error` - so to actually see the real error behind `Authentication request could not be processed due to a system problem.` I had to debug on production. Very bad practice IMHO.
Commits
-------
867eb78cfe [SECURITY] AbstractAuthenticationListener.php error instead info. Rebase of #28462
This PR was merged into the 5.0-dev branch.
Discussion
----------
[DependencyInjection][ProxyManagerBridge] Added type-hints to LazyProxy classes and interfaces
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #32179
| License | MIT
| Doc PR | N/A
This PR adds type-hints to the LazyProxy namespace of the DepenencyInjection component.
It also updates implementations of the LazyProxy interfaces inside the ProxyManager bridge. The consequence is that ProxyManagerBridge 5.0 won't work with DependencyInjection 4.4 anymore. If that is a problem, please tell me and I revert the ProxyManager part.
Commits
-------
211b718e28 Added type-hints to LazyProxy classes and interfaces.
This PR was merged into the 4.4 branch.
Discussion
----------
[Cache] Add argument $prefix to AdapterInterface::clear()
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR allows clearing `AdapterInterface` implementations by prefix of keys. The goal is to fix an edge case situation in `ProxyAdapter`: right now, when one calls `->clear()` on a proxy adapter that is configured to add a prefix to all the keys passed to the decorated pool, we clear it all; while only the subset that starts with the prefix should be.
Since `AdapterInterface` is an "internal" interface (ie its purpose is to create compatible implementations - *NOT* to be type-hinted for), this is not really a user-facing change.
/cc @Nyholm, this came out after we talked about proxified chain pools
Commits
-------
ad6f6cf900 [Cache] Add argument $prefix to AdapterInterface::clear()
This PR was merged into the 4.4 branch.
Discussion
----------
[ServerBundle] Display all logs by default
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #32111
| License | MIT
| Doc PR |
Instead of relying on `-vvv` behavior, we display all logs.
End user has two ways of filtering now:
* with the `--filter` options
* by configuring the handler in `config/dev/monolog.yaml`
Commits
-------
54b0809d2c [ServerBundle] Display all logs by default
This PR was merged into the 5.0-dev branch.
Discussion
----------
[Console] [5.0] Add all type-hint
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | Contributo to #32179 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | not needed <!-- 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):
- 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 4.4.
- Legacy code removals go to the master branch.
-->
Add all type-hint to console component whenever it's possible
Commits
-------
26624ed529 [Console] [5.0] Add all type-hint
This PR was merged into the 4.4 branch.
Discussion
----------
[Console] Add ProgressBar::preventRedrawFasterThan() and forceRedrawSlowerThan() methods
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | TBA
The way ProgressBar redraw frequency works currently requires to know speed of progress beforehand, which is impossible to know in some situations, e.g. when showing progress of download, or I/O speed. Setting frequency too low relative to progress speed throttles I/O speed and makes progress bar flicker too much, setting it too high makes progress bar unresponsive. Current behaviour IMHO undermines usefulness of ProgressBar.
This is an attempt to replace this with more consistent experience, not requiring to know speed of progress.)
Commits
-------
83edac321e [Console] Add ProgressBar::preventRedrawFasterThan() and forceRedrawSlowerThan() methods
This PR was squashed before being merged into the 4.3 branch (closes#32392).
Discussion
----------
[Messenger] Doctrine Transport: Support setting auto_setup from DSN
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | <!-- required for new features -->
It was not possible to set `auto_setup` via the dsn, as the result would always be a string, resulting in setup always being performed because a bool is required.
The same was true if `auto_setup` was provided in `options` as a string.
I've fixed ensuring that the final configuration contains a bool for `auto_setup`.
Additionally, constructing the `configuration` was overly complex and hard to grok, so I've hopefully simplified it as part of this PR.
As an aside the three transports all do configuration construction in different ways with varying styles. It would be nice to neaten them up.
Commits
-------
213dfd1492 [Messenger] Doctrine Transport: Support setting auto_setup from DSN
Instead of relying on `-vvv` behavior, we display all logs.
End user has two ways of filtering now (instead of 3 previously):
* with the `--filter` options
* by configuring the handler in `config/dev/monolog.yaml`
This PR was submitted for the master branch but it was squashed and merged into the 4.4 branch instead (closes#31269).
Discussion
----------
[Translator] Dump native plural formats to po files
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #29963, #10152
| License | MIT
| Doc PR |
Implementing support for dumping to the native po plural format.
```
'foo|foos' => 'bar|bars'
```
Before, the entry above was dumped directly:
```
msgid "foo|foos"
msgstr "bar|bars"
```
With this PR, it is dumped using the native po plural format:
```
msgid "foo"
msgid_plural "foos"
msgstr[0] "bar"
msgstr[1] "bars"
```
Strings using explicit rules or contain more than 2 pluralization forms are still dumped directly, as the po format does not support such cases:
```
'{0} no foos|one foo|%count% foos' => '{0} no bars|one bar|%count% bars'
```
```
msgid "{0} no foos|one foo|%count% foos"
msgstr "{0} no bars|one bar|%count% bars"
```
This PR complements #31266, fixing loading of native po plural formats.
Commits
-------
dc31739288 [Translator] Dump native plural formats to po files
This PR was merged into the 3.4 branch.
Discussion
----------
[Translator] Load plurals from mo files properly
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/10152#issuecomment-55522675
| License | MIT
| Doc PR |
Plurals were not handled correctly when loading mo files.
```
msgid "foo"
msgid_plural "foos"
msgstr[0] "bar"
msgstr[1] "bars"
```
Before, the mo entry above was treated as two entries, which doesn't make sense:
```
'foo' => 'bar'
'foos' => '{0} bar|{1} bars'
```
With this PR, it is treated as one entry:
```
'foo|foos' => 'bar|bars'
```
This PR does the same as #31266, just for mo files instead of po files. Note, however, that the old behavior differed between po and mo files: `'foos' => 'bar|bars'` for po files and `'foos' => '{0} bar|{1} bars'` for mo files.
Commits
-------
97d28b5e4e Load plurals from mo files properly
This PR was squashed before being merged into the 3.4 branch (closes#31266).
Discussion
----------
[Translator] Load plurals from po files properly
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/10152#issuecomment-55522675
| License | MIT
| Doc PR |
Plurals were not handled correctly when loading po files.
```
msgid "foo"
msgid_plural "foos"
msgstr[0] "bar"
msgstr[1] "bars"
```
Before, the po entry above was treated as two entries, which doesn't make sense:
```
'foo' => 'bar'
'foos' => 'bar|bars'
```
With this PR, it is treated as one entry:
```
'foo|foos' => 'bar|bars'
```
Commits
-------
6b69a99230 [Translator] Load plurals from po files properly
This PR was merged into the 4.4 branch.
Discussion
----------
[Ldap][Security] LdapBindAuthenticationProvider does not bind before search query
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yesish
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #24210 <!-- #-prefixed issue number(s), 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):
- 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 the master branch.
-->
This is tagged as a bug but since we need to add new params to the differents login providers and a deprecation I think we need to consider it as a new feature, maybe this could go in 3.4 too but without the deprecation.
This allow using a searchDn and a sarchPassword when passing a queryString in order to do the query authenticated.
Commits
-------
cb2d97f92b [Ldap][Security] LdapBindAuthenticationProvider does not bind before search query