* 5.1:
Fix CS
[Serializer] Fix configuration of the cache key
[Messenger] Do not stack retry stamp
[FrameworkBundle] Add missing mailer transports in xsd
[Lock] MongoDbStore skim non-standard options from uri
[ErrorHandler][DebugClassLoader] Add mixed and static return types support
* 4.4:
Fix CS
[Serializer] Fix configuration of the cache key
[Messenger] Do not stack retry stamp
[FrameworkBundle] Add missing mailer transports in xsd
[ErrorHandler][DebugClassLoader] Add mixed and static return types support
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Serializer] Fix configuration of the cache key
| 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#35574doctrine/orm#8030 (partially)
| License | MIT
| Doc PR | n/a
Currently, a bug prevents to configure the context keys to exclude from the cache key computation. The value is always replaced in the constructor. This PR fixes the problem.
Commits
-------
3b034cb343 [Serializer] Fix configuration of the cache key
This PR was squashed before being merged into the 4.4 branch.
Discussion
----------
[Messenger] Do not stack retry stamp
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | /
| License | MIT
| Doc PR | /
With the "RecoverableException" or a very high number of retry, the message is currently stacking a lot of stamp, which increase the size of the message sent to queue and (in my case) reach the "maximum size allowed" after 60 retries + php serializer
This PR removes previous stamps before adding the new Delay+RetryStamps.
Commits
-------
ad6f8532c6 [Messenger] Do not stack retry stamp
This PR was squashed before being merged into the 5.1 branch.
Discussion
----------
[Lock] MongoDbStore skim non-standard options from uri
| Q | A
| ------------- | ---
| Branch? | 5.1
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#37180
| License | MIT
| Doc PR |
Don't allow non-standard connection uri options reach `MongoDB\Client`
Commits
-------
67912faf9f [Lock] MongoDbStore skim non-standard options from uri
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[Console] added TableCellStyle
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | Fix#13370
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
Added an opportunity to customize a table cell via TableCellStyle object.
It can be used as
```php
new TableCell(
'content',
[
'style' => new TableCellStyle([
'align' => 'center',
'fg' => 'red',
'bg' => 'green',
// or
'cellFormat' => '<info>%s</info>',
])
]
)
```
See #13370
Commits
-------
aff7628d7d [Console] added TableCellStyle
* 5.1:
[Serializer] Fix variadic support when using type hints
[VarDumper] Backport handler lock when using VAR_DUMPER_FORMAT
[FrameworkBundle] Remove unused form-resources complex type from XSD file
Added missing router config
This PR was merged into the 3.4 branch.
Discussion
----------
[Serializer] Fix variadic support when using type hints
| Q | A
| ------------- | ---
| Branch? | 3.4 <!-- 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 | 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
Commits
-------
3fffa96928 [Serializer] Fix variadic support when using type hints
This PR was merged into the 5.2-dev branch.
Discussion
----------
[VarDumper] Support PHPUnit --colors option
| 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 | 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
Commits
-------
ac0a3fc38a [VarDumper] Support PHPUnit --colors option
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[Notifier][Slack] Use Slack Web API chat.postMessage instead of WebHooks
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
**TL;DR**: Revert changes introduced in 5.1 by #35828: Slack's Web API is much more flexible and easier to operate than Slack WebHooks are.
---
### Context
A valid choice was made to switch from Slack's Web API to Slack's WebHooks for a wrong reason: according to #35828, this was in reaction to the deprecation of Slack's Legacy Tokens.
The author cites:
> Legacy tokens are a deprecated method of generating tokens for testing and development.
[As far as I was able to understand](https://github.com/symfony/symfony/pull/35828#issuecomment-639465018
), from the author perspective, this deprecation was amalgamated with the (perceived) deprecation of the Web API itself.
According to [Slack documentation](https://api.slack.com/legacy/custom-integrations/legacy-tokens) cited by the author:
> If you were using a legacy token to make calls with the Web API, you'll need to generate a new one for your new Slack app.
**So Slack changing its credentials' policy didn't warrant changing how to use Slack's Web API.**
---
### Why Web API > WebHook?
While using Slack WebHooks as the underlying transport method for notification isn't inherently a bad choice, it does–on top of [the reasons cited by the author](#35828)–come with a major limitation: the need to setup (manually or programmatically) a Webhook per channel/recipient.
The Web API, with it's underlying OAuth Access Token, is much more flexible and allows for more diverse use case. Notifications can be sent on behalf of users for instance. Slack can also limit the use of the access tokens to a list of IP addresses and ranges.
**E.g. I want to notify the person who triggers a CD pipeline if the latter fails.** \
Assuming a team of 10 developer, using Slack WebHooks, I would need to setup 10 WebHooks, and manages as many secret in my Symfony app. Furthermore, I would need to create new WebHook each time a new member were to join the team. \
With the Web API, I would only need to manage a single access token for the whole Slack workspace, regardless of who as access to this workspace.
Slack's Web API is much more flexible and easier to operate than Slack WebHooks are.
Commits
-------
bb614c2159 [Notifier][Slack] Use Slack Web API chat.postMessage instead of WebHooks
This PR was squashed before being merged into the 5.2-dev branch.
Discussion
----------
[Security] Add missing NullToken vote
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
While playing with 5.2-dev, I discovered I forgot to add a granted vote for `PUBLIC_ACCESS`.
I also think it makes more sense now to move the constant from `AccessListener` to `AuthenticatedVoter` (to not have a dependency on Http constants in a Core voter). This is however a BC break, should we do anything more to facility our early-adapters?
Commits
-------
f17746c7c0 [Security] Add missing NullToken vote
This PR was merged into the 5.2-dev branch.
Discussion
----------
[VarDumper] Fix exception about abstract_arg
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Related to #37237
Some empty args have been replaced by abstract args (server host, populated by `dump_destination` configuration value). But when `dump_destination` is not set (in test env for instance) or doesn't start by `tcp://`, `var_dumper.dump_server` and `var_dumper.server_connection` server host arg is not injected and an exception is thrown due to the abstract arg.
This PR remove these abstract args.
Commits
-------
943fd631e3 [VarDumper] Fix exception about abstract_arg
This PR was merged into the 4.4 branch.
Discussion
----------
[VarDumper] Backport handler lock when using VAR_DUMPER_FORMAT
| Q | A
| ------------- | ---
| Branch? | 4.4 <!-- 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 | 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
Backport of the "lock" behavior from #35967, preventing unexpected handler change when using the `VAR_DUMPER_FORMAT` env var.
---
As a concrete example of this not working as expected:
Start a PHPUnit test suite with this env var to the desired format. If a web test case is making a request (with debug enabled), the `DebugBundle` replaces the handler set initially by the `VAR_DUMPER_FORMAT`, will collect dumps into the profiler, but won't output these.
As well, for dumps made in between the the kernel is boot (`DebugBundle::build()` is called) and a request, the dumps are properly sent to the output with expected format, but looses colors.
IMHO, the use-cases of `VAR_DUMPER_FORMAT` justifies locking the handler for the whole process.
Commits
-------
19b341e2b2 [VarDumper] Backport handler lock when using VAR_DUMPER_FORMAT
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.
