This PR was merged into the 4.4 branch.
Discussion
----------
[Messenger] Ignore stamps in in-memory transport
| Q | A
| ------------- | ---
| Branch? | 4.4 <!-- 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 | N/A <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | N/A <!-- required for new features -->
Stamps can be added/removed to/from message during handling. Ignore stamps so that we can ack/reject them correctly.
<!--
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
-------
b435b1aab6 [Messenger] Ignore stamps in in-memory transport
This PR was merged into the 4.4 branch.
Discussion
----------
[Form] group constraints when calling the validator
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Follow up of https://github.com/symfony/symfony/pull/34081
Spotted during the workshop at SymfonyCon, while trying to fix deprecation notices on symfony-demo:
the Form component currently passes constraints one by one for validation, effectively preventing the validator from taking care of cross-constraints dependencies.
This PR fixes it.
This will prevent ppl from having to fix things like
> Using the "Symfony\Component\Validator\Constraints\Length" constraint with the "min" option without setting the "allowEmptyString" one is deprecated and defaults to true. In 5.0, it will become optional and default to false.
Commits
-------
d15f77f33e [Form] group constraints when calling the validator
This PR was merged into the 4.4 branch.
Discussion
----------
Remove wrong @group legacy annotations
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
These annotations are still found on branch 5.0.
Does this mean they are wrong? Why don't they make 5.0 fail if not?
Commits
-------
8d84ac34a5 Remove wrong @group legacy annotations
This PR was merged into the 4.3 branch.
Discussion
----------
[DependencyInjection] Fix dumping multiple deprecated aliases
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Only the last deprecated alias wins, cause the content will not appended
Commits
-------
60b0dae174 [DependencyInjection] Fix dumping multiple deprecated aliases
This PR was merged into the 4.3 branch.
Discussion
----------
[Form] allow button names to start with uppercase letter
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Commits
-------
d811b0e9b5 allow button names to start with uppercase letter
This PR was merged into the 4.4 branch.
Discussion
----------
States that the HttpClient provides a Http Async implementation
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no (not really)
| New feature? | no (not really)
| Deprecations? | no
| Tickets | ~
| License | MIT
| Doc PR | ~
Add in the composer.json of the HttpClient that it now provides an implementation for the `php-http/async-client-implementation` virtual package, as @Nyholm did the implementation on the HttpPlug bridge in #33743.
Commits
-------
8a460cefef States that the HttpClient provides a Http Async implementation
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpKernel] Make ErrorListener::onKernelException()'s dispatcher argument explicit
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
One less BC break for 5.0
Commits
-------
aab9b43d03 [HttpKernel] Make ErrorListener::onKernelException()'s dispatcher argument explicit
This PR was merged into the 4.4 branch.
Discussion
----------
[Security] Fix best encoder not wired using migrate_from
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Thanks @wouterj for spotting it.
Commits
-------
4132a60392 [Security] Fix best encoder not wired using migrate_from
This PR was merged into the 4.4 branch.
Discussion
----------
Removed extra whitespace
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
I was working on upgrading Laravel 7's exception handling to use Symfony's new error handler component, and noticed this minor formatting error.
Commits
-------
754fbe41fb Removed extra whitespace
This PR was submitted for the master branch but it was merged into the 3.4 branch instead.
Discussion
----------
[Finder] Fixed docs
minor docblock fix
Commits
-------
e7d0787a4d [Finder] Fixed docs
This PR was merged into the 3.4 branch.
Discussion
----------
Adjust pull request template for 5.1
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
Now that 5.0-RC1 has been released (btw: 🎉👏🍾 ), I assume that new features should go to master again.
Commits
-------
c194fffaef Adjust pull request template for 5.0 branchout
This PR was squashed before being merged into the 3.4 branch (closes#34422).
Discussion
----------
Update HttpKernel.php
phpstan-symfony (0.11.6) level 5
Parameter #2 $values of method Symfony\Component\HttpFoundation\HeaderBag::set() expects array|string, int given.
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix #... <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR |
Commits
-------
7b7f966711 Update HttpKernel.php
This PR was merged into the 3.4 branch.
Discussion
----------
Add conflict rule for Monolog 2
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #27857, symfony/monolog-bundle#300
| License | MIT
| Doc PR | N/A
Depending on the monorepo has been best practice in Symfony 3 and is discouraged but still possible in Symfony 4. If the Symfony Standard Edition was used to bootstrap the application, Monolog is installed as dependency of the MonologBundle. Thus, if we released a MonologBundle that indicates compatibility with Monolog 2, those application would be bumped to Version 2 although MonologBridge 3.4 is not ready for it. The goal is to prevent this from happening.
This PR adds a conflict rule for Monolog 2 to the 3.4 branch. Assuming this gets merged before the next Symfony releases (3.4.30, 4.2.11, 4.3.3), my plan would be to bump MonologBundle's dependencies like this:
```diff
"require": {
- "monolog/monolog": "~1.22",
- "symfony/monolog-bridge": "~3.4|~4.0"
+ "monolog/monolog": "~1.22|~2.0",
+ "symfony/monolog-bridge": "^3.4.30|~4.2.11|^4.3.3|^5.0"
}
```
If I'm not mistaken, this should remove any possible combination of Symfony 3/4 and Monolog 2.
Projects depending on individual packages instead of the monorepo should be safe already because MonologBridge 3.x/4.x locks Monolog at version 1.
Commits
-------
d53b91a45a Add conflict rule for Monolog 2.
* 4.3:
[FrameworkBundle] Remove project dir from Translator cache vary scanned directories
[HttpFoundation] Allow redirecting to URLs that contain a semicolon
catch exceptions when using PDO directly
[SecurityBundle] fix failing test
This PR was merged into the 4.4 branch.
Discussion
----------
[Messenger] Perform no deep merging of bus middleware
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | n/a
This change helps in case one needs to configure a bus differently for a custom environment while keeping existing handlers attached by name.
Commits
-------
c264583f28 [Messenger] Perform no deep merging of bus middleware