This PR was merged into the 4.4 branch.
Discussion
----------
[DoctrineBridge] Fix eventListener initialization when eventSubscriber constructor dispatch an event
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#40365
| License | MIT
| Doc PR | -
The issue occurred, when an EventSubscriber (lazyLoaded) dispatch an event when constructed. In that case, the state of the `ContainerAwareEventManager` become inconsistent for the triggered event:
- the `listener` property contains both listener instance and `serviceId` meaning it's not fully initialized
- the `initialized` property contains `true` meaning the listeners are initialized
Sorry for this PR without test, But it's really to hard to reproduce the issue :(
@parijke @michanismus @fliespl @reypm could you please check if this patch fixes the issue for you?
Commits
-------
b3ee29244f Fix eventListener initialization when eventSubscriber constructor dispatch an event
This PR was merged into the 4.4 branch.
Discussion
----------
[FrameworkBundle] Fix PropertyAccess definition when not in debug
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
The signature of the `PropertyAccessor::createCache()` method specifies that the first argument must be a string but in the `FameworkBundle` configures its DIC with a first argument to `null`. Replacing `null` by `''` allows to respect the contact of `PropertyAccessor::createCache()` and removes the following error when the `symfony/framework-bundle` is blocked in `4.4` but the symfony/property-access goes up to `5.2`.
```
Argument 3 passed to Symfony\Component\PropertyAccess\PropertyAccessor::createCache() must be of the type string, null given, called in /usr/src/app/var/cache/prod/ContainerDX7KWI4/getCache_PropertyAccessService.php on line 12
```
Commits
-------
116c54a554 Fix FrameworkBundle PropertyAccess definition when not in debug
This PR was merged into the 4.4 branch.
Discussion
----------
[Form] clear unchecked choice radio boxes even if clear missing is set to false
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#16802
| License | MIT
| Doc PR |
Commits
-------
e7b4851ea0 clear unchecked choice radio boxes even if clear missing is set to false
This PR was merged into the 5.3-dev branch.
Discussion
----------
[PropertyAccess] use bitwise flags to configure when the property accessor should throw
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | yes
| Tickets | Fix#31126
| License | MIT
| Doc PR |
Commits
-------
a50cfcb49d use bitwise flags to configure when the property accessor should throw
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Cache] boost perf by wrapping keys validity checks with `assert()`
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
PSR-6 has one perf hog: checking the validity of keys.
But in practice, an invalid key should never happen in production: encoding/cleanup is a must-have, and it's a step that should be identified *during dev*.
That's why I think we're safe wrapping these checks with `assert()`.
On an `ArrayAdapter`, this doubles the throughput of the pool when getting items.
I didn't use `assert()` in constructors when not on the hot path.
This PR also makes some callable properties static, as they should be from the beginning.
Commits
-------
8f03a1f555 [Cache] boost perf by wrapping keys validity checks with `assert()`
This PR was merged into the 4.4 branch.
Discussion
----------
[ErrorHandler] Added missing type annotations to FlattenException
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#40385
| License | MIT
| Doc PR | N/A
This class has no constructor where the properties' types could be inferred from. If we want potential contributors (and our serializer, see #40385) to read that code, I think it's only fair that we document the property types via doc blocks.
Commits
-------
d68832e1b9 [ErrorHandler] Added missing type annotations to FlattenException
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Console] Avoid unneeded preg_replace_callback
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| License | MIT
Motivations for this change:
* Avoid an unneded preg call, explode+implode is faster
* The previous regex created to suboptimal expressions,
due to the pipe that caused empty to be matched.
That means an input like `foo:bar`
was translated into `foo[^:]*[^:]*:bar[^:]*[^:]*`
instead of simply `foo[^:]*:bar[^:]*`
Commits
-------
daaa760fd2 Avoid unneeded preg_replace_callback in console application
Motivations for this change:
* Avoid an unneded preg call, explode+implode is faster
* The previous regex created to suboptimal expressions,
due to the pipe that caused empty to be matched.
That means an input like `foo:bar`
was translated into `foo[^:]*[^:]*:bar[^:]*[^:]*`
instead of simply `foo[^:]*:bar[^:]*`
This PR was merged into the 4.4 branch.
Discussion
----------
[TwigBridge] Allow version 3 of the Twig extra packages
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
Commits
-------
61b0be9564 [TwigBridge] Allow version 3 of the Twig extra packages
`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`.
* 5.2:
[WebLink] Removed unused property
Fix method name compare in ResolveControllerNameSubscriber
add uz security validator and form validator file
uzb translation
* 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 5.3-dev branch.
Discussion
----------
[Security] Decouple passwords from UserInterface
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | yes
| Tickets | #23081, helps with #39308
| License | MIT
| Doc PR | todo
This PR addresses a long-standing issue of the Security component: UserInterface is coupled to passwords.
It does it by moving the `getPassword()` method from `UserInterface` to a `PasswordAuthenticatedUserInterface`, and the `getSalt()` method to a `LegacyPasswordAuthenticatedUserInterface`.
Steps:
- In 5.3, we add the new interface and, at places where password-based authentication happens, trigger deprecation notices when a `UserInterface` object does not implement the new interface(s). The UserInterface is kept as-is until 6.0.
- In 6.0, we can remove the methods from `UserInterface` as well as support for using password authentication with user objects not implementing the new interface(s).
As a side-effect, some password-related interfaces (`UserPasswordHasherInterface` and `PasswordUpgraderInterface`) must change their signatures to type-hint against the new interface.
That is done in a BC way, which is to make the concerned methods virtual until 6.0, with deprecation notices triggered from callers and concrete implementations.
Benefits:
In 6.0, applications that use password-less authentication (e.g. login links) won't need to write no-op `getPassword()` and `getSalt()` in order to fulfil the `UserInterface` contract.
For applications that do use password-based authentication, they will need to opt-in explicitly by implementing the relevant interface(s).
This build on great discussions with @wouterj and @nicolas-grekas, and it is part of the overall rework of the Security component.
Commits
-------
2764225a38 [Security] Decouple passwords from UserInterface
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Notifier] [OvhCloud] Add "sender"
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features --> (I'm waiting to see if the feature is accepted )
Add "sender" option to the DSN that allows configuring the sender of the message.
OVHCloud manages two cases for sending sms according to the [doc](https://docs.ovh.com/fr/sms/envoyer_des_sms_avec_lapi_ovh_en_php/):
> The senderForResponse parameter will allow the use of a short number, which allows you to send SMS directly without having to create an alphanumeric sender (for example: your name).
> Short numbers also allow you to receive responses from the recipients of your SMS, which can be useful for a satisfaction survey, a voting application, a game, etc.
![CleanShot 2021-03-05 at 13 26 33](https://user-images.githubusercontent.com/523981/110115554-84c5af80-7db6-11eb-815d-7e8bafa81e5d.png)
This PR introduces the management of these 2 cases with a new option `sender`:
* if `sender` is set, we use it
* if `sender` is not set, we use `senderForResponse` to get a short number (current behavior)
I took the logic implementedin the old official SDK : 52d279e112/src/Message.php (L161)
Commits
-------
c5a9b252ab [Notifier] [OvhCloud] Add "sender"
This PR was merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection] Implement psr/container 1.1
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
The `psr/container` interfaces have been updated with type declarations. The lack of those is what kept us from adding property type declarations to the `get()` and `has()` methods of our own `ContainerInterface`.
A small BC break is that we have never prevented calling code from passing `null` as the service ID. Even without strict types, this will cause a `TypeError` after my changes. I already had to update `AutowirePass` because of that.
On the other hand, it was neither documented that we allow `null` here nor did the container do anything useful (`has(null)` always resulted in `false` and `get(null)` always returned `null`).
Commits
-------
d9095aa892 [DependencyInjection] Implement psr/container 1.1