This PR was merged into the 4.4 branch.
Discussion
----------
[SecurityBundle] Drop duplicated code
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Commits
-------
ffbf31d8c6 [SecurityBundle] Drop duplicated code
This PR was squashed before being merged into the 4.4 branch (closes#35306).
Discussion
----------
[FrameworkBundle] Make sure one can use fragments.hinclude_default_template
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Using `framework.fragments.hinclude_default_template` is not possible in 4.4. You will always get an exception saying:
> You cannot set both "templating.hinclude_default_template" and "fragments.hinclude_default_template", please only use "fragments.hinclude_default_template".
That is because in [fragment_renderer.xml](https://github.com/symfony/symfony/blob/4.4/src/Symfony/Bundle/FrameworkBundle/Resources/config/fragment_renderer.xml#L8) we define the parameter `fragment.renderer.hinclude.global_template` to be an empty string, then in FrameworkExtension we are checking if it is null.
This PR do a `!empty` check instead. I also added a test to show the bug.
Commits
-------
25fd665d0e [FrameworkBundle] Make sure one can use fragments.hinclude_default_template
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpKernel] Fix that no-cache MUST revalidate with the origin
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
From [RFC 7234 Section 5.2.2](https://tools.ietf.org/html/rfc7234#section-5.2.2)
> The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
This is unconditional – the response must be revalidated right away.
(`must-revalidate`, to the contrary, requires revalidation only once the response has become stale.)
Commits
-------
c8bdcb3408 Fix that no-cache requires positive validation with the origin, even for fresh responses
* 4.3:
Avoid stale-if-error if kernel.debug = true, because it hides errors
[Console] Fix SymfonyQuestionHelper tests sometimes failing on AppVeyor
[Workflow] Fix configuration node reference for "initial_marking"
expand listener in place
[DI] deferred exceptions in ResolveParameterPlaceHoldersPass
* 3.4:
Avoid stale-if-error if kernel.debug = true, because it hides errors
[Console] Fix SymfonyQuestionHelper tests sometimes failing on AppVeyor
[DI] deferred exceptions in ResolveParameterPlaceHoldersPass
This PR was merged into the 4.3 branch.
Discussion
----------
[Workflow] Fix configuration node reference for "initial_marking"
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Related to | #30890
| License | MIT
Commits
-------
452f92540b [Workflow] Fix configuration node reference for "initial_marking"
This PR was merged into the 3.4 branch.
Discussion
----------
Avoid `stale-if-error` in FrameworkBundle's HttpCache if kernel.debug = true
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#24248 (maybe?)
| License | MIT
| Doc PR |
When working with the `HttpCache` in development, error messages may not become visible if a `public` response has been successfully generated for the same URL before.
This is because the `HttpCache` from the `HttpKernel` component by default sets `stale_if_error` to 60 seconds.
At least when using the `HttpCache` subclass from the `FrameworkBundle`, we know about the `kernel.debug` setting and its intention to support local development. In that case, we could set the *default* `stale-if-error` value to 0.
Commits
-------
3a23ec89c3 Avoid stale-if-error if kernel.debug = true, because it hides errors
This PR was merged into the 3.4 branch.
Discussion
----------
[DI] deferred exceptions in ResolveParameterPlaceHoldersPass
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#30428
| License | MIT
| Doc PR | n/a
fixes case #30428
implemented as in AutowiringPass
Commits
-------
b3a2173c8e [DI] deferred exceptions in ResolveParameterPlaceHoldersPass
This PR was merged into the 4.4 branch.
Discussion
----------
[Filesystem][FilesystemCommonTrait] Use a dedicated directory when there are no namespace
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
This PR fixes the following edge case:
- you use a namespaced filesystem adapter with root dir `/foo` and namespace `a`: all files are written in `/foo/a` (eg: it will write `/foo/a/b/file`)
- you use another filesystem adapter with the same root dir but without namespace and you clear it.
- it will fail because it will try to delete the `/foo/a/b` directory (see https://github.com/symfony/symfony/pull/33921 new `scanHashDir()` method - `a` is a possible dir value (see `getFile()`) so we look for it).
The simple solution (suggested by @nicolas-grekas) is to put the "empty namespace" in a dedicated directory.
Bonus: that will fix the tests that currently always fail on AppVeyor. The file in the namespace `a` is a leftover from a previous test. Without this patch, I have the same fail on my Mac. I did not look why it currently passes on travis.
Commits
-------
eaa767bebd [Filesystem][FilesystemCommonTrait] Use a dedicated directory when there are no namespace
This PR was merged into the 3.4 branch.
Discussion
----------
[Console] Fix SymfonyQuestionHelper tests sometimes failing on AppVeyor
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/35035
| License | MIT
| Doc PR | -
The test uses heredoc for the expected part. Expected line returns are `"\n"` because that's how they are written in the source code file.
However, on Windows, the console outputs `"\r\n"` (`PHP_EOL`) for new lines.
`"qqq:\r\n"` does not contain `"qqq:\n"`.
I'm still wondering why this test is not *always* failing...
Commits
-------
474f3bef08 [Console] Fix SymfonyQuestionHelper tests sometimes failing on AppVeyor
This PR was merged into the 4.4 branch.
Discussion
----------
[FrameworkBundle] Do not throw exception on value generate key
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
When using env variable instead of key files and creating a new Secret, the check in `generateKeys` (called by the command `SecretsSetCommand`) prevents generating a secret.
reproducer:
```
$ rm config/secrets/prod/prod.decrypt.private.php
$ export SYMFONY_DECRYPTION_SECRET=XXX
$ ./bin/console secret:set FOO
In SodiumVault.php line 50:
Cannot generate keys when a decryption key has been provided while instantiating the vault.
```
This PR converts the exception in a warning message.
Commits
-------
2f608b4dfa Do not throw exception on valut generate key
This PR was merged into the 4.3 branch.
Discussion
----------
[EventDispatcher] expand listener in place
| Q | A
| ------------- | ---
| Branch? | 4.3
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35259
| License | MIT
| Doc PR |
Commits
-------
f5d407318d expand listener in place
This PR was merged into the 3.4 branch.
Discussion
----------
Added more tests for WebProfilerBundle
| 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 | - <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | -
Thanks to @jpauli Code Coverage info about Symfony (http://cov.jpauli.tech/) I found that WebProfiler's controllers are pretty badly covered:
![image](https://user-images.githubusercontent.com/73419/57919817-ec390500-7899-11e9-81b7-763a0b35d0ec.png)
This PR focuses on testing the main controller class:
![image](https://user-images.githubusercontent.com/73419/57919877-04108900-789a-11e9-8a93-3466b672d873.png)
Commits
-------
2f7a820edd Added more tests for WebProfilerBundle
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpKernel][FileLocator] Fix deprecation message
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Ref https://github.com/symfony/symfony/pull/34886
`$deprecatedPath` is the foreach value so it only works if the last element triggers the deprecation, otherwise the value is wrong.
Commits
-------
18ce8399d2 [HttpKernel][FileLocator] Fix deprecation message
* 4.3:
[Process] - update @throws phpdoc
[PHPUnitBridge] file_get_contents() expects parameter 3 to be resource
[PHPUnit-Bridge] Fail-fast in simple-phpunit if one of the passthru() commands fails
* 3.4:
[PHPUnitBridge] file_get_contents() expects parameter 3 to be resource
[PHPUnit-Bridge] Fail-fast in simple-phpunit if one of the passthru() commands fails
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[PHPUnitBridge] file_get_contents() expects parameter 3 to be resource
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
file_get_contents 3rd parameter (context) expects resource or NULL to ignore them
Commits
-------
a28a42187c [PHPUnitBridge] file_get_contents() expects parameter 3 to be resource
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[PHPUnit-Bridge] Fail-fast in simple-phpunit if one of the passthru() commands fails
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Some commands executed by the `simple-phpunit` script are not checked for success. For example [here](https://travis-ci.org/twigphp/Twig/jobs/634110681), Composer fails with the message
```
[InvalidArgumentException]
Could not find package phpunit/phpunit with version 7.5.* in a version inst
allable using your PHP version 7.0.25.
```
Yet, the `simple-phpunit` script happily continues, going over failing `chdir()`, `file_get_contents()` and `include()` calls and eventually returns a successful `0` exit code. So CI tests look OK when in fact PHPUnit was not even downloaded.
Commits
-------
576e18561f [PHPUnit-Bridge] Fail-fast in simple-phpunit if one of the passthru() commands fails
* 4.3:
[Debug] fix ClassNotFoundFatalErrorHandler
[Routing] Fix using a custom matcher & generator dumper class
[Dotenv] Fixed infinite loop with missing quote followed by quoted value
[HttpClient] Added missing sprintf
[TwigBridge] button_widget now has its title attr translated even if its label = null or false
[PhpUnitBridge] When using phpenv + phpenv-composer plugin, composer executable is wrapped into a bash script
[Messenger] Added check if json_encode succeeded
[Security] Prevent canceled remember-me cookie from being accepted
[FrameworkBundle][TranslationUpdateCommand] Do not output positive feedback on stderr
[Security\Guard] Fix missing typehints