This PR was merged into the 4.2-dev branch.
Discussion
----------
[Cache] added support for phpredis 4 `compression` and `tcp_keepalive` options
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
See https://pecl.php.net/package-changelog.php?package=redis
Commits
-------
2ff02cd333 [Cache] added support for phpredis 4 `compression` and `tcp_keepalive` options
This PR was merged into the 4.2-dev branch.
Discussion
----------
[DX] Log potential redirect loops caused by forced HTTPS
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #27603
| License | MIT
| Doc PR | n/a
If the developer forgets/fails to set "trusted_proxies" properly, forcing the
https channel can cause infinite redirect loops. This change will hopefully
help them identify the problem faster.
See https://github.com/symfony/symfony/issues/27603
Commits
-------
53048cec6d Log potential redirect loops caused by forced HTTPS
This PR was submitted for the 4.1 branch but it was merged into the 2.8 branch instead (closes#27657).
Discussion
----------
[ExpressionLanguage] change `evaluate()` docblock return type from string to mixed
Issue: https://github.com/symfony/symfony/issues/27652
Commits
-------
2d26a556fd change `evaluate()` docblock return type from string to mixed
This PR was squashed before being merged into the 4.2-dev branch (closes#27653).
Discussion
----------
[Translation] Improved the performance of the lint:xliff command
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #27564
| License | MIT
| Doc PR | -
As suggested by @stof I extracted the schema validation logic from XliffFileLoader to reuse it in the `lint:xliff` command. The validation is now instantaneous, so the command is blazing fast!
Commits
-------
e53bf5839b [Translation] Improved the performance of the lint:xliff command
This PR was merged into the 2.8 branch.
Discussion
----------
Set serialize_precision explicitly to avoid fancy float rounding
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | -
This is fixing some of the test failures I was seeing locally due to increased `serialize_precision` INI setting:
```
2) Symfony\Component\HttpFoundation\Tests\JsonResponseTest::testConstructorWithSimpleTypes
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'0.1'
+'0.10000000000000001'
/www/symfony/symfony/src/Symfony/Component/HttpFoundation/Tests/JsonResponseTest.php:46
3) Symfony\Component\HttpFoundation\Tests\JsonResponseTest::testStaticCreateWithSimpleTypes
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'0.1'
+'0.10000000000000001'
```
The test assertions should not depend on externally configured PHP configuration.
Also default value for this option was changed multiple times: http://php.net/manual/en/ini.core.php#ini.serialize-precision
For compatibility reasons (with PHP <7.x) `-1` can't be used.
https://3v4l.org/HBNsT
HHVM doesn't seem to support this though, how to handle this?
Commits
-------
b5ee7c3ccd Set serialize_precision explicitly to avoid fancy float rounding
This PR was merged into the 4.1 branch.
Discussion
----------
[Messenger] Fixed MessengerPass::guessHandledClasses return type
| Q | A
| ------------- | ---
| Branch? | 4.1
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets | #27633
| License | MIT
| Doc PR | ø
#27633 should have been merged to 4.1.
Commits
-------
d6b6e9658c [Messenger] Fixed MessengerPass::guessHandledClasses return type
This PR was merged into the 3.4 branch.
Discussion
----------
[Config] Fixing GlobResource when inside phar archive
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | yes if old broken behavior counts as stable
| Deprecations? | no
| Tests pass? | no tests yet
| Fixed tickets |
| License | MIT
| Doc PR | N/A
When packaging an Sf4 application as a PHAR archive using globs at various locations (`Kernel`, `services.yaml`) most glob files are not found because the `glob()` PHP method [does not support PHAR streams](https://stackoverflow.com/questions/8203188/unexpected-problems-with-php-phar).
Using the regex fallback instead when operating inside PHAR archives fixes the behavior for me.
## Examples:
`src/Kernel.php::configureContainer()`:
```php
$loader->load($confDir.'/{services}'.self::CONFIG_EXTS, 'glob');
```
Expected behavior: `config/services.yaml` inside PHAR archive is found and parsed
Actual behavior: the file will not be loaded
`config/services.yaml` (hard-coded in Kernel without using glob pattern)
```yaml
App\:
resource: '../src/*'
exclude: '../src/{Entity,Migrations,Tests,Kernel.php}'
```
Expected behavior: service classes in `src/` will be found and auto-wired
Actual behavior: services are not auto-wired because the class files are not found
Commits
-------
e336ebeecf Fixing GlobResource when inside phar archive
This PR was merged into the 3.4 branch.
Discussion
----------
[Cache] fix Memcached tests
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Clearing a memcached pool works only when versioning is enabled. Dunno why this has not be caught before, but it's making tests fail now.
Commits
-------
09ec9e7cce [Cache] fix Memcached tests
* 4.1:
[HttpKernel] fix PHP 5.4 compat
Fix surrogate not using original request
[Finder] Update RealIteratorTestCase
[Routing] remove unneeded dev dep on doctrine/common
[minor] SCA
[Validator] Remove BOM in some xlf files
Ensure updateTimestamp returns a boolean
Fix#27378: Error when rendering a DateIntervalType form with exactly 0 weeks
[HttpKernel] fix session tracking in surrogate master requests
* 4.0:
[HttpKernel] fix PHP 5.4 compat
Fix surrogate not using original request
[Finder] Update RealIteratorTestCase
[Routing] remove unneeded dev dep on doctrine/common
[minor] SCA
[Validator] Remove BOM in some xlf files
Fix#27378: Error when rendering a DateIntervalType form with exactly 0 weeks
[HttpKernel] fix session tracking in surrogate master requests
* 3.4:
[HttpKernel] fix PHP 5.4 compat
Fix surrogate not using original request
[Finder] Update RealIteratorTestCase
[Routing] remove unneeded dev dep on doctrine/common
[minor] SCA
[Validator] Remove BOM in some xlf files
Fix#27378: Error when rendering a DateIntervalType form with exactly 0 weeks
[HttpKernel] fix session tracking in surrogate master requests
* 2.8:
[HttpKernel] fix PHP 5.4 compat
Fix surrogate not using original request
[Finder] Update RealIteratorTestCase
[Routing] remove unneeded dev dep on doctrine/common
[Validator] Remove BOM in some xlf files
This PR was merged into the 4.2-dev branch.
Discussion
----------
[FrameworkBundle] Fixed tests added in #27611
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no <!-- 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 | ~
| License | MIT
| Doc PR | ~
<!--
Write a short README entry for your feature/bugfix here (replace this comment block.)
This will help people understand your PR and can be used as a start of the Doc PR.
Additionally:
- Bug fixes must be submitted against the lowest 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 the master branch.
-->
Commits
-------
be97006c57 [FrameworkBundle] Fixed tests added in #27611
If the developer forgets/fails to set "trusted_proxies" properly, forcing the
https channel can cause infinite redirect loops. This change will hopefully
help them identify the problem faster.
See https://github.com/symfony/symfony/issues/27603
When packaging an Sf4 application as a PHAR archive using globs at various locations (`Kernel`, `services.yaml`) most glob files are not found because the `glob()` PHP method [does not support PHAR streams](https://stackoverflow.com/questions/8203188/unexpected-problems-with-php-phar).
Using the regex fallback instead when operating inside PHAR archives fixes the behavior for me.
This PR was merged into the 3.4 branch.
Discussion
----------
[Form] Fix error when rendering a DateIntervalType form with exactly 0 weeks
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #27378
| License | MIT
Fixes the issue described in #27378
Commits
-------
dae704ad2fFix#27378: Error when rendering a DateIntervalType form with exactly 0 weeks
This PR was merged into the 4.2-dev branch.
Discussion
----------
CacheWarmerAggregate handle deprecations logs
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #27387
| License | MIT
Actually the Web Debug Toolbar warning you about the deprecation messages thrown during the container built (#21502).
Cache warmup can throw deprecated message without any persistance, it may cause issue like #27387
This PR reproduce the same job for the cache warmer, and so on, handle deprecated messages during the warmup of Twig, Translator, Validator, Security and all `kernel.cache_warmer` services.
Here are the point that may be improvable in this PR:
1. Actually I've "duplicate" the callable used in the `set_error_handler` of the Kernel.
IMHO I think that Kernel and CacheWarmerAggregate have differents jobs and a trait may be a good solution to share this error handler setter without duplicating the code, but I'm a little bit lost about the repercussion of adding a Trait in the Kernel.
2. I've think about extending the `CacheWarmerAggregate` into a `DeprecatedLogHandlingCacheWarmerAggregate` to add the debug and containerClass argument, and declare it as the `cache_warmer` service only in debug mode (by declaring it in the DebugBundle/Resources/config/services.xml).
Commits
-------
f03b8bba9d CacheWarmerAggregate handle deprecations logs
This PR was submitted for the 3.4 branch but it was squashed and merged into the 2.8 branch instead (closes#27309).
Discussion
----------
Fix surrogate not using original request
| 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 |
Warning: This might need some close attention. It took me hours to wrap my head around that issue :-)
So the problem is that `HttpCache::forward()` (or essentially any part in your application) can modify the `$request` that is passed to the `HttpCache::handle()` and the surrogate can never access the original request using `HttpCache::getRequest()` anymore.
Example:
* Main request (GET `/foobar`)
* It's not in the cache, so `HttpCache::forward()` modifies `REMOTE_ADDR` to `127.0.0.1` and adds the `X-Forwarded-For` header.
* The request is sent to the application and any e.g. `kernel.request` listener might modify the `$request` further.
* Now the `/foobar` route returns `text/html` that contains some `<esi src="=/fragment_path"` tag.
* `HttpCache` has an instance of `SurrogateInterface` so (in our case `Esi`) will be asked to `process()` and then later on `handle()` the `/fragment_path` request. For that, `Esi` (or in fact `AbstractSurrogate` uses the following line to create a subrequest and pass it on to the application again:
```php
$subRequest = Request::create($uri, Request::METHOD_GET, array(), $cache->getRequest()->cookies->all(), array(), $cache->getRequest()->server->all());
```
What you can see here, is that it uses `$cache->getRequest()`. And here follows the problem:
We did not duplicate (clone) the original request so essentially `$cache->getRequest()` is a reference to the current request that `HttpKernel::forward()` modified and probably any other part of the application did so too. So for example the original `REMOTE_ADDR` (client IP) got lost.
What we should do instead is duplicate the original request so the surrogates can actually behave like a real reverse proxy such as Varnish would by keeping all the original request attributes.
Commits
-------
ab86f43d78 Fix surrogate not using original request