This PR was merged into the 4.4 branch.
Discussion
----------
Fix phpdocs
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- 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 | n/a
| License | MIT
| Doc PR | n/a
Backported from #32286
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/roadmap):
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against branch 4.4.
- Legacy code removals go to the master branch.
-->
Commits
-------
4acddef91b fixed phpdocs
This PR was merged into the 4.4 branch.
Discussion
----------
[FrameworkBundle] Allow creating chained cache pools by providing several adapters
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Replaces #30984, follows https://github.com/symfony/symfony-docs/pull/11813
This PR allows defining several adapters for one pool. When doing so, this defines a chain pool.
The benefit is that all chained pools get automatic namespace and lifetime, so things are transparent:
```yaml
pools:
my_chained_pool:
default_lifetime: 12
adapters:
- cache.adapter.array
- cache.adapter.filesystem
- {name: cache.adapter.redis, provider: 'redis://foo'}
```
(see fixtures for example of PHP/XML config)
/cc @Nyholm @pborreli FYI
Commits
-------
29ba091898 [FrameworkBundle] Allow creating chained cache pools by providing several adapters
This PR was merged into the 4.3 branch.
Discussion
----------
[Messenger] fix broken key normalization
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no <!-- 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 |
| License | MIT
| Doc PR |
Disable broken key normalization in messenger config.
If you tried to use `-` in a transport/bus it didn't work and you get a cryptic error (#31613)
```
framework:
messenger:
transports:
my-bus: '...'
routing:
Acme\MyMessage: my-bus
```
The default behavior of normalizing keys is really annoying and a waste of time in most cases. I've measured `\Symfony\Component\Config\Definition\ArrayNode::preNormalize` in a project and it takes 4 ms.
As an idea, we could disabling normalizing keys automatically when you call `useAttributeAsKey` because the value is then user-provided and shouldn't be modified (in contrast to children properties of an arrayNode which should get normalized for xml support).
Commits
-------
9931b3e183 [Messenger] fix broken key normalization
This PR was merged into the 4.4 branch.
Discussion
----------
[ErrorCatcher] Fixed some escaping in error renderers
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no <!-- 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 | -
| License | MIT
| Doc PR | not needed
Fixes this: https://github.com/symfony/symfony/pull/32364/files#r300394620
Commits
-------
1413bdc [ErrorCatcher] Fixed some escaping in XML errors
This PR was merged into the 4.4 branch.
Discussion
----------
[ErrorCatcher] Pretty print JSON formatted errors
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | not needed
A long string with JSON contents is not very useful to quickly parse the error contents, so I propose to "pretty print" the JSON errors.
Commits
-------
ab926d2 [ErrorCatcher] Pretty print JSON formatted errors
This PR was merged into the 3.4 branch.
Discussion
----------
[FrameworkBundle] reset cache pools between requests
| 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 | -
Looks like we missed this part: cache pools should all be reset between requests, at least to persist any deferred items. Replaces #32361 (which should be applied when merging 3.4 into 4.2).
Commits
-------
5ff45bac66 [FrameworkBundle] reset cache pools between requests
This PR was merged into the 3.4 branch.
Discussion
----------
[DI] fix processing of regular parameter bags by MergeExtensionConfigurationPass
| 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 | -
Spotted in and needed by #32294
Commits
-------
b06d0003a3 [DI] fix processing of regular parameter bags by MergeExtensionConfigurationPass
This PR was merged into the 4.4 branch.
Discussion
----------
[Messenger] Use ConnectionRegistry instead of RegistryInterface
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
This PR changes the constructor type-hint on `DoctrineTransportFactory` from `Symfony\Bridge\Doctrine\RegistryInterface` to the smaller `Doctrine\Common\Persistence\ConnectionRegistry`. Since we only call the `getConnection()` method, this interface is sufficient.
This change allows to use the factory without the Doctrine bridge and makes it easier to use it stand-alone.
Commits
-------
ce6a5ad235 Use ConnectionRegistry instead of RegistryInterface.
This PR was squashed before being merged into the 4.4 branch (closes#32348).
Discussion
----------
[HttpFoundation] Accept must take the lead for Request::getPreferredFormat()
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no <!-- 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 | n/a
| License | MIT
| Doc PR | n/a
Follow up PR to #32344: if both `Accept` and `Content-Type` are defined, `Accept` must take the lead because it explicitly tells what format the client expect as a response.
Before:
```
$ curl -H 'Accept: application/json' -H 'Content-Type: text/xml' -i 'https://127.0.0.1:8000/userinfo'
[snip]
content-type: text/xml
```
After:
```
$ curl -H 'Accept: application/json' -H 'Content-Type: text/xml' -i 'https://127.0.0.1:8000/userinfo'
[snip]
content-type: application/json
```
Actually, I'm not sure that inferring the content type of the response using the `Content-Type` provided for the request body is a good idea. The HTTP RFC explicitly states that `Accept` must be used to hint a preferred response format (`Content-Type` on the request indicates the type of associated its the body). I would be in favor of being more conservative: use `Accept` if provided (a best practice anyway), and fallback to the default value (HTML by default) otherwise. WDYT?
Commits
-------
60d997df75 [HttpFoundation] Accept must take the lead for Request::getPreferredFormat()
This PR was submitted for the 4.3 branch but it was merged into the 4.4 branch instead (closes#32207).
Discussion
----------
[FrameworkBundle] Allow to use the BrowserKit assertions with Panther and API Platform's test client
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no <!-- 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 | n/a
| License | MIT
| Doc PR | n/a
I'm adding a testing client for API Platform that implements the interfaces of HttpClient: https://github.com/api-platform/core/pull/2608
Most PHPUnit assertions provided by Symfony are useful and can be reused, but the ones using the crawler are not relevant and pollute auto-complete suggestions (because a web API usually returns JSON, not HTML).
This PR splits the existing trait to allow reusing the HTTP related assertions only.
Commits
-------
cd0341e69b [FrameworkBundle] Allow to use the BrowserKit assertions with Panther and API Platform's test client
* 4.3:
Fixes windows error
[Messenger] Added more test for MessageBus
fixed typo
[Filesystem] added missing deprecations to UPGRADE-4.3.md
Fix authentication for redis transport
only decorate when an event dispatcher was passed
[FrmaeworkBundle] More simplifications in the DI configuration
Fixing validation for messenger transports retry_strategy service key
Removed unused field.
Remove @internal annotations for the serilize methods
[Lock] Stores must implement `putOffExpiration`
Annotated correct return type for getInEdges()/getOutEdges().
deprecate the framework.templating option
* 4.2:
Fixes windows error
Removed unused field.
[Lock] Stores must implement `putOffExpiration`
Annotated correct return type for getInEdges()/getOutEdges().
This PR was submitted for the 4.3 branch but it was merged into the 3.4 branch instead (closes#32187).
Discussion
----------
[PHPUnit] Fixed composer error on Windows
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Fixed tickets | #31750
| License | MIT
Fixes bug when composer runs from bat file that described in PATH env.
Commits
-------
1f8927a9a6 Fixes windows error
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpFoundation][HttpKernel] Improving the request/response format autodetection
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Mainly for API-based apps, currently the response header `Content-Type` (if no provided) is guessed based on the request format (`_format` attribute), falling back to `html` by default.
Especially for the new error renderer system, where any kind of error can occur and it becomes an http response, this PR improves this guesser mechanism by taking into account also the `Content-type` of the request.
Example:
```bash
$ curl -X POST -H 'Content-Type: application/json' -i 'https://127.0.0.1:8000/login'
```
**before:**
```bash
HTTP/2 500
cache-control: no-cache, private
content-type: text/html; charset=UTF-8 # <- inaccurate
...
{"title":"Internal Server Error","status":500,"detail":"Invalid credentials!"}
```
Most of the 3rd-party bundles that I know (`api-platform/core`, `FOSRestBundle`) need a dedicated listener to achieve it right.
**after:**
```bash
HTTP/2 500
cache-control: no-cache, private
content-type: application/json
...
{"title":"Internal Server Error","status":500,"detail":"Invalid credentials!"}
```
Of course, this applies to all kind of responses, as long as the `Content-Type` is not explicitly provided. So, as a last chance, the `Accept` heading of the request is also taken into account to detect the preferred format:
```bash
$ curl -H 'Accept: application/json' -i 'https://127.0.0.1:8000/userinfo'
HTTP/2 404
cache-control: no-cache, private
content-type: application/json
...
{"title":"Not Found","status":404,"detail":"No route found for \"GET \/userinfo\""}
```
They could be other places in the code where this new method could also be useful, please advise :)
WDYT?
Commits
-------
1952928471 Improving the request/response format autodetection
This PR was merged into the 4.2 branch.
Discussion
----------
[Lock] Stores must implement `putOffExpiration`
| 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 | /
Following https://github.com/symfony/symfony/pull/32198#pullrequestreview-256165051 every stores MUST implement the method `putOffExpiration` either by ignoring the arguments (by design they lock forever) or using a mechanism to define the expiration.
It was a mistake to add the dockblock `@throws NotSupportedException` tell me if it's a BC break, I'll create a dedicated PR for it.
Commits
-------
c986c86d1c [Lock] Stores must implement `putOffExpiration`
This PR was merged into the 4.3 branch.
Discussion
----------
[Mime] Remove @internal annotations for the serialize methods
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes (it's not really a bug)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
Currently, when we extend the `Symfony\Component\Mime\Message` and `Symfony\Component\Mime\MessageRaw` classes of the Mime component, we get 2 deprecation messages:
```
The "Symfony\Component\Mime\Message::__serialize()" method is considered internal. It may change without further notice. You should not extend it from "Vendor\FooMessage".
```
and
```
The "Symfony\Component\Mime\Message::__unserialize()" method is considered internal. It may change without further notice. You should not extend it from "Vendor\FooMessage".
```
However, we need to add properties to the new class, and so, we need to extend `__serialize()` and `__unserialize()` methods in the same way as `Symfony\Bridge\Twig\Mime\TemplatedEmail`, to know, retrieve the serialization of the parent class:
```php
public function __serialize(): array
{
return [$this->foo, $this->bar, $this->baz, parent::__serialize()];
}
public function __unserialize(array $data): void
{
[$this->foo, $this->bar, $this->baz, $parentData] = $data;
parent::__unserialize($parentData);
}
```
But given that the third-party components use another namespace, we get the 2 deprecation messages, while the 2 methods must be inevitably used and extended. Of course, the methods `serialize()` and `unserialize()` are always marked by the `@internal` annotation and the `final` keyword.
This PR so deletes the 2 deprecation messages that should not be displayed.
Commits
-------
8544a35e52 Remove @internal annotations for the serilize methods
This PR was merged into the 4.3 branch.
Discussion
----------
[Messenger] Added more test for MessageBus
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
[This code](bed50fd542/src/Symfony/Component/Messenger/MessageBus.php (L33-L49)) is quite hard to understand. So It must be covered by tests.
More over, it will help people to understand how it works
Commits
-------
5f4ab23991 [Messenger] Added more test for MessageBus
