This PR was squashed before being merged into the 4.0 branch (closes#27676).
Discussion
----------
[minor] SCA
| Q | A
| ------------- | ---
| Branch? | 4.0>
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Found some leftovers after introducing parameter types in 4.0.
Commits
-------
afeb89fa06 [minor] SCA
This PR was squashed before being merged into the 3.4 branch (closes#26534).
Discussion
----------
allow_extra_attributes does not throw an exception as documented
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | none
| License | MIT
| Doc PR | none
The example at [Deserializing an object](https://symfony.com/doc/current/components/serializer.html#deserializing-an-object) does not actually work. It looks like this is a bug and not a docs issue. https://github.com/symfony/symfony/issues/24783 reported the same bug, but it looks like the fix at https://github.com/symfony/symfony/pull/24816 isn't complete.
Here's a failing test that copies the existing example.
Commits
-------
a67b650f12 allow_extra_attributes does not throw an exception as documented
This PR was merged into the 2.8 branch.
Discussion
----------
[Serializer] Updates DocBlock to a mixed param type
| Q | A
| ------------- | ---
| Branch? | 4.1
| Bug fix? | Yes
| New feature? | No
| BC breaks? | No
| Deprecations? | Non added.
| Tests pass? | Yes , no new tests added.
| Fixed tickets | #27457
| License | MIT
<!--
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.
-->
The JSON serializers make use of the JsonSerializable interface and return arrays to the NormalizerInterface. This PR updates the DocBlock to reflect that.
Moving towards PHP 7.2 and the use of object type-hints would require changes to the [JsonSerializableNormalizer@L41](92c37b9711/src/Symfony/Component/Serializer/Normalizer/JsonSerializableNormalizer.php (L41)) at a minimum.
Truly not much of a PR I'm afraid!
Commits
-------
dca9ff529a [Serializer] Updates DocBlock to a mixed param type
* 3.4:
[Lock] use 'r+' for fopen (fixes issue on Solaris)
[HttpKernel] fix test compat with PHP 5.3
fix handling of nested Error instances
fix file lock on SunOS
[Cache] more granular handling of exceptions in AbstractTrait::clear()
change `evaluate()` docblock return type from string to mixed
Set serialize_precision explicitly to avoid fancy float rounding
This PR was squashed before being merged into the 3.4 branch (closes#27668).
Discussion
----------
[Lock] use 'r+' for fopen (fixes issue on Solaris)
| Q | A
| ------------- | ---
| Branch? | 3.4 (also applicable to _LockHandler_ in 2.8 and 3.3)
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes [1]
| Fixed tickets | -
| License | MIT
| Doc PR | -
We discovered a curious case on a specific hosting environment: the `FlockStorage` (or `LockHandler` in previous Symfony versions) could never get a file lock on **existing files**. So if you run a script for the first time and the lock file did not exist yet, the `FlockStorage` could get a lock on that file just fine. However on the second and subsequent runs, `FlockStorage` could _never_ get a file lock anymore. You can follow the discussion [here](https://github.com/contao/core-bundle/issues/1551) (if you speak German).
We have been using this little script to confirm the issue on the hosting environment:
```php
$fileName = __DIR__ . '/file.lock';
if (!$handle = @fopen($fileName, 'r')) {
$handle = fopen($fileName, 'x');
}
if (!$handle) {
echo "Could not open $fileName\n";
exit;
}
if (flock($handle, LOCK_EX | LOCK_NB)) {
echo "Got a lock on $fileName\n";
flock($handle, LOCK_UN | LOCK_NB);
} else {
echo "Could not get a lock on $fileName\n";
}
```
Whenever `file.lock` already existed prior to running the script, a lock could not be made.
After contacting the hosting provider's support on this they confirmed the issue and told us they are using **Solaris** instead of a Linux environment. And this is supposedly why it does not work. Instead you have to use `'r+'` instead of `'r'` for `fopen`.
I was able to confirm that changing from `'r'` to `'r+'` fixes the issue. However I am wondering who's actually at fault here. Is it Solaris? PHP? The compiled PHP version under Solaris? The hosting provider's operating system configuration?
### System information
```
uname -a
SunOS vlek 5.11 11.3 i86pc i386 i86pc Solaris
```
```
phpinfo:
SunOS localhost 5.10 Generic_150401-49 i86pc
```
```
php -v
PHP 7.2.5 (cli) (built: May 4 2018 12:57:43) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
```
### Footnotes
[1] Previously one failed test on the first run and two failing tests on the second run with the proposed changes:
```
1) Symfony\Component\Lock\Tests\Store\FlockStoreTest::testSaveSanitizeName
Symfony\Component\Lock\Exception\LockStorageException: fopen(C:\Users\[…]\AppData\Local\Temp/sf.-php-echo-hello-word-.Sz2dDSf.lock)
: failed to open stream: Permission denied
```
```
2) Symfony\Component\Lock\Tests\Store\FlockStoreTest::testSaveWithDifferentKeysOnSameResources
Symfony\Component\Lock\Exception\LockStorageException: fopen(C:\Users\[…]\AppData\Local\Temp/sf.Symfony-Component-Lock-Tests-Store-
AbstractStoreTest-testSaveWithDifferentKeysOnSameResources5b2b5f00872538.64807920.2u9bH+a.lock): failed to open stream: Permission denied
```
The latter failed both on the first run and on the second run.
After the [proposed changes](https://github.com/symfony/symfony/pull/27668#discussion_r197054198) from @nicolas-grekas everything works fine 👍
Commits
-------
9c9ae7d9c9 [Lock] use 'r+' for fopen (fixes issue on Solaris)
* 2.8:
[HttpKernel] fix test compat with PHP 5.3
fix file lock on SunOS
change `evaluate()` docblock return type from string to mixed
Set serialize_precision explicitly to avoid fancy float rounding
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 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 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
* 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
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 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
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpKernel] fix session tracking in surrogate master 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 | -
Spotted while looking at ESI fragments resolved by`HttpCache`: right now when the master request starts the session, fragments are not cacheable anymore, even when they do not use the session.
Commits
-------
146e01cb44 [HttpKernel] fix session tracking in surrogate master requests
This PR was submitted for the master branch but it was squashed and merged into the 2.8 branch instead (closes#27508).
Discussion
----------
[Finder] Update RealIteratorTestCase
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #27480
| License | MIT
| Doc PR | n/a
Makes the entire test directory empty instead of trying to delete particular files and directories. The old method failed when trying to remove a directory which was not empty.
Commits
-------
7d0ebd41ab [Finder] Update RealIteratorTestCase
This PR was squashed before being merged into the 3.4 branch (closes#27623).
Discussion
----------
[minor] SCA
| Q | A
| ------------- | ---
| Branch? | 3.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
New findings: language level, greedy regex, array_column usages
Commits
-------
5922507dc5 [minor] SCA
This PR was submitted for the 3.4 branch but it was merged into the 2.8 branch instead (closes#27630).
Discussion
----------
[Validator][Form] Remove BOM in some xlf files
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? |
| Fixed tickets | #...
| License | MIT
| Doc PR | symfony/symfony-docs#...
I removed first blank space from some xml files
It caused this error during cache:clear
[ERROR 4] Start tag expected, '<' not found (in n/a - line 1, column 1)
Commits
-------
0bc53d66c0 [Validator] Remove BOM in some xlf files
