This PR was merged into the 4.1-dev branch.
Discussion
----------
[DI][FrameworkBundle] Add PSR-11 "ContainerBag" to access parameters as-a-service
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #17160
| License | MIT
| Doc PR | -
There is one thing that prevents us from not injecting the container: access to the parameter bag.
This PR fixes this limitation by providing a PSR-11 `ContainerBagInterface` + related implementation, and wiring it as a service that ppl can then also autowire using the new interface as a type hint, or `ParameterBagInterface`.
Needed to complete e.g. #24738
Commits
-------
561cd7e Add tests on the ContainerBag
0e18d3e [DI][FrameworkBundle] Add PSR-11 "ContainerBag" to access parameters as-a-service
This PR was merged into the 4.1-dev branch.
Discussion
----------
[FrameworkBundle] debug:autowiring: don't list FQCN when they are aliased
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
In order to favor type-hinting for interfaces, I propose to not list the class as explicitly autowireable when an alias exists for it.
Which means displaying only
```
App\FooInterface
alias to App\Foo
```
instead of
```
App\Foo
App\FooInterface
alias to App\Foo
```
ping @weaverryan
Commits
-------
8cbfa1eaf3 [FrameworkBundle] debug:autowiring: don't list FQCN when they are aliased
This PR was squashed before being merged into the 4.1-dev branch (closes#24375).
Discussion
----------
[Serializer] Serialize and deserialize from abstract classes
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | Not yet
This PR adds a feature in the Serializer: allow to serialize and de-serialize abstract classes. Such feature is especially useful when dealing with domain objects.
# Example
Let's take the example of the following objects:
- `CodeRepository` defines a set of properties like `name` and `url`
- `GitHubCodeRepository` and `BitBucketCodeRepository` extends from the abstract `CodeRepository` class and adds a few properties.
- `Project` has a relation with a `codeRepository`, which has a type `CodeRepository`.
At the moment, the serializer can't serialize/deserialize correctly this `Project` object has it doesn't know how to deal with this `CodeRepository` abstract object.
This feature allows the serializer to deal with such situation. The `ObjectNormalizer` has now access to a `ClassDiscriminatorResolver` that knows, for a given abstract class:
- Is the "type" property it needs to read/write to uniquely identify each sub-class
- What's the name of the "type" for each sub-class mapping
# Usage without Framework Bundle
```php
$discriminatorResolver = new ClassDiscriminatorResolver();
$discriminatorResolver->addClassMapping(CodeRepository::class, new ClassDiscriminatorMapping('type', [
'github' => GitHubCodeRepository::class,
'bitbucket' => BitBucketCodeRepository::class,
]));
$serializer = new Serializer(array(new ObjectNormalizer(null, null, null, null, $discriminatorResolver)), array('json' => new JsonEncoder()));
$serialized = $serializer->serialize(new GitHubCodeRepository());
// {"type": "github"}
$repository = $serializer->unserialize($serialized, CodeRepository::class, 'json');
// GitHubCodeRepository
```
# Usage with the Framework Bundle
```yaml
framework:
serializer:
discriminator_class_mapping:
App\CodeRepository:
type_property: type
mapping:
github: App\GitHubCodeRepository
bitbucket: App\BitBucketCodeRepository
```
# Usage with Annotations/XML/YAML
```php
use Symfony\Component\Serializer\Annotation\DiscriminatorMap;
/**
* @DiscriminatorMap(typeProperty="type", mapping={
* "first"="Symfony\Component\Serializer\Tests\Fixtures\AbstractDummyFirstChild",
* "second"="Symfony\Component\Serializer\Tests\Fixtures\AbstractDummySecondChild"
* })
*/
abstract class AbstractDummy
{
public $foo;
public function __construct($foo = null)
{
$this->foo = $foo;
}
}
```
# TODO
- [x] Working as standalone
- [x] Working with the framework bundle
- [x] Tests on mapping classes
Commits
-------
4c6e05b7ee [Serializer] Serialize and deserialize from abstract classes
This PR was merged into the 4.1-dev branch.
Discussion
----------
[DoctrineBridge] DoctrineDataCollector comments the non runnable part of the query
| Q | A
| ------------- | ---
| Branch? | 4.1
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | #24782
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
![img_2932](https://user-images.githubusercontent.com/3451634/33648180-f6c7a5ac-da58-11e7-8bf8-95fc943d16ff.jpeg)
I think the idea in this ticket is good and it should be implemented. Could we go further by adding more things to this feature, or will it be ok to just comment out the un-needed part to make the kiri
![kiri](https://user-images.githubusercontent.com/3451634/33648278-5eccc830-da59-11e7-8034-a1b9efee7673.png)
(french joke for query) runnable ?
Commits
-------
42760d0d7f [DoctrineBridge] DoctrineDataCollector comments the non runnable part of the query
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Process] Create a "isTtySupported" static method
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | _none_
| License | MIT
| Doc PR | _none_
Currently, there is no way to enable the TTY mode without risking an exception. This PR extracts the code checking for TTY support and provides it in a `isTtySupported` static method.
Now we can enable the TTY mode everywhere it's available without risking an exception:
```php
$process = (new Process)->setTty(Process::isTtySupported());
```
_Old comment_:
> I'm targeting the 2.7 branch since this is not really a new feature, just a little refactoring of the existent code, and it is fully backward compatible.
Commits
-------
a1398f6de4 Create a "isTtySupported" static method
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Workflow] Introduce a Workflow interface
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #23910
| License | MIT
| Doc PR | todo
@chalasr I think all the points you made in 23910 has been done. Needs to update the docs too.
Commits
-------
e8351d8 [Workflow] Introduce a Workflow interface
* 4.0:
[Bridge/PhpUnit] Prefer ['argv'] over
[SecurityBundle] fix setLogoutOnUserChange calls for context listeners
[SecurityBundle] add note to info text of no-op config option logout_on_user_change
[DI] Register singly-implemented interfaces when doing PSR-4 discovery
Fix for missing whitespace control modifier in form layout
This PR was submitted for the master branch but it was squashed and merged into the 3.3 branch instead (closes#25304).
Discussion
----------
[Bridge/PhpUnit] Prefer $_SERVER['argv'] over $argv
| 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
This makes the script usable even if it is wrapped into another script, which is what some IDEs like PHPStorm do.
Commits
-------
1ff22e6acc [Bridge/PhpUnit] Prefer ['argv'] over
* 3.4:
[SecurityBundle] fix setLogoutOnUserChange calls for context listeners
[DI] Register singly-implemented interfaces when doing PSR-4 discovery
Fix for missing whitespace control modifier in form layout
This PR was merged into the 4.0 branch.
Discussion
----------
[SecurityBundle] add note to info text of no-op config logout_on_user_change
| Q | A
| ------------- | ---
| Branch? | 4.0
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
While discussing the "deprecation path" of the `logout_on_user_change` security option with @chalasr I got a bit confused.
- on 3.4 we added the option (default=false) and triggered a deprecation in case it's false
- on 4.0 the default became true **and the option is no-op** (does not change anything if its set to false)
- on 4.1 the option is additionally also deprecated
So maybe we should change the info text of the config node to mention that its effectively no-op since 4.0. WDYT?
Commits
-------
dec77f1 [SecurityBundle] add note to info text of no-op config option logout_on_user_change
This PR was squashed before being merged into the 3.4 branch (closes#25272).
Discussion
----------
[SecurityBundle] fix setLogoutOnUserChange calls for context listeners
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #25267
| License | MIT
| Doc PR | -
As pointed out in https://github.com/symfony/symfony/issues/25267 the `setLogoutOnUserChange` method calls were added to the parent definition `security.context_listener` instead of the concrete child definitions `security.context_listener.*`.
ping @iltar @chalasr
Commits
-------
4eff146 [SecurityBundle] fix setLogoutOnUserChange calls for context listeners
This PR was merged into the 3.4 branch.
Discussion
----------
[DI] Register singly-implemented interfaces when doing PSR-4 discovery
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I'm feeling bad for not having this idea before 3.4.0 went out, therefore submitting on 3.4, despite this being a new feature, technically. On a DX pov still, this is a bugfix :) I'll let you accept the argument or not...
So, when doing PSR-4-based service registration, we keep only classes as services.
This systematically leads to the question: "But what about interfaces, shouldn't we type-hint against abstractions and not classes?!"
And the answer has invariably been: "Well, just create an alias!"
Which means doing configuration manually.
I fear that if we leave things as is, we're going to grow a "generation" of devs that will hijack autowiring and abuse hinting for classes instead of interfaces.
BUT, here is the idea implemented by this PR: let's create an alias for every singly-implemented interface we discover while looking for classes!
Plain local, simple, and obvious, isn't it?
Votes pending :)
Commits
-------
fcd4aa7807 [DI] Register singly-implemented interfaces when doing PSR-4 discovery
* 4.0:
[Security] Adding a GuardAuthenticatorHandler alias
fixed tests
moved method to function
marked method as being internal
Disallow viewing dot-files in Profiler
* 3.4:
[Security] Adding a GuardAuthenticatorHandler alias
fixed tests
moved method to function
marked method as being internal
Disallow viewing dot-files in Profiler
This PR was submitted for the master branch but it was squashed and merged into the 3.4 branch instead (closes#25274).
Discussion
----------
[Security] Adding a GuardAuthenticatorHandler alias
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | kinda
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | This feature is not currently documented
The `security.authentication.guard_handler` service *is* actually meant to be available for users to use. Specifically, the `authenticateUserAndHandleSuccess()` method is useful to auto-login the user after, for example, registration, but maintain all the behavior of a normal login (success behavior, trigger the login event).
So, it should have an autowiring alias.
Commits
-------
844c402171 [Security] Adding a GuardAuthenticatorHandler alias
This PR was merged into the 3.3 branch.
Discussion
----------
[FrameworkBundle] Fix a bug where a color tag will be shown when passing an antislash
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #25193
| License | MIT
| Doc PR | none
You can see in the [reproducer](e6509ffcb4) when running `bin/console debug:container` that there an error in the ouput (like in the issue) when using a class with `\` in the service name.
This PR fix this wrong output. (even if that feels more developer thingy when there are xml everywhere ;)
Commits
-------
890edf7c38 [FrameworkBundle] Fix a bug where a color tag will be shown when passing an antislash
* 4.0:
[DI] Fix missing unset leading to false-positive circular ref
[DI] Fix deep-inlining of non-shared refs
parse newlines in quoted multiline strings
Fix collision between view properties and form fields
Fix collision between view properties and form fields
[SecurityBundle] Fix compat with HttpFoundation >=3.4
[DI] turn $private to protected in dumped container, to make cache:clear BC
Fix collision between view properties and form fields
* 3.4:
[DI] Fix missing unset leading to false-positive circular ref
[DI] Fix deep-inlining of non-shared refs
parse newlines in quoted multiline strings
Fix collision between view properties and form fields
Fix collision between view properties and form fields
[SecurityBundle] Fix compat with HttpFoundation >=3.4
Fix collision between view properties and form fields
This PR was merged into the 2.7 branch.
Discussion
----------
Fix for missing whitespace control modifier in form layout
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #25252
| License | MIT
| Doc PR | -
That single missing whitespace control modifier results in e.g. new line in `data-prototype` attribute when using CollectionType field type in form.
Commits
-------
369075a282 Fix for missing whitespace control modifier in form layout
This PR was merged into the 3.3 branch.
Discussion
----------
[WebProfiler] Disallow viewing dot-files in Profiler
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
The file viewer in the profiler should not open files that were specifically intended to be hidden, like specifically .env files, but similarly files like .htaccess that might expose server configuration knowledge.
Added tests validating both the new and old behavior.
Commits
-------
6a2f518e74 Disallow viewing dot-files in Profiler
This PR was merged into the 3.4 branch.
Discussion
----------
[Form][TwigBridge] Fix collision between view properties and form fields
| 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 | -
Require https://github.com/symfony/symfony/pull/25236 merged in 3.4
Commits
-------
c330965cfb Fix collision between view properties and form fields
This PR was merged into the 3.3 branch.
Discussion
----------
[Form][TwigBridge] Fix collision between view properties and form fields
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Require https://github.com/symfony/symfony/pull/25236 merged in 3.3
Commits
-------
888b48a89c Fix collision between view properties and form fields