`ConstraintViolation#getPropertyPath()`'s inherited signature states that `string` is
to be returned by it at all times, yet the implementation returns `null` when no property
path had been provided at instantiation.
This patch obviates it, returning an empty string when the
property path is `null`.
* 4.4:
[WebLink] Removed unused property
Fix method name compare in ResolveControllerNameSubscriber
add uz security validator and form validator file
uzb translation
This PR was merged into the 4.4 branch.
Discussion
----------
[WebLink] Removed unused property
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
In `Link::withHref()`, a property `templated` is written, that is never declared or access anywhere else. I assume that this is dead code.
Commits
-------
848972e830 [WebLink] Removed unused property
This PR was merged into the 4.4 branch.
Discussion
----------
[FrameworkBundle] [4.4]: Fix method name compare in ResolveControllerNameSubscriber
| Q | A
| ------------- | ---
| Branch? | 4.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 | <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | <!-- required for new features -->
The left side to `strtolower` was not actually lowercased, so it would be always `false`.
The bug was introduced in 6c109c71a9 (https://github.com/symfony/symfony/pull/31938)
<!--
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/releases):
- 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 5.x.
- Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
-->
Commits
-------
69431a3db3 Fix method name compare in ResolveControllerNameSubscriber
This PR was merged into the 4.4 branch.
Discussion
----------
add 2 translations file uzb lang
| Q | A
| ------------- | ---
| Branch? | 5.x for features / 4.4 or 5.2 for bug fixes <!-- see below -->
| 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 #... <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| 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/releases):
- 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 5.x.
- Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
-->
Commits
-------
73392924bf add uz security validator and form validator file
This PR was submitted for the 5.x branch but it was merged into the 4.4 branch instead.
Discussion
----------
add uz validators file
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix #... <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| 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/releases):
- 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 5.x.
- Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
-->
add uz validators file
Commits
-------
df4679c163 uzb translation
This PR was merged into the 4.4 branch.
Discussion
----------
[TwigBridge] Render email once
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#39718
| License | MIT
| Doc PR | -
When `\Symfony\Component\Mailer\Mailer` send an email via the Bus (async) it dispatches an `MessageEvent`, then the consumer call the `\Symfony\Component\Mailer\Transport\AbstractTransport::send` method which also dispatches an `MessageEvent`.
This event is listened by `\Symfony\Bridge\Twig\Mime\BodyRenderer::render` which rendered twice an email.
I'm not sure why the event is send twice, and if we could safely remove one of them (or maybe deprecating the `MessageEvent`, in favor of `SendMessageEvent` + `AsyncMessageEvent`)
This PR store a flag in the Message to avoid rendering it twice.
Commits
-------
186ea59180 Render email once
* 4.4:
Backport psr/container 1.1/2.0 compatibility
Bump Symfony version to 4.4.21
Update VERSION for 4.4.20
Update CONTRIBUTORS for 4.4.20
Update CHANGELOG for 4.4.20
This PR was merged into the 4.4 branch.
Discussion
----------
[DependencyInjection][Security] Backport psr/container 1.1/2.0 compatibility
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix https://github.com/symfony/symfony/pull/40384/files#r588494278
| License | MIT
| Doc PR | N/A
This PR backports a fix that I had to apply to the 5.x branch in order to make it compatible with the `psr/container` 1.1 interfaces.
It also updates various composer.json files:
* Security Core only consumes a PSR `ContainerInterface` without providing its own implementation. I should be compatible with version 2 of the PSR package already.
* ~~DependencyInjection breaks on PHP 7.2 and 7.3 if `psr/container` 1.1.0 is installed. A version 1.1.1 has already been release that fixes the issue. I've added a conflict rule to document the incompatibility.~~
Commits
-------
7f8242ef58 Backport psr/container 1.1/2.0 compatibility
This PR was merged into the 5.2 branch.
Discussion
----------
[Messenger] Don't lock tables or start transactions
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
I was so sure my PR #40336 fixed the doctrine-messenger issue once and for all. But it had a very silent bug..
This has been tricky to debug and find because the `PDO` behaves differently in PHP 7.4 compared to PHP 8.
| Scenario | Command | Is executed in transaction | Method that calls `PostgreSqlConnection::getTriggerSql()` |
| --| -- | -- | -- |
| A | `messenger:setup-transports` | No | `setup()`
| B| `doctrine:schema:create` | No | `getExtraSetupSqlForTable()`
| C | `doctrine:migration:diff` | Yes by default, but it can be configured | `getExtraSetupSqlForTable()`
PR #40055 fixed scenario C on PHP 8, but that also broke scenario B on PHP 7.4 and PHP 8.
In PR #40336 I was wrong claiming:
> We don't need COMMIT because the transaction will commit itself when we close the connection.
The result was the we removed all the errors messages from the 3 scenarios. But scenario B will produce some SQL that is actually never committed. IE it will silently fail.
I've been trying to figure out a good solution to how or when to start a transaction. I tried out @fbourigault [suggestion](https://github.com/symfony/symfony/pull/40336#issuecomment-790622951) but that would be the same fix as #40055.
---------------
We need a transaction because the SQL includes a `LOCK TABLE`, however, I cannot see a strict need for it. This PR removes `LOCK TABLE` and all transaction juggling. It all seams to work.
I would be happy to get thorough feedback on this PR so we can end the chapter of constantly adding bugs to this part of the component.
@dunglas, you added `LOCK TABLE` in your initial version of this class in https://github.com/symfony/symfony/pull/35485, could you share some knowledge if this is a good or bad idea?
Commits
-------
26061a131d Dont lock tables or start transactions
This PR was merged into the 5.2 branch.
Discussion
----------
Changing ZulipTransportFactory tag to prevent the exception UnsupportedSchemeException
| Q | A
| ------------- | ---
| Branch? | 5.2 <!-- 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#40374 <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| 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/releases):
- 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 5.x.
- Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
-->
Changing ZulipTransportFactory to 'chatter.transport_factory' to prevent the exception UnsupportedSchemeException "The "zulip" scheme is not supported."
Commits
-------
61c5bafafc Update notifier_transports.php
This PR was squashed before being merged into the 5.2 branch.
Discussion
----------
[Messenger] Doctrine setup with migrations
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? |
| Deprecations? | no
| Tickets | Fix#40130
| License | MIT
| Doc PR |
This PR reverts parts of #40055.
When running these commands, You do need to be in a transaction:
- `doctrine:schema:create`
- `messenger:setup-transports`
- `doctrine:migrations:diff` and `doctrine:migrations:migrate`
Commits
-------
3371e1cf39 [Messenger] Doctrine setup with migrations
This PR was merged into the 4.4 branch.
Discussion
----------
Add missing translations for Belarusian
| Q | A
| ------------- | ---
| Branch? | 4.4 <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix#38727 <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | N/A <!-- required for new features -->
Add translations for Belarusian
Commits
-------
1b84d5d23b Add translation for Belarusian
8e1d3285ed Adding templates for Belarusian
Marco Pivetta
Alexander M. Turek
Fabien Potencier
Robin Chalas
Elan Ruusamäe
shokhaa
Dane Powell
Ronny
Nyholm
fritzmg
OxanaKozlova