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.
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
