* 4.3: (26 commits)
[Console] Fix#33915, Detect dimensions using mode CON if vt100 is supported
[HttpKernel][DataCollectorInterface] Ease compatibility
Add tests to ensure defaultLocale is properly passed to the URL generator
[DependencyInjection] Fix broken references in tests
[HttpClient] Retry safe requests when then fail before the body arrives
Avoid using of kernel after shutdown
Simplify PHP CS Fixer configuration
[PropertyInfo] Fixed type extraction for nullable collections of non-nullable elements
[FrameworkBundle] [HttpKernel] fixed correct EOL and EOM month
[Serializer] Fix property name usage for denormalization
Name test accordingly to the tested class
Fix MockFileSessionStorageTest::sessionDir being used after it's unset
bumped Symfony version to 4.3.7
updated VERSION for 4.3.6
updated CHANGELOG for 4.3.6
bumped Symfony version to 3.4.34
updated VERSION for 3.4.33
update CONTRIBUTORS for 3.4.33
updated CHANGELOG for 3.4.33
[HttpClient] Fix perf issue when doing thousands of requests with curl
...
This PR was merged into the 4.3 branch.
Discussion
----------
[Console] Detect dimensions using mode CON if vt100 is supported
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#33915
| License | MIT
This fixes color support detection for users of Win10 + git-bash. If vt100 support is detected, the terminal will not try to use `stty` to test for dimensions. Calling such command implicitly disables vt100 support on STDOUT.
Commits
-------
fdeceff85e [Console] Fix#33915, Detect dimensions using mode CON if vt100 is supported
This PR was merged into the 4.3 branch.
Discussion
----------
[HttpClient] Retry safe requests using HTTP/1.1 when HTTP/2 fails
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
cURL support of HTTP/2 is not as robust as HTTP/1.1. When doing >1k requests, the stream can break for buggy reasons. New versions of cURL are fixed already, but let's make our logic more resilient anyway, and switch to HTTP/1.1 when a *safe* request fails for send/recv reasons.
Commits
-------
9f7cd66004 [HttpClient] Retry safe requests when then fail before the body arrives
* 3.4:
[DependencyInjection] Fix broken references in tests
Avoid using of kernel after shutdown
Simplify PHP CS Fixer configuration
[FrameworkBundle] [HttpKernel] fixed correct EOL and EOM month
Fix MockFileSessionStorageTest::sessionDir being used after it's unset
bumped Symfony version to 3.4.34
updated VERSION for 3.4.33
update CONTRIBUTORS for 3.4.33
updated CHANGELOG for 3.4.33
[Stopwatch] Fixed a bug in stopwatch event getStartTime
[Stopwatch] Fixed bug in getDuration when counting multiple ongoing periods
Adding some validations tags on validators.et.xlf
add missing translation for 94 (it)
This PR was merged into the 4.4 branch.
Discussion
----------
[VarDumper] display the method we're in when dumping stack traces
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
This PR adds the line in blue:
Without it, we're missing some context as the method is from a trait. This allows knowing which class is actually importing and using the method.
Commits
-------
23600cc8e1 [VarDumper] display the method we're in when dumping stack traces
This PR was merged into the 4.4 branch.
Discussion
----------
[ErrorRenderer] Show generic message in non-debug mode
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
I agree with @Tobion here https://github.com/symfony/symfony/pull/34158#issuecomment-548181099, so let's always show the detail message, but for 5xx errors we'll send a generic message instead.
/cc @dunglas wdyt?
Commits
-------
45f1a5ee06 Show generic message in non-debug mode
This PR was squashed before being merged into the 4.4 branch (closes#33732).
Discussion
----------
[Console] Rename some methods related to redraw frequency
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
In #26339 we added `preventRedrawFasterThan()` and `forceRedrawSlowerThan()`. While merging the docs for them (https://github.com/symfony/symfony-docs/pull/12364) I thought that the method names are a bit hard to understand.
In this PR I propose a renaming for your consideration. Thanks!
In the following example, we want to update the progress bar every 100 iterations, but not faster than 100ms or slower than 200ms.
**Before**
```php
$progressBar = new ProgressBar($output, 50000);
$progressBar->start();
$progressBar->setRedrawFrequency(100);
$progressBar->preventRedrawFasterThan(0.1);
$progressBar->forceRedrawSlowerThan(0.2);
```
**After**
```php
$progressBar = new ProgressBar($output, 50000);
$progressBar->start();
$progressBar->setRedrawFrequency(100);
$progressBar->maxRefreshInterval(0.1);
$progressBar->minRefreshInterval(0.2);
```
Commits
-------
e6ee7b07f3 [Console] Rename some methods related to redraw frequency
This PR was merged into the 4.4 branch.
Discussion
----------
[Routing][Config] Allow patterns of resources to be excluded from config loading
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #31516
| License | MIT
| Doc PR | not yet
The PR will fix the following RFC: #31516
Like resource loading for services, this PR offers a way to exclude patterns of resources like:
```yml
// config/routes/annotations.yaml
controllers:
resource: ../../src/Controller/*
type: annotation
exclude: '../src/Controller/{DebugEmailController}.php'
```
All the annotation routes inside `Controller/` will be loaded in this example except all the one present inside the `Controller/DebugEmailController.php`
Commits
-------
332ff8811c [Routing][Config] Allow patterns of resources to be excluded from config loading
This PR was merged into the 4.4 branch.
Discussion
----------
[DI] Add compiler pass and command to check that services wiring matches type declarations
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #27744
| License | MIT
| Doc PR |
PR replacing https://github.com/symfony/symfony/pull/27825.
It adds a `lint:container` command asserting the type hints used in your code are correct.
Commits
-------
8230a1543e Make it really work on real apps
4b3e9d4c96 Fix comments, improve the feature
a6292b917b [DI] Add compiler pass to check arguments type hint
This PR was merged into the 4.3 branch.
Discussion
----------
[Messenger] fix retry of messages losing the routing key and properties
| Q | A
| ------------- | ---
| Branch? | 4.3
| 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#32994 <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR |
Messages sent for retry in rabbitmq lost the routing key and properties like the priority. Now we read those original properties and sent the retry message with the same properties (unless those properties have already been set manually before).
Commits
-------
75c674debc [Messenger] fix retry of messages losing the routing key and properties
This PR was merged into the 3.4 branch.
Discussion
----------
Adding some validations tags on validators.et.xlf
| Q | A
| ------------- | ---
| Branch? | 4.4 for features / 3.4 or 4.3 for bug fixes <!-- see below -->
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/30160
| License | MIT
I saw an issue in the **Issues Page** and i want to help to improve the repository, even with a simple modification
Commits
-------
16bd71b5b1 Adding some validations tags on validators.et.xlf
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] add missing translation for 94 (it)
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | None
| License | MIT
| Doc PR | not needed
Italian translation for validator is missing last item (id 94)
Commits
-------
1dc7ce1159 add missing translation for 94 (it)
This PR was merged into the 3.4 branch.
Discussion
----------
[Stopwatch] Fixed bug in getDuration when counting multiple ongoing periods
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#34087
| License | MIT
| Doc PR | N/A
When running multiple periods in StopwatchEvent (start multiple times and not stop them all), the getDuration() method would return unexpected values.
This was because at every stop, the last entry in the `started` array was removed, while the `getDuration` method was still expecting all the started events to still be there.
Now, when calling `getDuration`, the duration of all the finished periods are added together with the unfinished counts.
Commits
-------
af00d8deab [Stopwatch] Fixed bug in getDuration when counting multiple ongoing periods
This PR was squashed before being merged into the 4.3 branch (closes#34165).
Discussion
----------
[PropertyInfo] Fixed type extraction for nullable collections of non-nullable elements
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
When an annotation is declared as `int[]|null`, it is handled like `(int|null)[]|null`. So array values are also nullable.
Now this behavior is fixed that `int[]|null` is either a collection of integers only or null.
How to reproduce:
```php
class Dummy
{
/** @var int[]|null */
public $nullableCollectionOfNonNullableElements;
}
/** @var Type[] $types */
$types = (new PhpDocExtractor())->getTypes(Dummy::class, 'nullableCollectionOfNonNullableElements');
$collectionType = $types[0];
assert($collectionType->isCollection() === true); // OK
assert($collectionType->isNullable() === true); // OK
assert($collectionType->getCollectionValueType()->getBuiltinType() === Type::BUILTIN_TYPE_INT); // OK
assert($collectionType->getCollectionValueType()->isNullable() === false); // FAILED
```
Commits
-------
5e394c40f0 [PropertyInfo] Fixed type extraction for nullable collections of non-nullable elements
This PR was merged into the 3.4 branch.
Discussion
----------
[Stopwatch] Fixed a bug in StopwatchEvent::getStartTime
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#34088
| License | MIT
| Doc PR | N/A
When using a `StopwatchEvent` with an `$origin` that's smaller than the first start time, calling `getStartTime()` before ending the event will give `0` instead of the correct number.
The proposed fix in #34088 fixes this.
Commits
-------
b2b7eab949 [Stopwatch] Fixed a bug in stopwatch event getStartTime
* Added a hardcoded day 01 in order to output the proper month November
which is the correct EOL and EOM month.
* \DateTime::createFromFormat('mY') will output December for every month
where day 31 exists.
This PR was merged into the 4.4 branch.
Discussion
----------
Add new Form WeekType
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #32029
| License | MIT
| Doc PR | <!--symfony/symfony-docs#...--> coming soon
----
#### Update
After the first try, I've updated the field to have more options, and be more "straight".
The field acts like the `DateTimeType` or `TimeType`, various fields type (pure text, html5 type, select boxes), data validation, ....
For that I took the choice to update the `DateTimeToStringTransformer` and `DateTimeToArrayTransformer` to make them work with weeks format.
I was not sure if it was better to update them or create new ones, WDYT?
Before addind tests and docs, it would be nice to have your first thoughts/comments 😊
Do you need/want a small test repo?
Commits
-------
c4a2f026e0 Add new Form WeekType
This PR was merged into the 4.4 branch.
Discussion
----------
[DI] Add ability to choose behavior of decorations on non existent decorated services
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | #33522
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/12442
# Handling decorations on non existent decorated services
Handle decorations on non existent decorated services by either throwing the service not found exception, silently ignoring services (decorator & decorated) all together or leave the decorated service to null (current behavior)
Something almost similar to how missing services as parameters are handles.
## Yaml configuration
```yaml
decorator:
decorates: decorated
decoration_on_invalid: ignore
```
Available values: `exception`, `ignore`, `null`. `exception` if nothing is specified.
## Xml configuration
```xml
<service id="decorator" decorates="decorated" decoration-on-invalid="ignore" />
```
Available values: `exception`, `ignore`, `null`. `exception` if nothing is specified.
## Behavior
- `exception`: Throws a `ServiceNotFoundException` telling that the decorator's dependency is missing
- `ignore`: Remove decorator definition. Decorator and decorated will not be available at all.
- `null`: Keep decorator but set decorated to null. Therefore, decorator `__construct` should be written with a nullable decorated dependency (`public function __contruct(?DecoratedInterface $decorated) {}`) and check should be done in other methods
Commits
-------
f167c77eaf Handle non existent decorated services
This PR was squashed before being merged into the 4.3 branch (closes#34035).
Discussion
----------
[Serializer] Fix property name usage for denormalization
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Using the `@SerializedName()` and passing it an existing property name affects the deserialization even if `@Groups()` are not supposed to be involved.
## How to reproduce
Given the following class
```php
class Foo
{
/**
* @Group("list")
*/
private $bar;
public function setBar($bar)
{
$this->bar = $bar;
}
public function getBar()
{
return $this->bar;
}
/**
* @Groups({"list:export"})
* @SerializedName("bar")
*/
public function getBarForExport()
{
return $this->bar.' Rocks';
}
}
```
This allow us to change the content of the property based on the normalization context.
```php
$obj = new Foo();
$obj->setBar('Api Platform');
$data = $normalizer->normalize($obj, null, ['groups' => ["list"]]);
// $data => ['bar' => 'Api Platform'] as expected
$data = $normalizer->normalize($obj, null, ['groups' => ["list:export"]]);
// $data => ['bar' => 'Api Platform Rocks'] as expected
$obj = $normalizer->denormalize(['bar' => 'Api Platform'], Foo::class, null, ['groups' => ['list']]);
// $obj->getBar() would return null instead of 'Api Platform' as expected.
```
Commits
-------
8ca4a3f345 [Serializer] Fix property name usage for denormalization
This PR was squashed before being merged into the 4.4 branch (closes#34155).
Discussion
----------
Revert SyncTransport simplification and fix properly
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#34115 (and also related to #34066)
| License | MIT
| Doc PR | Not needed
In #34069, I made `SyncTransport` simpler by removing that transport class and making the whole things a config trick. I felt GREAT about that solution... until i realized two big problems:
1) It kills using env vars for `sync://` because we read the config values at build time - #34115 - that could probably be fixed by adding a factory, but then there is also the next problem
2) If someone routed a message to `[async, sync]` (weird, but allowed), my #34069 config solution basically maps this internally to `[async]`, which actually causes the message to *not* be handled immediately. Basically, my solution only worked if you route a message ONLY to one sync transport, but fails if you route to multiple transports.
So... this fixes things in a less-cool, but sensible way:
A) The first commit reverts #34069 exactly
B) The second commit solves the issue that we need to know if a message is being handled in a "worker" context or not, so middleware can decide if they should reset things before/after handling things. Previously we were using `ReceivedStamp` to know this. But because `SyncTransport` also "receives" the message and adds this stamp, it's not enough. To fix this, I added a new `ConsumedByWorkerStamp` that clearly means: "This message is being handled by a worker" (and so, you might want to "reset" some things before/after handling).
Thanks!
Commits
-------
01a9fefe77 Adding ConsumedByWorkerStamp as way to mark a message in a "worker context"
38f19a960c Revert "[Messenger] Removing "sync" transport and replacing it with much nicer config trick"
