This PR was merged into the 3.3-dev branch.
Discussion
----------
[HttpKernel] Refactored SessionValueResolver
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
I thought the comment has been addressed in #21164, but it may have been unintentionally lost while rebasing?
Commits
-------
f0e832a [HttpKernel] Refactored SessionValueResolver
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Remove experimental status from service-locator argument type
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/21625#issuecomment-282483374, https://github.com/symfony/symfony/pull/21625#discussion_r102232221, #21710
| License | MIT
The `service-locator` argument type is not controversial to me. We know its scope, nothing really surprising, just a map of services to be lazily loaded like `iterator` is (which is not experimental) but keyed.
About its api, it's just PSR-11 restricted to objects, nothing that can't be changed safely in the future.
As stated in https://github.com/symfony/symfony/pull/21625#issuecomment-282483374, it proven its usefulness already. I think what we were looking for by flagging it experimental is just to see it in action, we've 3 opened PRs for that (#21625, #21690, #21730).
This allows introducing deprecations for making use of the feature in the core, thus unlocks #21625 and #21690.
Commits
-------
46dc47af11 [DI] Remove experimental status from service-locator argument type
This PR was merged into the 3.3-dev branch.
Discussion
----------
[HttpKernel] Added the SessionValueResolver
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21159
| License | MIT
| Doc PR | (soon)
This feature adds the `SessionValueResolver`. That means that you no longer have to rely on injecting a `SessionInterface` implementation via the constructor or getting this implementation from the `Request`. Regardless of method, it does not know about the `getFlashBag()`.
By adding the `Session` to the action arguments, you can now type-hint against the implementation rather than interface, which contains the `getFlashBag()`, making it accessible rather than using duck-typing.
_It should also feel less like injecting a service into the constructor which has a state or getting a service from the request._
**Old Situation**
```php
class Controller
{
public function __construct(SessionInterface $session) { /* ... */ }
public function fooAction(Request $request)
{
$this->get('session')->get(...);
$request->getSession()->get(...);
$this->session->get(...)
// duck-typing
$this->get('session')->getFlashBag();
$request->getSession()->getFlashBag();
$this->session->getFlashBag();
$this->addFlash(...);
}
}
```
**New Situation** _- The controller shortcut for flashbag could in theory be removed now_
```php
class Controller
{
public function fooAction(Session $session)
{
$session->get(...);
$session->getFlashBag();
}
}
```
Commits
-------
b4464dcea1 Added the SessionValueResolver
* 3.2:
Revamped the README file
Fix missing namespace in AddConstraintValidatorPassTest
[SecurityBundle] simplified code
[ExpressionLanguage] Registering functions after calling evaluate(), compile() or parse() is not supported
* 2.8:
Revamped the README file
Fix missing namespace in AddConstraintValidatorPassTest
[ExpressionLanguage] Registering functions after calling evaluate(), compile() or parse() is not supported
* 2.7:
Revamped the README file
Fix missing namespace in AddConstraintValidatorPassTest
[ExpressionLanguage] Registering functions after calling evaluate(), compile() or parse() is not supported
This PR was squashed before being merged into the 2.7 branch (closes#21744).
Discussion
----------
Revamped the README file
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21235
| License | MIT
| Doc PR |
Here is a before/after comparison image:
![before-after-readme](https://cloud.githubusercontent.com/assets/73419/23294444/cb001e9a-fa6b-11e6-88f2-a8449470fb4e.png)
Commits
-------
c7d30ca486 Revamped the README file
This PR was merged into the 2.7 branch.
Discussion
----------
Fix missing namespace in test
| Q | A
| ------------- | ---
| Branch? | 2.7
| Tests pass? | yes
Commits
-------
1e9ca7b Fix missing namespace in AddConstraintValidatorPassTest
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Config] fixed glob file loader when there is an exception
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Fixes a typo. When importing a glob, we definitely want to have errors like syntax errors in a YAML file.
Commits
-------
d1b6601612 [Config] fixed glob file loader when there is an exception
This PR was merged into the 3.3-dev branch.
Discussion
----------
[SecurityBundle] Don't normalize username of in-memory users
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
It's common to have e.g. emails as keys in `security.providers.in_memory.users` since keys are username. Actually they are normalized so `foo-bar@gmail.com` becomes `foo_bar@gmail.com` and authentication fails unexpectedly.
Commits
-------
8d03332726 [SecurityBundle] Don't normalize keys of in-memory users
This PR was squashed before being merged into the 2.7 branch (closes#21722).
Discussion
----------
[ExpressionLanguage] Registering functions after calling evaluate(), compile() or parse() is not supported
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
If we add expr. function after first eval/compile like this:
```php
$el = new ExpressionLanguage();
$el->evaluate('1 + 1');
$el->addFunction(new ExpressionFunction('fn', function () {}, function () {}));
$el->evaluate('fn()');
```
A ``SyntaxError`` is thrown that says ``The function "fn" does not exist around position 1.``. It's the same bug with ``$el->compile('fn()')``.
This PR fixes this (duplicate of #21098 that was closed).
Commits
-------
e305369f98 [ExpressionLanguage] Registering functions after calling evaluate(), compile() or parse() is not supported
This PR was merged into the 2.7 branch.
Discussion
----------
[SecurityBundle] fix priority ordering of security voters
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21660
| License | MIT
| Doc PR |
Could be updated in the `3.2` branch to make use of the `PriorityTaggedServiceTrait `.
Commits
-------
dcd19f3cf9 fix priority ordering of security voters
This PR was merged into the 3.2 branch.
Discussion
----------
[DoctrineBridge] Fixed validating custom doctrine type columns
| Q | A
| ------------- | ---
| Branch? | 3.1
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21619
| License | MIT
| Doc PR | -
This fixes#21619 by not assuming the invalid `$value` is a Doctrine entity if its an object
Commits
-------
ad59370241 [DoctrineBridge] Fixed validating custom doctrine type columns
This PR was merged into the 2.7 branch.
Discussion
----------
Use PHPUnit 6.0 on PHP 7.* test lines
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | need #21694 first
| Fixed tickets | -
| License | MIT
| Doc PR | -
Commits
-------
96ecd3c Use PHPUnit 6.0 on PHP 7.* test lines
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Bridge/PhpUnit] Add PHPUnit 6 support
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21125
| License | MIT
| Doc PR | -
This PR makes our phpunit bridge compatible with all namespaced versions of phpunit, from 4.8.35 to 6.
It takes another approach than #21668 and #21221, thus replaces them.
Tested locally : tests pass when using phpunit 5.7, and fails with v6.0 because our own test suite is not yet compatible with it - but at least it runs nice.
If this were handled as usual Symfony component, we would consider some changes to be BC breaks. But in this specific case - a phpunit bridge - it makes no sense to me to apply the bc policy here. I added `@final` and `@internal` annotations to make this clearer.
Commits
-------
9e0745c [Bridge/PhpUnit] Add PHPUnit 6 support