This PR was squashed before being merged into the 2.3 branch (closes#17997).
Discussion
----------
Updated all the README files
| Q | A
| ------------- | ---
| Branch | 2.3
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Related to #17995.
Commits
-------
2e81248 Updated all the README files
This PR was merged into the 2.3 branch.
Discussion
----------
[HttpKernel] Remove _path from query parameters when fragment is a subrequest
| Q | A
| ------------- | ---
| Bug fix? | Yes
| New feature? | No
| BC breaks? | No
| Deprecations? | No
| Tests pass? | Yes
| Fixed tickets |
| License | MIT
| Doc PR |
Prior to 2.3.29, all requests to the ESI fragment path ("/_fragment" by default) would have the "_path" query parameter removed. This held true whether an external proxy (such as Varnish) handled the request as true ESI, or whether the Symfony kernel was mocking ESI behavior and inlining the subrequest.
Once the "_controller" check was added in 2.3.29, the "_path" query parameter was only removed on master requests (such as those coming from an external proxy) and not subrequests, leading to differing behavior in production and development settings.
Commits
-------
c374420 Remove _path from query parameters when fragment is a subrequest and request attributes are already set Added tests for _path removal in FragmentListener
This PR was merged into the 2.3 branch.
Discussion
----------
Static code analysis
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Things that done:
* fix case in method calls
* removed unused imports
* use shorter concat where it possible
* optimize some css
* removed duplicated array keys
* removed redurant return statements
* removed one-time variables
* do not pass arguments that not used in functions
Commits
-------
8db691a Static code analysis
This PR was merged into the 2.3 branch.
Discussion
----------
[HttpKernel] Lookup the response even if the lock was released after two second wait
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
While looking into #15813 I noticed that we [wait for the lock to be released for five seconds, but then only do a lookup if the lock was released in two seconds](fa604d3c6f/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php (L540-L562)), no more.
I think it's worth to make both values the same (so either two or five seconds). I see no reason why we should wait for the lock for five seconds, but then only do a lookup if we waited for two. One way the wait either takes too long, the other way we loose the opportunity to actually return a response.
Commits
-------
9963170 [HttpKernel] Lookup the response even if the lock was released after 2 seconds
This PR was merged into the 2.3 branch.
Discussion
----------
Do not use HttpKernel Extension when not needed
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
HttpKernel Extension only adds `addClassesToCompile`. So the class hierarchy should be slim if it's not used.
Commits
-------
4978e19 Do not use HttpKernel Extension when not needed
This PR was squashed before being merged into the 2.3 branch (closes#16312).
Discussion
----------
[HttpKernel] clearstatcache() so the Cache sees when a .lck file has been released
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #15813
| License | MIT
| Doc PR | n/a
I've been trying to debug #15813 and modified the Store in a way to keep unique request IDs in the .lck file. That way, I was hoping to find out which request is blocking and/or if the request is actually still running.
It turned out that `is_file()` would claim that a lock file still exists, but a subsequent attempt to read the information from that file returned "file not found" errors.
So, my assumption is that the `is_file()` result is based on the fstat cache and wrong once a process has seen the lock file.
@jakzal said in https://github.com/symfony/symfony/issues/15813#issuecomment-149013691 that `unlink()`ing the lock file should clear the statcache, but I doubt this is true across PHP processes.
Commits
-------
982710f [HttpKernel] clearstatcache() so the Cache sees when a .lck file has been released
This PR was merged into the 2.3 branch.
Discussion
----------
added the new Composer exclude-from-classmap option
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Commits
-------
65bef75 added the new Composer exclude-from-classmap option
