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()
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 merged into the 5.3-dev branch.
Discussion
----------
Fixed the deprecation message about Master/Main requests
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
I saw this while running tests in an app just updated to 5.x version:
```
Remaining direct deprecation notices (61)
61x: Since symfony/http-kernel 5.3: "%s()" is deprecated, use "isMainRequest()" instead.
```
Commits
-------
65f7408c61 Fixed the deprecation message about Master/Main requests
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 merged into the 5.3-dev branch.
Discussion
----------
[Notifier] Inject Mailer instead of service locator for FakeSms and FakeChat
| Q | A
| ------------- | ---
| Branch? | 5.x
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fixes#40731
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/15206
| Recipe PR | https://github.com/symfony/recipes/pull/930
Until now the locator was not injected and therefore not working.
We decided to make the transport name configurable instead of the service_id.
[How is it working?](https://github.com/symfony/symfony/pull/40739#issuecomment-816609850)
### Todos
* [x] add tests
* [x] test in a real project
Commits
-------
0f6d5079cb [Notifier] Inject Mailer instead of service locator for FakeSms and FakeChat
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
