This PR was squashed before being merged into the 5.3-dev branch.
Discussion
----------
[FrameworkBundle] Add missing notifier transport factories to framework extension
| 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 -->
Tests on https://github.com/symfony/symfony/pull/39353 were failing (https://travis-ci.com/github/symfony/symfony/jobs/499236540) because of missing entries in the `$classToServices` array. They are now added and the list is ordered alphabetically.
Missing entries:
- LightSmsTransportFactory
- SmsBiurasTransportFactory
- MessageBirdTransport
Commits
-------
a83c9fe79a [FrameworkBundle] Add missing notifier transport factories to framework extension
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
This PR was submitted for the 5.x branch but it was squashed and merged into the 4.4 branch instead.
Discussion
----------
[Console] added phpdocs to InputOption constants
| Q | A
| ------------- | ---
| Branch? | 5.x for features / 4.4 or 5.2 for bug fixes <!-- 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 | 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 <!-- required for new features -->
This PR adds phpdocs to the `InputOption` constants. The docs itself were copied over from the docs on https://symfony.com/doc/current/console/input.html#using-command-options.
Over and over again people (including myself) confuse the different available constants.
having the meaning carried with the implementation should help to use the one which actually fits the use-case.
<!--
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
-------
9f124f6278 [Console] : added phpdocs to InputOption constants
* 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"
This PR was merged into the 5.3-dev branch.
Discussion
----------
[Notifier] Microsoft Teams: JSON structure error fix for simple message
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'.
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix
| License | MIT
Commits
-------
636dfc6b18 [Notifier] Microsoft Teams: JSON structure error fix for simple message
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 4.4 branch.
Discussion
----------
[FrameworkBundle] Fix missing class in messenger service locator definitions
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Should make travis green once merged up to 5.x.
Commits
-------
615bcaef08 [FrameworkBundle] Fix messenger.receiver_locator service definition
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
Fix CS in IsbnValidator and IssnValidator
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Commits
-------
dc90c195e3 Fix CS in IsbnValidator and IssnValidator
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 squashed before being merged into the 5.3-dev branch.
Discussion
----------
[FrameworkBundle] Add argument KernelInterface to BuildDebugContainerTrait::getContainerBuilder()
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
This comes from a suggestion by `@yceruto` https://github.com/symfony/symfony/pull/40804#discussion_r612746851
This change will make the trait usable outside the `Command` namespace. I did not find a better namespace to move the trait to though.. This patch will help #40804
The trait is internal so the change is okey.
Commits
-------
0e9652a4bc [FrameworkBundle] Add argument KernelInterface to BuildDebugContainerTrait::getContainerBuilder()
