This PR was merged into the 4.2-dev branch.
Discussion
----------
[OptionsResolver] Fixed explicitly ignores a depreciation
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/28860#issuecomment-432560319
| License | MIT
| Doc PR | -
When a deprecated option with default value was resolved (the first time it's called) in this case through a lazy evaluation, [the default resolution process](8398947c9c/src/Symfony/Component/OptionsResolver/OptionsResolver.php (L771-L773)) takes the resolved value and here should also trigger only if the option was provided by the user or is being called from a lazy evaluation, otherwise ignore.
Commits
-------
8398947c9c Fixed explicitly ignores a depreciation
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Process] pass all output to the wait-until callback
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | yes
| New feature? |
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Introduced yesterday, my bad.
Should make appveyor green hopefully.
Commits
-------
a320133b1d [Process] pass all output to the wait-until callback
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Validator] catch any UnexpectedValueException on validation
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #12312
| License | MIT
| Doc PR |
Commits
-------
fa3586029f catch any UnexpectedValueException on validation
This PR was merged into the 4.1 branch.
Discussion
----------
also clean away the NO_AUTO_CACHE_CONTROL_HEADER if we have no session
| Q | A
| ------------- | ---
| Branch? | 4.1 (feature added in this branch)
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This header is not supposed to ever be exposed to clients of the application, but a hack to transfer information within the symfony application. This bugfix makes it so that we also remove the header when no session is started and thus no decision has to be taken whether to overwrite the caching instructions or not.
Commits
-------
28d9f0c84c also clean away the NO_AUTO_CACHE_CONTROL_HEADER if we have no session
This PR was squashed before being merged into the 4.2-dev branch (closes#28875).
Discussion
----------
[FWBundle] Add a new method AbstractController::addLink()
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? |no
| New feature? | yes <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | n/a <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | todo
This provides a convenient method to add `Link` headers to the current `Response` directly from the `Request` object.
It improves the developer experience and the discoverability of [the WebLink component](https://github.com/symfony/symfony-docs/pull/10309).
Usage:
```php
namespace App\Controller;
use Fig\Link\Link;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
class MyAction extends AbstractController
{
public function __invoke(Request $request): Response
{
$this->addLink($request, new Link('mercure', 'https://demo.mercure.rocks'));
return $this->json(['foo' => 'bar']);
}
}
```
Commits
-------
4d20c39f70 [FWBundle] Add a new method AbstractController::addLink()
This PR was merged into the 4.2-dev branch.
Discussion
----------
[OptionsResolver] Trigger deprecation only if the option is used
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #28848
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/10496
It's true that showing a deprecation message when the option is not used is a bit annoying and it would be heavy to get rid of it.
Now, a deprecated option is triggered only when it's provided by the user or each time is being called from a lazy evaluation (except for deprecations based on the value, they're triggered only when provided by the user).
Commits
-------
1af23c9a74 [OptionsResolver] Trigger deprecation only if the option is used
This PR was squashed before being merged into the 4.2-dev branch (closes#28939).
Discussion
----------
[WebProfilerBundle] Remove application name
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
This fixes a regression in master, i think after #28809 (or something related)
There's still a "application name" concept out there today, and it's `ConfigDataCollector::getApplicationName()` 🤔
In my case the service resolved to
```php
$e = new \Symfony\Component\HttpKernel\DataCollector\ConfigDataCollector(\basename('/app'));
```
Causing the app name to be, well, `app` (again :P). It was really confusing.
Before:
![image](https://user-images.githubusercontent.com/1047696/47264761-fcb01980-d51c-11e8-9a3b-14a43d18b179.png)
(the "a" is from "app" here)
After:
![image](https://user-images.githubusercontent.com/1047696/47264767-16516100-d51d-11e8-8a5d-4c20d4911861.png)
or
![image](https://user-images.githubusercontent.com/1047696/47264774-28cb9a80-d51d-11e8-8fe6-de0f46b06a1d.png)
I think we need to deprecate the argument for real?
cc @fabpot
Commits
-------
f5c355e1ba [WebProfilerBundle] Remove application name
This PR was squashed before being merged into the 4.2-dev branch (closes#28940).
Discussion
----------
[Process] Adds usleep(1000) to ease CPU usage.
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR | symfony/symfony-docs
Commits
-------
9d1416ad82 [Process] Adds usleep(1000) to ease CPU usage.
This PR was squashed before being merged into the 4.2-dev branch (closes#28737).
Discussion
----------
[DependencyInjection] Optimize exporting variables
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #28292
| License | MIT
Store previously resolved variables so that the relatively expensive function [resolveEnvPlaceholders](3e7b029524/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php (L1776)) is not called unnecessarily.
The effect on running ```bin/console``` with an empty cache in a big application (200+ env variables) in seconds:
| Before | After |
|------------|------------|
| 24.1 | 15.8 |
| 24.5 | 16.0 |
| 24.7 | 16.3 |
| 24.2 | 16.0 |
| Avg: 24.4 | Avg:16.0 |
Commits
-------
768de2f7d9 [DependencyInjection] Optimize exporting variables
This PR was squashed before being merged into the 4.2-dev branch (closes#28200).
Discussion
----------
[Config] Fix slow service discovery for large excluded directories
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets | #26736
| License | MIT
| Doc PR |
Not sure if this is a bug fix or not, is more an improvement.
Please for all detail follow the conversation here:
https://github.com/symfony/symfony/issues/26736
Commits
-------
fa731e53e9 [Config] Fix slow service discovery for large excluded directories
This PR was squashed before being merged into the 4.2-dev branch (closes#28709).
Discussion
----------
[Serializer] Refactor and uniformize the config by introducing a default context
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | n/a <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | todo <!-- required for new features -->
This PR uniformizes how the Serializer's configuration is handled:
* As currently, configuration options can be set using the context (options that weren't configurable using the context have been refactored to leverage it)
* Normalizers and encoders' constructors now accept a "default context"
* All existing global configuration flags (constructor parameters) have been deprecated in favor of this new default context
* the stateless context is always tried first, then is the default context
Some examples:
```php
// Configuring groups globally
// Before: not possible
// After
$normalizer = new ObjectNormalizer(/* deps */, ['groups' => 'the_default_group']);
// Escaping Excel-like formulas in CSV files
// Before
$encoder = new CsvEncoder(',', '"', '\\', '.', true);
// After
$encoder = new CsvEncoder(['csv_escape_formulas' => true]);
$encoder->normalize($data, 'csv', ['csv_escape_formulas' => false]); // Override for this call only
```
Benefits:
* The DX is dramatically improved, configuration is always handled in similar way
* The serializer can be used in fully stateless way
* Every options can be configured globally
* Classes that had constructors with a lot of parameters (like `CsvEncoder`) are now much easier to use
* We'll be able to improve the documentation by adding a dictionary of all available context options for the whole component
* Everything can be configured the same way
TODO in subsequent PRs:
* Add a new option in framework bundle to configure the context globally
* Uniformize the constants name (sometimes the name if `FOO`, sometimes `FOO_KEY`)
* Fix the "bug" regarding the format configuration in `DateTimeNormalizer::denormalize()` (see comments)
* Maybe: move `$defaultContext` as the first parameter (before required services?)
* Make `XmlEncoder` stateless
Commits
-------
52b186a210 [Serializer] Refactor and uniformize the config by introducing a default context
This PR was merged into the 4.2-dev branch.
Discussion
----------
[HttpFoundation] Merging arrays in a loop is slow and causes high CPU usage
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
As described here, https://github.com/kalessil/phpinspectionsea/blob/master/docs/performance.md#slow-array-function-used-in-loop, merging arrays in a loop is slow and causes high CPU usage (benchmarks are also on the link), this pull request solves this problem
Commits
-------
3db84789f2 Merging arrays in a loop is slow and causes high CPU usage
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Messenger] internal cleanups
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | no
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
From the updated changelog:
* `MessengerDataCollector::getMessages()` returns an iterable, not just an array anymore
* `AbstractHandlerLocator` is now internal
* `HandlerLocatorInterface::resolve()` has been replaced by `getHandler(Envelope $envelope)`
* `SenderLocatorInterface::getSenderForMessage()` has been replaced by `getSender(Envelope $envelope)`
* `SenderInterface::send()` returns `void`
+ some internal simplifications
Commits
-------
4a3edd0b37 [Messenger] internal cleanups
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Messenger] make middlewares truly lazy on a bus
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Right now, as soon as a message is dispatched on a bus, all its handlers are instantiated.
This PR fixes it by leveraging `IteratorAggregate` when possible (implemented by DI's `RewindableGenerator`).
Commits
-------
6a5d7a1aac [Messenger] make middlewares truly lazy on a bus
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Messenger] make Envelope first class citizen for middleware handlers
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | no
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR sits on top of #28909 so that only the 2nd commit should be reviewed for now, until I rebase it.
This idea has already been proposed and rejected in #27322.
Yet, now that I've reviewed in depth the component, I politely but strongly suggest to reconsider.
Middleware handlers are the central piece of the routing layer.
When `dispatch()` accepts `object|Envelope`, it's because it sits on the outer boundary of the component. `handle()` on the contrary plugs inside its core routing logic, so that it's very legitimate to require them to deal with `Envelope` objects. Yes, some middleware care only about the message inside. That's fine calling `getMessage()` for them.
Right now, we built a complex magic layer that acts as a band-aid *just* to save this call to `getMessage()`. For middleware that want the envelope, we require an additional interface that magically *changes* the expected argument. That's very fragile design: it breaks the `L` in `SOLID`...
Looking at the diff stat, this is most natural.
Commits
-------
ae46a436e7 [Messenger] make Envelope first class citizen for middleware handlers
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Messenger] made dispatch() and handle() return void
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | no
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Middlewares and dispatchers should not return any value. Forwarding back the results from handlers breaks the scope of the component. The canonical example of some bad design this can lead to is `ChainHandler`: how can the caller know that there is one in the chain and that it should expect an array as a return value? More generally, how can a caller know what to expect back from a call to dispatch()? I think we should not allow such broken designs.
Instead, we should favor east-oriented design: if one needs a command bus, one would have to dispatch a proper command object - and if a result is expected back, it should be done via a setter on the dispatched command - or better, a callback set on the command object. This way we play *by the rules* of the type-system, not against.
Commits
-------
f942ffcb1b [Messenger] made dispatch() and handle() return void
This PR was merged into the 4.2-dev branch.
Discussion
----------
Fix debug:container which crash when the service class has no doc comment
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
The console command container:debug have now the ability to display service description, based on phpdoc comments of the service class. But the command currently crash when selecting a service with a class without phpdoc description.
This PR fixes this issue.
Commits
-------
aed0a5a38a [FrameworkBundle] Fix debug:container which crash when the service class has no doc comment
This PR was squashed before being merged into the 3.4 branch (closes#28893).
Discussion
----------
[TwigBundle] Fix usage of TwigBundle without FrameworkBundle
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
According to the composer.json (https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/TwigBundle/composer.json), the FrameworkBundle shouldn't be required to use the bundle (which can be useful in tests of other bundles for instance). However, it is not the case, mainly due to issues with direct references to unavailable services.
I target 3.4 because 812fbb444f is the main reason for the issue. We may have added additional problems in 4.0 and 4.1.
Commits
-------
246a905f93 [TwigBundle] Fix usage of TwigBundle without FrameworkBundle