This PR was merged into the 4.4 branch.
Discussion
----------
[ErrorHandler] merge and remove the ErrorRenderer component
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
This PR supersedes #34288.
Here is what it does:
- Merge the `ErrorRenderer` component into `ErrorHandler`
- Add `ErrorRendererInterface::render(\Throwable $e): FlattenException` and refactor error renderers around it.
- Add `FlattenException::setAsString()` to make the previous possible.
- Add `CliErrorRenderer` to render error on the CLI too. This means `VarDumper` is now a required dependency of `ErrorHandler`. This paves the way to use it also for rendering HTML - the logic there is much more advanced than what `HtmlErrorRenderer` provides and ever should provide.
- Make `BufferingLogger` map its collected logs to `error_log()` if they are not emptied before.
- Remove some classes that are not needed anymore (`ErrorRenderer`, `ErrorRendererPass`, `HtmlErrorRendererInterface`)
- Simplified the logic in `Debug::enable()` - nobody uses its arguments
- Fix a few issues found meanwhile.
With these changes, the component can be used standalone. One is now able to require only it, register it either with either `ErrorHandler::register()` or `Debug::enable()` and profit.
Commits
-------
d1bf1cada4 [ErrorHandler] help finish the PR
6c9157bbc2 [ErrorHandler] merge and remove the ErrorRenderer component
* 4.4:
bumped Symfony version to 4.3.8
updated VERSION for 4.3.7
updated CHANGELOG for 4.3.7
bumped Symfony version to 3.4.35
updated VERSION for 3.4.34
update CONTRIBUTORS for 3.4.34
updated CHANGELOG for 3.4.34
* 4.3:
bumped Symfony version to 4.3.8
updated VERSION for 4.3.7
updated CHANGELOG for 4.3.7
bumped Symfony version to 3.4.35
updated VERSION for 3.4.34
update CONTRIBUTORS for 3.4.34
updated CHANGELOG for 3.4.34
This PR was submitted for the master branch but it was merged into the 4.4 branch instead.
Discussion
----------
[HttpFoundation][Lock] Connection parameter corrected
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Connection parameter incorrectly specified. This variable doesn't exist, the data is in $connection instead.
Commits
-------
27207c3056 [HttpFoundation][Lock] Connection parameter corrected
This PR was merged into the 5.0-dev branch.
Discussion
----------
[Security] make ExceptionEvent handle all throwables
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
fixes `master` after merging #34309 up
Commits
-------
eba2d8efc9 make ExceptionEvent handle all throwables
This PR was merged into the 5.0-dev branch.
Discussion
----------
[5.0][Security] Minor clarification of the new isGranted signature
| Q | A
| ------------- | ---
| Branch? | 5.0
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | n/a
| License | MIT
| Doc PR | n/a
As we now only allow a single attribute for `isGranted()` in Symfony 5, let's adapt the PHPdoc and parameter name as well.
Commits
-------
e41e6b48a9 Clarified single attribute to isGranted() a bit more
This PR was merged into the 4.4 branch.
Discussion
----------
[HttpKernel] make ExceptionEvent able to propagate any throwable
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | yes
| Tickets | -
| License | MIT
| Doc PR | -
An alternative to #34306.
As a reminder, the goal of this series of PRs is to remove the `FatalThrowableError` wrapper that we introduced to seamlessly handle throwables when they were introduced in PHP 7.
From the changelog of `HttpKernel`:
* Deprecated methods `ExceptionEvent::get/setException()`, use `get/setThrowable()` instead
* Deprecated class `ExceptionListener`, use `ErrorListener` instead
And the final target: removed `Symfony\Component\ErrorHandler\Exception\ErrorException` (`FatalThrowableError` is already deprecated.)
Commits
-------
6f67f0e0c0 [HttpKernel] make ExceptionEvent able to propagate any throwable
This PR was merged into the 4.4 branch.
Discussion
----------
[4.4] Disallow symfony/contracts v2
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | N/A
| License | MIT
| Doc PR | N/A
Travis is red at the moment because unit tests on 4.4 are run against the incompatible event dispatcher contracts v2. https://travis-ci.org/symfony/symfony/jobs/609622341#L4719-L4725
~~This PR proposes to switch to individual packages, so we can specifically disallow those incompatible contracts.~~
This PR pins the `symfony/contracts` package to v1.1 on `symfony/symfony`.
Commits
-------
f2dc2d6d8b Disallow symfony/contracts v2.
This PR was merged into the 5.0-dev branch.
Discussion
----------
[Contracts] Add parameter type declarations to contracts
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #32179
| License | MIT
| Doc PR | N/A
This PR proposes to create a php 7.2 version of the contracts that maintains BC with Symfony 4. The PR suggests to bump the contracts version to ~~1.2~~ 2.0 on the master branch. We would still be able to maintain the contracts 1.1 branch on Symfony's 4.4 branch, should we need to patch the current contracts in the future.
This move would allow us to add parameter type declarations to existing contracts interfaces and make use of them in Symfony 5. Especially the Translation and EventDispatcher components benefit a lot from this bump, imho.
Contracts that will be added on the road to Symfony 6 wouldn't be restricted to the capabilities of php 7.1, which would be another benefit in my opinion.
~~<sup>1</sup> Test currently fail because the translator is called with `null` as translation key. That possibility should be deprecated imho.~~
Commits
-------
4de3773979 Add parameter type declarations to contracts.
This PR was merged into the 4.4 branch.
Discussion
----------
[Security] Fix defining multiple roles per access_control rule
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/pull/12371 needs to be reverted
#33584 deprecated passing multiple attributes to `AccessDecisionManager::decide()`, but this change must not impact `access_control` as you cannot define multiple rules with the same criteria for request matching (the first match wins).
Commits
-------
338b3dfd9f [Security] Fix defining multiple roles per access_control rule