This PR was merged into the 5.1 branch.
Discussion
----------
[FrameworkBundle] Remove unused form-resources complex type from XSD file
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Unused since d5be373cac (diff-e7427ecf018e4434c1645712ebe715f6L165).
Commits
-------
8bec34dd22 [FrameworkBundle] Remove unused form-resources complex type from XSD file
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Console] Rework the signal integration
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | refs https://github.com/symfony/symfony/pull/33729
| License | MIT
| Doc PR |
I updated the code to have a better design and DX:
* `SignalRegistry::$handlingSignals` is gone. This was a temporary data store to
bind signal to symfony event. This does not belong to the `SignalRegistry`. It
has been replaced by `Application::$signalsToDispatchEvent`. A method has been
added to edit this list `Application::setSignalsToDispatchEvent()`
* The default value for `Application::$signalsToDispatchEvent` is `SIGINT,
SIGTERM, SIGUSR1, SIGUSR2`. Theses defaults seems good enough for most of
application. for recall:
* `SIGINT`: CTRL+C
* `SIGTERM`: `kill PID`, this is what occurs when stopping a process with SystemD, upstart & co
* `SIGUSR1` and `SIGUSR2`: Signal for user space
* `Application::setSignalRegistry()` is gone. Now the Application always owns a
signal registry. Since it's a CLI, it's legit to always have support for
signals. A method has been added for convenience, and to register signal
handler manually from the command:
```php
$application->getSignalRegistry()->register(SIGINT, function ($signal) {
dump("Signal ($signal) caught");
});
```
* The interface `SignalableCommandInterface` has been added. When a command
implements this interface, the command is automatically called when a
registered signal has been caught
A note about the BC:
* If one register an handler before the Symfony ones, the Signal Registry keeps
existing registered handlers. The BC is kept ✅
* If one register an handler after the Symfony ones, it overrides the Symfony
behavior. Since the feature is new. the BC is kept ✅
---
So now, If one want to listen a signal, they have few options depending on the context:
* A global action is common to all commands (such as logging, enabling a
profiler (👋 blackfire.io)): Use a listener. With autoconfigure, the following
code is enough:
```php
class SignalSubscriber implements EventSubscriberInterface
{
private $logger;
public function __construct(LoggerInterface $logger = null)
{
$this->logger = $logger ?: new NullLogger();
}
public function handleSignal(ConsoleSignalEvent $event)
{
$signal = $event->getHandlingSignal();
$this->logger->debug('The application has been signaled', [
'signal' => $signal,
]);
}
public static function getSubscribedEvents()
{
return [
ConsoleEvents::SIGNAL => 'handleSignal',
];
}
}
```
* The command should react to a signal: Implements the interface:
```php
class SignalCommand extends Command implements SignalableCommandInterface
{
protected static $defaultName = 'signal';
private $shouldStop = false;
protected function execute(InputInterface $input, OutputInterface $output): int
{
$output->writeln('hello, I am '. getmypid());
for ($i=0; $i < 60; $i++) {
if ($this->shouldStop) {
break;
}
$output->write('.');
sleep(1);
}
$output->writeln('');
$output->writeln('bye');
return 0;
}
public function handleSignal(int $signal)
{
dump([__METHOD__, $signal]);
$this->shouldStop = true;
}
public function getSubscribedSignals(): array
{
return [SIGINT];
}
}
```
* The command should react differently to many event and/or one wants a full control on name of the method called
```php
class SignalCommand extends Command
{
protected static $defaultName = 'signal';
private $shouldStop = false;
protected function execute(InputInterface $input, OutputInterface $output): int
{
$this->getApplication()->getSignalRegistry()->register(SIGINT, [$this, 'stop']);
$this->getApplication()->getSignalRegistry()->register(SIGUSR1, [$this, 'enableBlackfire']);
$output->writeln('hello, I am '. getmypid());
for ($i=0; $i < 60; $i++) {
if ($this->shouldStop) {
break;
}
$output->write('.');
sleep(1);
}
$output->writeln('');
$output->writeln('bye');
return 0;
}
public function stop()
{
$this->shouldStop = true;
}
public function enableBlackfire()
{
// ...
}
}
```
ping @marie
Commits
-------
df57119884 [Console] Rework the signal integration
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Messenger] Don't require doctrine/persistence when installing symfony/messenger
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix#36790 <!-- 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 of today, [installing `symfony/messenger` installs `symfony/doctrine-messenger`](3867fb2489/src/Symfony/Component/Messenger/composer.json (L23)) as well. Which means adding `doctrine/persistence` as a hard dep of the latest will install it for any user requiring `symfony/messenger` in 5.2.
I think it should stay a soft-dependency until we remove `symfony/doctrine-messenger` as a `symfony/messenger` dependency as of Symfony 6.0 (as mentioned in #35422).
---
related: #36785
Commits
-------
5c05455521 [Messenger] Don't require doctrine/persistence when installing symfony/messenger
This PR was merged into the 3.4 branch.
Discussion
----------
use expectWarning() when possible
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Commits
-------
26dd39eb06 use expectWarning() when possible
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Mailer] Add a transport that uses php.ini settings for configuration
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
This PR aims to allow to use the mailer when sendmail is not on the `/usr/sbin` directory or when the `-bs` option is not supported.
Commits
-------
04de561f63 [Mailer] Add NativeTransportFactory
* 5.1:
Postpone BC layer removal to 6.0.
add validator translation 99 for Italian language
stop using the deprecated at() PHPUnit matcher
Fix typehint phpdoc
This PR was merged into the 3.4 branch.
Discussion
----------
stop using the deprecated at() PHPUnit matcher
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | Fix#37780
| License | MIT
| Doc PR |
Commits
-------
850389731c stop using the deprecated at() PHPUnit matcher
This PR was merged into the 5.1 branch.
Discussion
----------
Postpone Range BC layer removal to 6.0.
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
This BC layer triggers a deprecation message when using `minMessage`/`maxMessage` and `min` and `max` are both set.
Since users on 5.0 and 5.1 hasn't have the deprecation, removing the BC layer (and so throwing an exception) in 5.x would be a big BC break.
Also updated trigger_error to trigger_deprecation and `@deprecationMessage` to `ExpectDeprecationTrait::expectDeprecation`.
Commits
-------
1f66618bb1 Postpone BC layer removal to 6.0.
This PR was merged into the 5.2-dev branch.
Discussion
----------
Add cache.adapter.redis_tag_aware to use RedisCacheAwareAdapter
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | https://github.com/orgs/symfony/projects/1#card-33761315
| License | MIT
| Doc PR |
Commits
-------
68d16384d4 Add cache.adapter.redis_tag_aware to use RedisCacheAwareAdapter
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Workflow] Improve and fix
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | Fix https://github.com/symfony/symfony/pull/37815 review
| License | MIT
| Doc PR | #
Hi @lyrixx
thx for such fast PR take over :)
while reviewing i found this typo i think
also i reordered the constants inside the events class to map with the order of fireing event
Commits
-------
9bbce417ff [Workflow] Improve and fix
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Messenger] Add Beanstalkd bridge
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
On a project at work we use Beanstalkd and we wanted to start using Messenger with it so I've written this bridge/transport. Any feedback is highly appreciated.
Commits
-------
8e6d0df3ec Add Beanstalkd Messenger bridge
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[VarDumper] Add VAR_DUMPER_FORMAT=server format
| Q | A
| ------------- | ---
| Branch? | master<!-- see below -->
| Bug fix? | no
| New feature? | yes<!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | Fix#35801 <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | TODO <!-- required for new features -->
This PR follows discussion in #35801 and adds support for a `server` value for the existing `VAR_DUMPER_FORMAT` env var.
It comes as well with two more things:
- ~~the handler is registered as soon as the `VAR_DUMPER_FORMAT` env var is detected~~ we prevent registering another handler as soon as the `VAR_DUMPER_FORMAT` env var is set, instead of checking if there was a previous handler (which could make this env var useless in some conditions where the handler was already set by another "process")
- the handler registered this way cannot be replaced. This prevents another "process" to takeover dump handling while undesired. E.g: a phpunit functional test booting the kernel to call an endpoint => the handler is replaced. It's (in a sense) a satisfying alternative to #26696
This PR means anyone can use dump with a server in any context, without changing a single line of code in the project by:
- starting the server using `./vendor/bin/var-dump-server --format=html > dumps.html`
- using the env var: `VAR_DUMPER_FORMAT=server [your-cli-command]`
---
Previous related PRs:
- https://github.com/symfony/symfony/pull/26695
- https://github.com/symfony/symfony/pull/26696
Commits
-------
82df6dbcda [VarDumper] Add VAR_DUMPER_FORMAT=server format
This PR was merged into the 3.4 branch.
Discussion
----------
add validator translation 99 for Italian language
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | none
| License | MIT
| Doc PR | not needed
This is a followup to PR #37730 for Italian language.
Commits
-------
ad4923f706 add validator translation 99 for Italian language
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Workflow] Choose which Workflow events should be dispatched
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#36633 ; Fix#36617
| License | MIT
| Doc PR |
Commits
-------
cfc53ad732 [Workflow] Choose which Workflow events should be dispatched (fix previous commit)
d70074753c [Workflow] Choose which Workflow events should be dispatched
* 5.1:
[Validator] RangeTest: fix expected deprecation
Fix bad merge
[Yaml] Fix for #36624; Allow PHP constant as first key in block
Use PHPUnit 9.3 on php 8.
fix mapping errors from unmapped forms
[Validator] Add target guards for Composite nested constraints
* 4.4:
[Validator] RangeTest: fix expected deprecation
[Yaml] Fix for #36624; Allow PHP constant as first key in block
Use PHPUnit 9.3 on php 8.
fix mapping errors from unmapped forms
[Validator] Add target guards for Composite nested constraints
* 3.4:
[Yaml] Fix for #36624; Allow PHP constant as first key in block
Use PHPUnit 9.3 on php 8.
fix mapping errors from unmapped forms
[Validator] Add target guards for Composite nested constraints
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Console] Different approach on merging application definition
| Q | A |
| --- | --- |
| Branch? | "master" |
| Bug fix? | yes |
| New feature? | not really (refactoring) |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | #19181, #17804, #19909, partially #20030 |
| License | MIT |
| Doc PR | reference to the documentation PR, if any |
Before/After:
``` diff
$ bin/console list -h
Usage:
list [options] [--] [<namespace>]
Arguments:
namespace The namespace name
Options:
--raw To output raw command list
--format=FORMAT The output format (txt, xml, json, or md) [default: "txt"]
+ -h, --help Display this help message
+ -q, --quiet Do not output any message
+ -V, --version Display this application version
+ --ansi Force ANSI output
+ --no-ansi Disable ANSI output
+ -n, --no-interaction Do not ask any interactive question
+ -e, --env=ENV The environment name [default: "dev"]
+ --no-debug Switches off debug mode
+ -v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
Help:
The list command lists all commands:
php bin/console list
You can also display the commands for a specific namespace:
php bin/console list test
You can also output the information in other formats by using the --format option:
php bin/console list --format=xml
It's also possible to get raw list of commands (useful for embedding command runner):
php bin/console list --raw
```
This could deprecate `getNativeDefinition` or make it a feature as right now it's internal and unused.
edit: resolved the BC break.
edit2: question is.. should this target 2.7?
Commits
-------
553b173a30 [Console] Different approach on merging application definition
This PR was merged into the 5.2-dev branch.
Discussion
----------
[Notifier] Add Mobyt bridge
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | #33687
| License | MIT
| Doc PR | symfony/symfony-docs#13606
| recipe PR | symfony/recipes#768
Add Mobyt notifier bridge.
In this SMS Provider, you can choose a sort of "quality service" to send the message.
I updated `src/Symfony/Component/Notifier/Message/SmsMessage.php` to add the notification in order to be able to use the notification importance when creating options.
Commits
-------
bf594b75d0 Add Mobyt Notifier bridge
This PR was merged into the 5.2-dev branch.
Discussion
----------
[FrameworkBundle] Allow to leverage autoconfiguration for DataCollectors with template
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
When creating a datacollector with a template for the profiler display, an id must be set in the `data_collector` tag and must be the same as this returned by `DataCollectorInterface::getName`. A template path can also be added to the tag. We lose in this case the ability to use autoconfigure. This PR suggests:
- To guess the id configured in the `data_collector` tag. To follow the principle already used for services ids or events names, if not specified, the id is the data collector class name.
- To allow data collectors to provide the template path from the code. Note that the template path configuration via the `data_collector` tags still takes precedence over configuration from the code.
This PR also provides an `AbstractDataCollector` to avoid to implement methods that might be considered as boilerplate: `reset` and `getName`.
Commits
-------
986a0a221e [FrameworkBundle] Allow to leverage autoconfiguration for DataCollectors with template
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[Security] Add event to inspect authenticated token before it becomes effective
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| License | MIT
| Doc PR | n/a
Hello there, I'm the author of `scheb/two-factor-bundle`, which extends Symfony's security layer with two-factor authentication. I've been closely following the recent changes by @wouterj to rework the security layer with "authenticators" (great work!). While I managed to make my bundle work with authenticators, I see some limitations in the security layer that I'd like to address to make such extensions easier to implement.
This PR adds a new event, which is disapatched right after the authenticated token has been created by the authenticator, to "announce" it to the application *before* it becomes effective to the security system. The event works similar to `ResponseEvent`, but for security token. It allows listeners to inspect the new token before it becomes effective and - most importantly - apply modifications to it. So components other than the authenticator will be able to influence how the security token looks like, that will be set to the security layer on successful authentication.
Why would you want to do this? Of course I'm looking at this from the 2fa perspective. To make 2fa work, it's necessary to prevent a newly created authenticated token from becoming visible to the security system and therefore exposing its privileges/roles. This is done by replacing the authenticated token with a temporary "TwoFactorToken". Currently I'm doing this through dependency injection, getting all the registered authenticators and decorating them with my own token-exchange logic. This is not very clean and overly complicated, but it works. Adding this event as a hook-in point would allow for a much cleaner integration for any component that wants to have a saying in how the security token should look like.
Commits
-------
20309646b7 [Security] Add event to inspect authenticated token before it becomes effective