This PR was merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection] Add `#[Target]` to tell how a dependency is used and hint named autowiring aliases
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Right now, when one wants to target a specific service in a list of candidates, we rely on the name of the argument in addition to the type-hint, eg:
`function foo(WorkflowInterface $reviewStateMachine)`
The deal is that by giving the argument a name that matches the target use case of the required dependency, we make autowiring more useful.
But sometimes, being able to de-correlate the name of the argument and the purpose is desired.
This PR introduces a new `#[Target]` attribute on PHP8 that allows doing so. The previous example could be written as such thanks to it:
`function foo(#[Target('review.state_machine')] WorkflowInterface $workflow)`
That's all folks :)
Commits
-------
cc76eab795 [DependencyInjection] Add `#[Target]` to tell how a dependency is used and hint named autowiring aliases
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Config] Support extensions without configuration in ConfigBuilder warmup
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
`ConfigurationExtensionInterface::getConfiguration()` is nullable.
As a real use-case: A small internal bundle in my company just uses `array_merge` to manage a very limited set of configuration. We don't have these fancy Configuration classes.
Commits
-------
0a6f5e50b7 [Config] Support extensions without configuration
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Notifier] Add missing entries in scheme to package map
| Q | A
| ------------- | ---
| Branch? | 5.x
| 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 -->
<!--
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
-------
8cf605062b Add missing entries in scheme to package map
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Notifier] Notifier add test for adding transport factories to framework extension
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| 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 -->
Follow up of https://github.com/symfony/symfony/pull/40843 and https://github.com/symfony/symfony/pull/40844
Needs to be rebased after both were merged.
See changes: ddf61c2dae
Commits
-------
3118c9088a Make sure we will not forget to add notifier transport factories to FrameworkExtension anymore
This PR was merged into the 5.3-dev branch.
Discussion
----------
[SecurityBundle] Deprecate public services to private
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | yes
| Tickets | -
| License | MIT
| Doc PR | -
Follow up of https://github.com/symfony/symfony/pull/36691 on the SecurityBundle
Commits
-------
56be86aa7d [SecurityBundle] Deprecate public services to private
This PR was merged into the 5.3-dev branch.
Discussion
----------
[FrameworkBundle] Add basic tests for the notifier framework bundle integration
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| 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 -->
This PR adds basic tests for the notifier framework bundle integration:
- [x] Adjust the symfony-1.0.xsd and define the notifier type
- [x] Add general notifier configuration tests in FrameworkExtensionTest
Commits
-------
47088eb53a Add basic notifier tests
This PR was merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection] Add `#[When(env: 'foo')]` to skip autoregistering a class when the env doesn't match
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
This is a follow up of #40214, in order to conditionally auto-register classes.
By adding a `#[When(env: prod)]` annotation on a class, one can tell that a class should be skipped when the current env doesn't match the one declared in the attribute.
This saves from writing similar conditional configuration by using the per-env `services_prod.yaml` convention (+corresponding exclusion from `services.yaml`), or some logic in the Kernel.
Commits
-------
59c75bad7b [DI] add `#[When(env: 'foo')]` to skip autoregistering a class when the env doesn't match
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Security] Add passport to AuthenticationTokenCreatedEvent
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| License | MIT
This is a follow-up to my previous PR #37359, which added `AuthenticationTokenCreatedEvent` to the new authenticator-based security system to inspect the security token before it becomes effective to the security system. It **adds the passport** that was used to generate that token to the event, so that it can be inspected as well.
Reasoning:
1) It makes the event more aligned with other security events (which are also providing the passport)
2) I see valid use-cases when you'd want to look into the passport/badges to decide if you'd want to make modifications to the security token. @seldaek mentioned to me in scheb/2fa#74 that he'd like to have the ability to add a badge from his custom authenticator class, which then influences 2fa being triggered or not. Having the passport in the event would make that a straight forward task.
I would like to add this to Symfony 5.3, since @wouterj plans to stabilize the authenticator security system for that release, so I believe this is worth adding it now rather than later. The constructor change could be considered a BC break, but since authenticator system is experimental, I believe it's fair to make that change now before declaring it "stable".
Commits
-------
74196e0750 Add passport to AuthenticationTokenCreatedEvent
* 5.2:
[DoctrineBridge] Allow bundles to define a driver type "attribute"
fix test SocketStreamTest for Windows
Fix issue with RequestMatcher when attribute is a closure
[PropertyInfo] Use the right context for methods defined in traits
* 4.4:
[DoctrineBridge] Allow bundles to define a driver type "attribute"
fix test SocketStreamTest for Windows
Fix issue with RequestMatcher when attribute is a closure
[PropertyInfo] Use the right context for methods defined in traits
This PR was merged into the 5.2 branch.
Discussion
----------
[FrameworkBundle] Fix array controller link in debug:router
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
`debug:router` is broken when you add a route in the Kernel (see https://symfony.com/doc/current/configuration/micro_kernel_trait.html) because `kernel` is not a class and triggers a `\ReflectionException`. The code in the exception handling always expect `$controller` to be a string.
Commits
-------
be964bdfa6 [FrameworkBundle] Fix array controller link in debug:router
This PR was merged into the 4.4 branch.
Discussion
----------
[Mailer] Fix SocketStreamTest for windows
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? |no
| Tickets | -
| License | MIT
| Doc PR | -
**How to reproduce**
PHP 8.0.3
PHPUnit 9.5.4
c:\php\php ./phpunit --bootstrap ./vendor/autoload.php --configuration ./phpunit.xml.dist --filter "/(SocketStreamTest::testSocketErrorNoConnection)( .*)?$/" --test-suffix SocketStreamTest.php ./src/Symfony/Component/Mailer/Tests/Transport/Smtp/Stream --testdox
Failed asserting that exception message 'Connection could not be established with host "ssl://localhost:9999": stream_socket_client(): Unable to connect to ssl://localhost:9999 (A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond)' matches '/Connection refused|unable to connect/'.
Commits
-------
a46fce402c fix test SocketStreamTest for Windows
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[FrameworkBundle] Add AbstractController::handleForm() helper
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | n/a
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/15217
Some libraries such as Turbo require to strictly follow the HTTP specification (and especially to use proper status codes) to deal with forms.
In https://github.com/symfony/symfony/pull/39843, I introduced a new `renderForm()` helper for this purpose. But I'm not very satisfied by it. The current approach has several problems:
1. It calls `$form->isValid()` two times, which may hurt performance
2. It sets the proper status code in case of validation error (422), but not for the redirection when the entity is created or updated (306). The user must do this manually (and so be aware of these HTTP subtleties).
3. It hides the verbosity of the Form component a bit, but I'm a sure that we can reduce it more
This PR proposes an alternative helper, `handleForm()`, which handles automatically 80% of the use cases, provide an extension point for the other 20%, and can also serve as a quick example for users to handle form in a custom way (by control-clicking on the function to see the code and copy/paste/adapt it).
* if the form is not submitted, the Twig template passed in $view is rendered and a 200 HTTP status code is set
* if the form is submitted but invalid, the Twig template passed in $view is rendered and 422 HTTP status code is set
* if the form is submitted and valid, the entity is saved (only if it is managed by Doctrine ORM), a 306 HTTP status code is set and the Location HTTP header is set to the value of $redirectUrl
Before (standard case):
```php
#[Route('/{id}/edit', name: 'conference_edit', methods: ['GET', 'POST'])]
public function edit(Request $request, Conference $conference): Response
{
$form = $this->createForm(ConferenceType::class, $conference);
$form->handleRequest($request);
$submitted = $form->isSubmitted();
$valid = $submitted && $form->isValid();
if ($valid) {
$this->getDoctrine()->getManager()->flush();
return $this->redirectToRoute('conference_index', [], Response::HTTP_SEE_OTHER);
}
$response = $this->render('conference/edit.html.twig', [
'conference' => $conference,
'form' => $form->createView(),
]);
if ($submitted && !$valid) {
$response->setStatusCode(Response::HTTP_UNPROCESSABLE_ENTITY);
}
return $response;
}
```
With the new helper:
```php
#[Route('/{id}/edit', name: 'conference_edit', methods: ['GET', 'POST'])]
public function edit(Request $request, Conference $conference): Response
{
$form = $this->createForm(ConferenceType::class, $conference);
return $this->handleForm(
$request,
$form,
view: 'conference/edit.html.twig',
redirectUrl: $this->generateUrl('conference_index')
);
}
```
Before (more advanced use case):
```php
#[Route('/{id}/edit', name: 'conference_edit', methods: ['GET', 'POST'])]
public function edit(Request $request, Conference $conference, HubInterface $hub): Response
{
$form = $this->createForm(ConferenceType::class, $conference);
$form->handleRequest($request);
$submitted = $form->isSubmitted();
$valid = $submitted && $form->isValid();
if ($valid) {
$this->getDoctrine()->getManager()->flush();
$hub->publish(
new Update(
'conference:'.$conference->getId(),
$this->renderView('conference/edit.stream.html.twig', ['conference' => $conference])
)
);
return $this->redirectToRoute('conference_index', [], Response::HTTP_SEE_OTHER);
}
$response = $this->render('conference/edit.html.twig', [
'conference' => $conference,
'form' => $form->createView(),
]);
if ($submitted && !$valid) {
$response->setStatusCode(Response::HTTP_UNPROCESSABLE_ENTITY);
}
return $response;
}
```
With the new helper (more advanced case):
```php
#[Route('/{id}/edit', name: 'conference_edit', methods: ['GET', 'POST'])]
public function edit(Request $request, Conference $conference, HubInterface $hub): Response
{
$form = $this->createForm(ConferenceType::class, $conference);
$response = $this->handleForm(
$request,
$form,
view: 'conference/edit.html.twig',
redirectUrl: $this->generateUrl('conference_index')
);
if ($response->isRedirection()) {
$hub->publish(
new Update(
'conference:' . $conference->getId(),
$this->renderView('conference/edit.stream.html.twig', ['conference' => $conference])
)
);
}
return $response;
}
```
This also works without named parameters. I also considered passing a callback to be executed on success, but I'm happier with the current solution.
WDYT?
TODO:
* [x] update tests
Commits
-------
5228546066 [FrameworkBundle] Add AbstractController::handleForm() helper
This PR was merged into the 4.4 branch.
Discussion
----------
[DoctrineBridge] Add support for a driver type "attribute"
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| License | MIT
Without this change its not possible to use attributes for mapping when they get released in ORM 2.9 over the next days. Otherwise we would need to copy three methods from the `AbstractDoctrineExtension` into the Bundle. See the DoctrineBundle PR that makes the full changes: https://github.com/doctrine/DoctrineBundle/pull/1322
Commits
-------
cecaa7815a [DoctrineBridge] Allow bundles to define a driver type "attribute"
Code caused following error - 'Unable to post the Microsoft Teams message: ... Summary or Text is required. '. The structure of the message should contain the 'text' attribute instead of 'title'.
This PR was merged into the 4.4 branch.
Discussion
----------
RequestMatcher issue when `_controller` is a closure
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| License | MIT
## Description
If the `matches` method of `RequestMatcher` is used on an attribute which is a closure it crashes.
## How did we get it
On a project that is using FOS HTTP Cache, we have this configuration
```yaml
fos_http_cache:
cache_control:
rules:
-
match:
attributes: { _controller: ^App\\Controller\\.*::.* }
headers:
overwrite: true
cache_control: { public: true, private: false, must_revalidate: true, s_maxage: 3600 }
```
Everything works fine unless you are reaching a controller that is a closure.
You get a
```TypeError: preg_match(): Argument #2 ($subject) must be of type string, Closure given``` which is to me logical.
## Proposed solution
Just testing the type of attribute value and return false before crashing `preg_match`
This PR adds a quick unit test to enforce this.
Commits
-------
66491238e3 Fix issue with RequestMatcher when attribute is a closure
This PR was merged into the 4.4 branch.
Discussion
----------
[PropertyInfo] Use the right context for methods defined in traits
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#34191
| License | MIT
| Doc PR |
Pull request #40175 only partially fixed#34191 - it solved the problem for properties used in traits but it did not address the same issue with methods.
I have therefore applied the same style of fix and confirmed it works properly with tests.
Commits
-------
c7e9493c5b [PropertyInfo] Use the right context for methods defined in traits
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Intl] Switch from json to php resources
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix #23545
| License | MIT
| Doc PR | -
take over #34214
Commits
-------
24bfc3bedd [Intl] Switch from json to php resources
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Routing] Fix supporting string "methods" and "schemes" on the Route annotation
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/40796
| License | MIT
| Doc PR | -
Commits
-------
b5f61c31e5 [Routing] Fix supporting string "methods" and "schemes" on the Route annotation
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Config] Don't regenerate the ConfigBuilders if they already exists
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes... or optimisation
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
When the user is trying to use the `Symfony\Config\AcmeConfig` ConfigBuilder, the `PhpFileLoader` will check if this class is loaded (ie `class_exists()`. Since it is normally generated and put in the `kernel.build_dir`, the class is not found by a PSR-4 class loader. So the `class_exists()` check will most likely fail. It will only return true if a third party bundle define `Symfony\Config\AcmeConfig` and make sure it is loaded with their composer.json. This is a great feature for third party bundles to be able to provide a config class.
However, if the class `Symfony\Config\AcmeConfig` does not exist, we try to generate it. Always... Which means that every time you rebuild the container, we generate these files.
This PR will do a check if `kernel.build_dir/Symfony/Config/AcmeConfig.php` exists first, and generate the file only if it is missing.
Commits
-------
88896e8d57 [Config] Don't regenerate the ConfigBuilders if they already exists
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Config][FrameworkBundle] Add CacheWarmer for ConfigBuilder
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? |
| Tickets |
| License | MIT
| Doc PR |
Make sure ConfigBuilder exists before you write your first line of config.
This is similar to #40803
Commits
-------
c1d6c0e57a [Config][FrameworkBundle] Add CacheWarmer for ConfigBuilder
This PR was merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection][Routing] Access environment in PHP config
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? |
| Tickets |
| License | MIT
| Doc PR |
This will allow me to write config like:
```php
use Symfony\Config\FrameworkConfig;
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;
return static function (FrameworkConfig $framework, ContainerConfigurator $container) {
if ('test' === $container->env()) {
$framework->test(true);
$framework->session()->storageFactoryId('session.storage.mock_file');
}
};
```
This PR will also revert parts of #40214. It is much simpler to maintain and write PHP config without `->when()`. Instead we add `ContainerConfigurator::env(): ?string` and `RoutingConfigurator::env(): ?string`.
```php
use App\Controller\BlogController;
use Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator;
return function (RoutingConfigurator $routes) {
if ($routes->env() === 'dev') {
$routes->add('debug-stats', '/blog-debyg')
->controller([BlogController::class, 'debug'])
;
}
$routes->add('blog_list', '/blog')
->controller([BlogController::class, 'list'])
;
};
```
Commits
-------
11dfaa4742 [DependencyInjection][Routing] Access environment in PHP config
This PR was merged into the 5.3-dev branch.
Discussion
----------
Improve deprecation message for session
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
The `session` service is not public since we deprecate it, which lead to headache when people migrate to 5.3:
When people expect the service to be public (like in tests), the service does not exist anymore (removed or inlined), it's now an alias to `.session.do-not-use` and deprecation telling how to migrate has not been triggered because the service has been removed / inlined.
This PR makes the `session` service/alias public, and also improves the deprecation message a little bit.
/cc @javiereguiluz , @wouterj
Commits
-------
b568768cec Improvide deprecation message for session
This PR was merged into the 5.3-dev branch.
Discussion
----------
Remove the experimental flag from the authenticator system 🚀
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | todo
Here we go.
Commits
-------
a2f5693c5e Remove experimental flag from the authenticator system 🚀
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Form] Add support for sorting fields
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#5827
| License | MIT
| Doc PR | TODO
This PR adds a new `priority` option used later to sort all fields in order of importance instead of simply numerical order, i.e. fields with higher priority will be rendered first, fields with lower priority will be rendered last. The default priority would be "0" for all fields. Fields with equal priority will keep the original order (stable sorting).
History of previous proposals and discussions: #3452, #4254, #5827, #6111, #11241
This kind of feature has been abandoned in the past because complex proposals, and somehow rejected because ideally we should do the sorting at the view level ([customizing form](https://symfony.com/doc/current/form/form_customization.html) themes or layout templates) and it's true for most cases (the simple ones I think) but the fact is that it's often quite complex to accomplish that way, mainly for [dynamic forms](https://symfony.com/doc/current/form/dynamic_form_modification.html).
Let's focus the following analysis on explaining *why* and *when* the `priority` option could save us a lot of time, getting rid of cumbersome workarounds with templates to change the rendering order *only*.
---
A common example could be the building of a multi-steps form with a convenient type hierarchy and including fields dynamically based on the data. Let's take this sample:
```php
class WorkflowType extends AbstractType
{
public function buildForm(FormBuilderInterface $builder, array $options)
{
// get current enabled transitions from the workflow definition...
foreach ($enabledTransitions as $transitionName) {
$builder->add($transitionName, SubmitType::class, ['attr' => ['value' => $transitionName]]);
}
}
}
class PersonRegistrationType extends AbstractType
{
public function buildForm(FormBuilderInterface $builder, array $options)
{
$builder
->add('firstName')
->add('lastName');
$builder->addEventListener(FormEvents::PRE_SET_DATA, function (FormEvent $event) {
$person = $event->getData();
if ($person->isLegalType()) {
$event->getForm()->add('company');
}
});
}
public function getParent()
{
return WorkflowType::class;
}
}
```
These classes model the required form. However, according to the form building process and taken into account that the underlaying person data was set with "legal" type (from the previous step), this will be the rendering result:
```html
<button type="submit" name="form[register]" value="register">Register</button> {# wrong place #}
<input name="form[first_name]">
<input name="form[last_name]">
<input name="form[company]"> {# wrong place #}
```
Now, taking the view customization path to fix the order, you likely will face some problems regarding to:
- How do I render the dynamic submit buttons at the bottom?
- How can the specific form fields be rendered in the correct order if they vary from step to step? (being it a generic template)
- if you solve the previous questions, you will also need to check if the company field is defined or not before rendering it in the right order.
There could be more and different problems depending on the context and you can find workarounds using the block prefixes system to customize each step block theme, but to me it's enough to think about other alternatives.
On the other side, using the `priority` option, the solution is quite easy. Setting the right priority value will guarantee the right rendering order:
```php
// ...
$builder->add($transitionName, SubmitType::class, ['priority' => -1, // ...]);
// ...
$event->getForm()->add('company', null, ['priority' => 1]);
```
That's ! There is no need to customize templates at all when you only need to change the fields order.
This way, these fields are being pre-defined in the order they will be rendered at view level. This sorting process will take place on `$form->createView()` method, just after `buildView()` and before `finishView()` calls.
Could we reconsider the usefulness of this feature? please.
Cheers!
Commits
-------
62650bbdc7 [Form] Add support for sorting fields
This PR was merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection] Autowire arguments using attributes
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | TODO
This PR allows us to bind arguments via attributes. This mechanism is enabled for tagged iterators and service locators for now.
To receive an iterator with all services tagged with `my_tag`:
```php
use Symfony\Component\DependencyInjection\Attribute\TaggedIterator;
class MyService
{
public function __construct(
#[TaggedIterator('my_tag')]
private iterator $taggedServices,
) {
}
}
```
To receive a locator with all services tagged with `my_tag`:
```php
use Psr\Container\ContainerInterface;
use Symfony\Component\DependencyInjection\Attribute\TaggedLocator;
class MyService
{
public function __construct(
#[TaggedLocator('my_tag')]
private ContainerInterface $taggedServices,
) {
}
}
```
Commits
-------
91fbc90238 Autowire arguments using attributes
b86aa3d068 [DependencyInjection] Bind constructor arguments via attributes
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Messenger] Support Redis Cluster
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#38264
| License | MIT
| Doc PR | symfony/symfony-docs#14956
This PR brings support for Redis Cluster in the Messenger component:
- The first commit _Support RedisCluster instance_ allows to pass a `RedisCluster` object when instanciating the `Connection` class, which brings support for Redis Cluster without any friction.
- The second commit _Support multiple hosts DSN for Redis Cluster_ is more opiniated and brings a DSN format to configure a Redis Cluster from `config/packages/messenger.yaml`.
Instanciating `Connection` with a `RedisCluster` object:
```php
$redis = new \RedisCluster(null, ['host-01:6379', 'host-02:6379', 'host-03:6379', 'host-04:6379']);
$connection = new Connection([], [], [], $redis);
```
Configuring a Redis Cluster from YAML:
```yaml
// config/packages/messenger.yaml
framework:
messenger:
metadata:
default: 'redis://host-01:6379,redis://host-02:6379,redis://host-03:6379'
lazy: 'redis://host-01:6379?lazy=1,redis://host-02:6379,redis://host-03:6379'
# Configuration will be `lazy = true` and `auto_setup = true`
multipleConfig: 'redis://host-01:6379?lazy=1&auto_setup=false,redis://host-02:6379,redis://host-03:6379?auto_setup=true'
```
This format allows to define multiple hosts for a Redis Cluster and still contains valid URLs. Custom configuration is still supported, it can be specified on only one of the URLs in the DSN (see `lazy` above). If the user provides multiple configurations on different URLs, they are simply merged with the following code and if an option is defined multiple times then the latest takes precedence (see `multipleConfig` above).
I understand the way the DSN is handled could not suit you. Please, if you close this PR only for the DSN part, just tell me and I will make a new PR with only the first commit.
Commits
-------
04530fb2d7 [Messenger] Support Redis Cluster
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Config][DependencyInjection] Add configuration builder for writing PHP config
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/15181
I've spent most part of today to generate this PR. It is far from complete but it is ready for review.
This PR will build classes and store them in the build_dir. The classes will help you write PHP config. It will basically generate an array for you.
### Before
```php
// config/packages/security.php
<?php
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;
return static function (ContainerConfigurator $container) {
$array = [
'firewalls' => [
'main' => [
'pattern' => '^/*',
'lazy' => true,
'anonymous' => [],
],
],
'access_control' => [
[
'path' => '^/user',
'roles' => [
0 => 'ROLE_USER',
],
],
[
'path' => '^/admin',
'roles' => 'ROLE_ADMIN',
],
],
'role_hierarchy' => [
'ROLE_ADMIN' => ['ROLE_USER'],
'ROLE_SUPER_ADMIN' => ['ROLE_ADMIN', 'ROLE_ALLOWED_TO_SWITCH',
],
],
];
$container->extension('security', $array);
}
```
### After
```php
// config/packages/security.php
<?php
use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
$security
->roleHierarchy('ROLE_ADMIN', ['ROLE_USER'])
->roleHierarchy('ROLE_SUPER_ADMIN', ['ROLE_ADMIN', 'ROLE_ALLOWED_TO_SWITCH'])
->accessControl()
->path('^/user')
->role('ROLE_USER');
$security->accessControl(['path' => '^/admin', 'roles' => 'ROLE_ADMIN']);
$security->firewall('main')
->pattern('^/*')
->lazy(true)
->anonymous();
};
```
### About autogeneration
This PR is generating the extension's `ConfigBuilder`s when they are first used. Since the PR is already very large, I prefer to follow up with additional PRs to include a cache warmer and command to rebuild the `ConfigBuilder`s.
The generated `ConfigBuilder` uses a "ucfirst() camelCased" extension alias. If the alias is `acme_foo` the root `ConfigBuilder` will be `Symfony\Config\AcmeFooConfig`.
The recommended way of using this class is:
```php
// config/packages/acme_foo.php
use Symfony\Config\AcmeFooConfig;
return static function (AcmeFooConfig $foo) {
// ...
// No need to return
}
```
One may also init the class directly, But this will not help you with generation or autoloading
```php
// config/packages/acme_foo.php
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;
return static function (ContainerConfigurator $container) {
$foo = new \Symfony\Config\AcmeFooConfig();
// ...
$container->extension('acme_foo', $foo->toArray());
}
```
**I do think we should only talk about the first way**
If a third party bundle like this idea and want to provide their own `ConfigBuilder`, they have two options:
1) Create the class `Symfony\Config\TheBundleConfig` themselves and make sure they configure composer to autoload that file and that the class implements `ConfigBuilderInterface`. We will never regenerate a file that already exists.
2) Create any class implementing `ConfigBuilderInterface` and ask their users to use that class in their config in the same way they would use `Symfony\Config\TheBundleConfig`.
The first way is obviously the smoothest way of doing things.
### BC
There is a great discussion about backwards compatibility for the generated files. We can assure that the class generator don't introduce a BC break with our tests. However, if the bundle changes their configuration definition it may break BC. Things like renaming, changing type or changing a single value to array is obvious BC breaks, however, these can be fixed in the config definition with normalisation.
The generator does not support normalisation. It is way way more complicated to reverse engineer that. I think a future update could fix this in one of two ways:
1) Add extra definition rules to help the class generator
2) Allow the bundle to patch part of the generated code
I hate BC breaks as much as the next person, but all the BC breaks in the generated classes will be caught when building the container (not at runtime), so I am fine with not having a 100% complete solution for this issue in the initial PR.
### Other limitations
If a bundle is using a custom extension alias, then we cannot guess it.. so a user have to use a cache warmer because we cannot generate the `ConfigBuilder` on the fly.
### TODO
- [x] Add tests
- [x] Update changelog
- [x] Write documentation
-------------
The generated code can be found in this example app: https://github.com/Nyholm/sf-issue-40600/tree/main/var/cache/dev/Symfony/Config
Commits
-------
460b46f730 [Config][DependencyInjection] Add configuration builder for writing PHP config
* 5.2:
[WebProfiler] Use ControllerReference instead of URL in twig render()
[Serializer][Validator] Update some phpDoc relative to "getters"
Update README.md
[SecurityBundle] Empty line starting with dash under "access_control" causes all rules to be skipped
[Cache] Apply NullAdapter as Null Object
* 4.4:
[Serializer][Validator] Update some phpDoc relative to "getters"
Update README.md
[SecurityBundle] Empty line starting with dash under "access_control" causes all rules to be skipped
[Cache] Apply NullAdapter as Null Object
This PR was merged into the 5.2 branch.
Discussion
----------
[WebProfilerBundle] Use ControllerReference instead of URL in twig render()
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#40709
| License | MIT
| Doc PR |
Use `ControllerReference` instead of `UrlGenerator`'s URL. Helps to deal with different baseUrl
Feel free to help me with some advice. Thank you in advance
Commits
-------
f2ee8bc7ae [WebProfiler] Use ControllerReference instead of URL in twig render()
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Security] Stop using a shared changelog for our security packages
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
I understand there are historical reasons for why our four security packages share a changelog. However, I dont believe it makes much sense moving forward.
I suggest that ~~6.0~~ will start using separate changelogs.
#### Update
Lets start in 5.4 for the reasons explained by Christophe
Commits
-------
0b1103ae48 [Security] Stop using a shared changelog for our security packages
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Security] [LoginLink] remove experimental
| Q | A
| ------------- | ---
| Branch? | 5.3
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | tbd
Symfony's new security Login Link functionality is no longer experimental as of 5.3
Commits
-------
f2842f26e7 [Security][LoginLink] remove experimental
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Workflow] Add Mermaid.js dumper
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | #40165
| License | MIT
| Doc PR | symfony/symfony-docs#15102
Mermaid is - next to PlantUML - one of the most popular simple graphing solutions. This workflow dumper mirrors the feature set of the PlantUML dumper except that Mermaid does not currently support colored transitions.
**Things I need help with:**
- ~I basically tried to copy the code style of the surrounding files and hope everything is conforming. Please let me know if I missed something.~ I see, that's the magic of fabbot. Nice. ❤️
- There are currently no tests for the different graph direction constants, I can add those, just did not see value in doing so yet.
- I am unsure how to integrate this with the current documentation. This however is likely better discussed in the corresponding issue (see above).
Commits
-------
ada6f7d315 [Workflow] Add Mermaid.js dumper
This PR was merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection] Allow calling custom processors directly on EnvConfigurator
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
This is a proposition of addition to the feature added by https://github.com/symfony/symfony/pull/40682 to allow calling custom processors in the same way we call builtin ones. This is not perfect since it doesn't allow auto-completion for these custom methods but I think this provides a cleaner API for custom processors.
Commits
-------
1d008f76da Allow calling custom processors directly on EnvConfigurator
This PR was merged into the 5.3-dev branch.
Discussion
----------
[MonologBridge] Reset loggers on workers
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
This PR tries to solve some problems with buffered handlers (FingerCrossed) in workers.
Let's consider the default configuration (`stop_buffering: true`):
- When the threshold is crossed, all logs are flushed. Logs for the current message but also logs of previous messages in the buffer. Although buffer is limited `buffer_size`, it's a shame to keep logs of previous messages.
- When the threshold is crossed, buffering is disabled. So finger crossed configuration is not used anymore, all the logs are flushed as soon as they are written.
Then with (`stop_buffering: false`) (why isn't this the default configuration ?)
- It's a bit better since buffering isn't disabled when the threshold is crossed
- Like with `stop_buffering: true`, logs of previous messages are kept in memory
In a similar way of `DoctrineClearEntityManagerWorkerSubscriber`, this PR adds a `ResetLoggersWorkerSubscribber` to reset resettable loggers.
Integration in Monolog bundle: symfony/monolog-bundle#403
Commits
-------
1d2f7f1f87 [Messenger] Reset loggers on workers
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Serializer][Validator] Update some phpDoc relative to "getters"
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yesish (phpDoc unaccurate after code updates)
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Commits
-------
5046500deb [Serializer][Validator] Update some phpDoc relative to "getters"
This PR was merged into the 4.4 branch.
Discussion
----------
Update README.md
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | yes as doc
| Tickets | see desc
| License | MIT
| Doc PR | .
Related to https://packagist.org/packages/symfony/web-server-bundle/stats
Also I do have a question, do Symfony uses the https://getcomposer.org/doc/04-schema.md#abandoned feature?
It can be useful I think
I’ve seen many differents way, inside the repo readme, via github repo description with [DEPRECATED], even marking the repo as readonly
IMHO a similar aproach should be done for all packages of the organisation :)
Commits
-------
37b19d9c06 Update README.md
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Security] Deprecate using UsageTrackingTokenStorage outside the request-response cycle
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | yes
| New feature? | no
| Deprecations? | yes
| Tickets | Fix#40778
| License | MIT
| Doc PR | -
Currently, you get an "There is currently no session available" exception when using the `security.token_storage` service outside the main request-response cycle (e.g. in a `kernel.terminate` listener). This PR deprecates such usage and requires developers to update their definitions to explicitly use `security.untracked_token_storage` instead.
A different solution would be to silently disable tracking in these cases, but I think that might create some unnecessary technical debt.
Commits
-------
7452476156 [Security] Fix UsageTrackingTokenStorage outside the request cycle
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Messenger] Add X-Ray trace header support to the SQS transport
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
aws documentation: https://docs.aws.amazon.com/xray/latest/devguide/xray-services-sqs.html
Commits
-------
5fa7ff9541 [Messenger] Added X-Ray trace header support to the SQS transport
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[SecurityBundle] Empty line starting with dash under "access_control" causes all rules to be skipped
| 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 | Fix#40235 ... <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License | MIT
When the IDE by mistake puts an empty line in `access_control` in security.yaml there is no warning that we have an empty row, making the rest of routes defined, to be ignored and possible to be accessed by anyone that can authenticate no matter the role.
# How to reproduce the issue
- git clone git@github.com:monteiro/symfony-issue-40235.git
- composer install
- symfony server:start
- open 127.0.0.1:8000/admin with username: "john_user" and password "123456"
- Since that user has only ROLE_USER should not be able to access the route... but because there is an empty line in "access_control" in `security.yaml`, "by mistake" it is possible to access the protected `ROLE_ADMIN` route.
Commits
-------
ee26ce5987 [SecurityBundle] Empty line starting with dash under "access_control" causes all rules to be skipped
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Cache] Apply NullAdapter as Null Object
| 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 | Fix https://github.com/symfony/symfony/issues/40753
| License | MIT
<!--| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
There is a problem with the NullAdapter if I have to add an expression to work:
```php
$adapter = new NullAdapter();
$item = new CacheItem();
$item->set('FooBar');
if (!$adapter->save($item) && !($adapter instanceof NullAdapter)) {
throw new Exception('Uoh oh');
}
```
So the goal here is to modify the methods that are causing a problem to behave as a Null Object.
Commits
-------
f6818eb7ac [Cache] Apply NullAdapter as Null Object
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[HttpKernel] Minor fixes and tweaks in the Symfony Welcome Page
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | (not needed)
The current "Welcome Page" has a minor issue related to CSS flexbox. See how the "debug mode" text looks in smaller screens:
The solution is to wrap the contents in a HTML element such as `<p>`, but this PR also does some other minor tweaks. This is how it'd look now:
Commits
-------
ee49cfe2b9 [HttpKernel] Minor fixes and tweaks in the Symfony Welcome Page
* 5.2:
[HttpClient][PHPDoc] Fix 2 remaining return mixed
[Cache] [FrameworkBundle] Fix logging for TagAwareAdapter
[Route] Better inline requirements and defaults parsing
Simplified condition and removed unused code from AbstractSessionListener::onKernelRequest
[PhpUnitBridge] Fix phpunit symlink on Windows
[Yaml] Fixed infinite loop when parser goes through an additional and invalid closing tag
[Form] Fix 'invalid_message' use in multiple ChoiceType
* 4.4:
[HttpClient][PHPDoc] Fix 2 remaining return mixed
[Cache] [FrameworkBundle] Fix logging for TagAwareAdapter
[Route] Better inline requirements and defaults parsing
Simplified condition and removed unused code from AbstractSessionListener::onKernelRequest
[PhpUnitBridge] Fix phpunit symlink on Windows
[Yaml] Fixed infinite loop when parser goes through an additional and invalid closing tag
This PR was merged into the 5.3-dev branch.
Discussion
----------
[DependencyInjection] Add env() and EnvConfigurator in the PHP-DSL
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Recently, I have been using env var processors a lot. This is a proposition to improve the DX a bit when you use the PHP-DSL to configure services.
Firstly, I am "annoyed" by the fact that I can do `param('my_param')` but not `env('MY_ENV')`.
Secondly, long chains of env var processors (eg: `%env(default:my_param:key:path:url:MY_ENV_VAR)` have two issues:
- you must construct and read them in "reverse"
- some env var processor are actually composed of 2 parts (key:path), you don't distinguish them easily from the rest
Before:
```php
->arg('$myArg', '%env(default:my_param:key:path:url:MY_ENV_VAR)%')
```
After:
```php
->arg(
'$myArg',
env('MY_ENV_VAR')
->url()
->key('path')
->default('my_param')
)
```
Custom env var processor would be callable with `->custom('my_custom_env_var_processor')` or you could extend the configurator and add your own methods.
WDYT?
Commits
-------
5f0fe3235f [DependencyInjection] Add env() and EnvConfigurator in the PHP-DSL
Remove ! symbol from requirements and defaults array keys in Route class. Leave ! symbol in Route compiled path for correct token creation
Added some inline route settings tests
This PR was merged into the 4.4 branch.
Discussion
----------
[PhpUnitBridge] Fix phpunit symlink on Windows
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
If the symlink to `.phpunit/phpunit` already exists, unlink is called to remove it. But this fails on Windows (because it is a directory and requires `rmdir`), which in turn causes the subsequent `symlink` call to fail (because it already exists).
Additionally, creating symlinks on Windows requires Administrator permissions (generally), so `.phpunit/phpunit` can never be created for ordinary Users.
This PR uses a junction instead of a symlink on Windows. It also fixes some issues with stderror output and adds some argument escaping.
Commits
-------
ff8093246b [PhpUnitBridge] Fix phpunit symlink on Windows
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Security] Rework the remember me system
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fixes part of #39308
| License | MIT
| Doc PR | tbd
As I said in #39308, I want to change the remember me system in Symfony 5.3. The remember me system has a couple big "problems":
1. **It's hardwired into some Security classes** like `ContextListener`. The `RememberMeFactory` adds a `setRememberMe()` method call to the DI config and the context listener calls methods on this. This is very coupled, instead of the decoupled nature of the rest of security.
2. **Conditional conditions are combined with cookie creation in one class**. This is especially hard in e.g. 2FA (where setting the cookie should be done after 2FA is completed, which is currently near impossible as it's directly bound to the conditional of being called after logging in).
The changes
---
* The first commits harden the current functional test suite of remember me, to avoid breaking it.
* I discovered a lot of similarity between remember me tokens and login links. That's why I've extracted the shared logic into a generic `SignatureHasher` in the 3rd commit.
* I then remodelled `RememberMeAuthenticator` to the login link system, which I think improves a lot and at least improves problem (2) - as the conditionals (`RememberMeAuthenticator`) is split from the cookie creation (`RememberMeHandlerInterface`).
* Finally, I added a new event (`TokenDeauthenticatedEvent`) to the `ContextListener` to avoid direct coupling - solving problem (1).
This removes any usage of remember me services, which can be deprecated along with the rest of the security system.
Usage
---
As with the authenticator manager: **Nothing changes in the configuration**
Usage of persistent token providers has been improved. First, configuration is provided (setting up services is no longer needed):
```yaml
# before
services:
Symfony\Bridge\Doctrine\Security\RememberMe\DoctrineTokenProvider:
autowire: true
security:
firewalls:
main:
remember_me:
# ...
token_provider: 'Symfony\Bridge\Doctrine\Security\RememberMe\DoctrineTokenProvider'
# after
security:
firewalls:
main:
remember_me:
# ...
token_provider:
doctrine: true
```
Furthermore, a schema listener is created. Whenever the doctrine token provider is used, `make:migration`/`doctrine:schema:update` will automatically create the required table.
Some advanced usage of Remember me is also improved a lot (there is no real "before" here, consider looking at scheb/2fa to get an idea of the before). A few use-cases I took into account:
* If you ever need to **programmatically create a remember me cookie**, you can autowire `RememberMeHandlerInterface` and use `createRememberMeCookie($user)`. This will make sure the remember me cookie is set on the final response (using the `ResponseListener`)
* The `RememberMeListener` previously was responsible for both determining if a cookie must be set and setting the cookie. This is now split in 2 listeners (checking is done by `RememberMeConditionsListener`). If `RememberMeBadge` is enabled, the cookie is set and otherwise it isn't. This allows e.g. SchebTwoFactorBundle to create a listener that catches whether remember me was requested, but suppress it until the 2nd factor is completed.
Todo
---
* [x] Update UPGRADE and CHANGELOG
* [x] Show before/after examples
* [x] Investigate the conditional event registering of `ContextListener`. This forces to inject both the firewall and the global event dispatcher at the moment.
* Make sure old remember me tokens still function. As remember me tokens are long lived, we may need to provide backwards compatibility for at least Symfony 6.x. **Update: it was decided to not include this for now: https://github.com/symfony/symfony/pull/40145#issuecomment-785819607**
cc `@scheb` `@weaverryan` as you both initiated this PR by sharing the problems with the current design.
Commits
-------
15670419d4 [Security] Rework the remember me system
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Console] Deprecate Helper::strlen() for width() and length()
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | yes
| Deprecations? | yes
| Tickets | Follow up form #40698
| License | MIT
| Doc PR |
This PR will deprecated `Helper::strlen()` since it is actually calculating the width. I remove the `@internal` on `Helper::width()` and a `Helper::length()`. I will also deprecate `Helper::strlenWithoutDecoration()` because you should use `Helper::removeDecoration()` instead.
Commits
-------
3c24aa9d47 [Console] Deprecate Helper::strlen() for width() and length()
This PR was merged into the 5.2 branch.
Discussion
----------
[Form] Fix 'invalid_message' use in multiple ChoiceType
| 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#40636 <!-- 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
-->
`invalid_message` option were not take into account anymore since v5.2.4. This PR intends to fix this. The option `invalid_message` is now passed to the `POST_SUBMIT` callback, for multiple ChoiceType.
Commits
-------
f2516840c8 [Form] Fix 'invalid_message' use in multiple ChoiceType
This PR was merged into the 4.4 branch.
Discussion
----------
[Yaml] Fixed infinite loop when parser goes through an additional and invalid closing tag
| Q | A
| ------------- | ---
| Branch? | 4.4 and above
| 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#40706 <!-- 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 -->
Instead of letting the parser goes in an infinite loop because it can't get the right closing tag, throw an exception when the additional and invalid closing tag is found
Commits
-------
d5f8c887a2 [Yaml] Fixed infinite loop when parser goes through an additional and invalid closing tag
This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[Notifier] LightSMS duplicated $errorCode variable fix
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | Fix#40712, #40733
| License | MIT
| Doc PR | -
Removed duplicated variable $errorCode.
Many thanks for:
@OskarStark, @jderusse and special thanks for @chalasr for fast rebase course at night :)))
Commits
-------
867769ede4 [Notifier] LightSMS duplicated $errorCode variable fix
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Notifier] Added missing changelog
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
I found this to be missing
Commits
-------
41198cccb5 [Notifier] Added missing changelog
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Notifier] Fix LightSms package name
| Q | A
| ------------- | ---
| Branch? | 5.x
| 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 #", no need to create an issue if none exist, explain below instead -->
| License | MIT
| Doc PR | n/a
As the namespace is LightSms and not Lightsms.
Commits
-------
2d80665a4a [Notifier] Fix LightSms package name
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Security] Add concept of required passport badges
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | yes
| Deprecations? | n
| Tickets | Fix#39305
| License | MIT
| Doc PR | tbd
A badge on a passport is a critical security element, it determines which security checks are run during authentication. Using the `required_badges` setting, applications can make sure the expected security checks are run.
Commits
-------
01c3bf9604 [Security] Add concept of required passport badges
This PR was merged into the 4.4 branch.
Discussion
----------
[PHPDoc] Fix some union type cases
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
While working on https://github.com/symfony/symfony/issues/40154, I discovered some PHPDoc issues, I'm going to comment in the review. Upper branches will need some fixes too.
Commits
-------
dd1481642b [PHPDoc] Fix some union type cases
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Serializer] Construct annotations using named arguments
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | yes
| Tickets | N/A
| License | MIT
| Doc PR | Not needed
This is the same as #40266, but applied to the serializer annotations.
This PR proposes to bump the `doctrine/annotations` library to 1.12 to gain access to its emulation layer for named arguments. Furthermore, constructing any of the serializer's annotation classes the old way by passing an array of parameters is deprecated.
### Reasons for this change
The constructors of our annotation classes have become unnecessarily complicated because we have to support two ways of calling them:
* An array of parameters, passed as first argument, because that's the default behavior `doctrine/annotations`.
* A set of named arguments because that's how PHP 8 attributes work.
Since we can now tell the Doctrine annotation reader to use named arguments as well, we can simplify the constructors of our annotations significantly.
### Drawback
After this change, there is no easy way anymore to construct instances of most of the annotation classes directly on PHP 7. The PR has been built under the assumption that instances of this class are usually created using either Doctrine annotations or a PHP 8 attribute. Thus, most applications should be unaffected by this change.
Commits
-------
c11666264d [Serializer] Construct annotations using named arguments
This PR was merged into the 5.2 branch.
Discussion
----------
[Console] Add Helper::width() and Helper::length()
| Q | A
| ------------- | ---
| Branch? | 5.2
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Close#40697Fix#40634, fix#40635
| License | MIT
| Doc PR |
This PR will add add a Helper::strwidth() and a Helper::strlength(). Same with with the Helper::strlenWithoutDecoration(). It does not deprecate anything. That is done in #40695
With this PR we dont have to revert the emoji issue (ie close#40697)
FYI @grasmash, I used your tests from #40635
Commits
-------
d9ea4c597c Add test.
dc02ab3d74 [Console] Add Helper::strwidth() and Helper::strlength()
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Notifier] [CS] [5.x] Replace easy occurrences of ?: with ??
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
https://github.com/symfony/symfony/pull/40729 on 5.x
Commits
-------
726075c177 [CS] [5.x] Replace easy occurrences of ?: with ??
