This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Allow ~ instead of {} for services in Yaml
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Now we can omit the class name, Yaml config can look like this:
```yaml
services:
AppBundle\Something: {}
```
While this works, the consistent way in Symfony for such cases is to use `~`. This PR allows to use `~` as well, ending up with:
```yaml
services:
AppBundle\Something: ~
```
Commits
-------
28a1b5ac47 Allow setting services as null
This PR was merged into the 3.3-dev branch.
Discussion
----------
[SecurityBundle] removed usage of the templating component
| Q | A
| ------------- | ---
| Branch? | master
| 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
-------
17240eb7e8 [SecurityBundle] removed usage of the templating component
* 3.2:
[TwigBundle] fixed usage when Templating is not installed
[Validator] Check cascasdedGroups for being countable
[Cache] Add changelog for 3.2
[Cache] Add changelog
[Filesystem] Check that the directory is writable after created it in dumpFile()
[HttpFoundation] Improved set cookie header tests
[Serializer] int is valid when float is expected when deserializing JSON
[Console] increased code coverage of Output classes
Added missing headers in fixture files
[Profiler][VarDumper] Fix minor color issue & duplicated selector
* 3.1:
[TwigBundle] fixed usage when Templating is not installed
[Validator] Check cascasdedGroups for being countable
[Cache] Add changelog
[Filesystem] Check that the directory is writable after created it in dumpFile()
[HttpFoundation] Improved set cookie header tests
[Serializer] int is valid when float is expected when deserializing JSON
[Console] increased code coverage of Output classes
Added missing headers in fixture files
[Profiler][VarDumper] Fix minor color issue & duplicated selector
* 2.8:
[TwigBundle] fixed usage when Templating is not installed
[Validator] Check cascasdedGroups for being countable
[Filesystem] Check that the directory is writable after created it in dumpFile()
[HttpFoundation] Improved set cookie header tests
[Console] increased code coverage of Output classes
[Profiler][VarDumper] Fix minor color issue & duplicated selector
* 2.7:
[TwigBundle] fixed usage when Templating is not installed
[Validator] Check cascasdedGroups for being countable
[Filesystem] Check that the directory is writable after created it in dumpFile()
[HttpFoundation] Improved set cookie header tests
[Console] increased code coverage of Output classes
This PR was merged into the 2.7 branch.
Discussion
----------
[TwigBundle] fixed usage when Templating is not installed
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | bug introduced in #20799
| License | MIT
| Doc PR | n/a
In #20799, the decoupling of the Templating definition means that the `twig.loader.filesystem` is not always defined, but used in Extension. So, this PR does the opposite as what was done before. Use `twig.loader.native_filesystem` by default and copy paths to `twig.loader.filesystem` when templating is used.
/cc @xabbuh
Commits
-------
6aa98d163d [TwigBundle] fixed usage when Templating is not installed
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Filesystem] Add appendToFile()
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | todo
So we could append content to a file:
```php
(new Filesystem)->appendToFile($file, 'bar');
```
instead of doing it in two steps:
```php
if (false === $content = @file_get_contents($file)) {
throw new \Exception();
}
(new Filesystem)->dumpFile($file, $content.'bar');
```
Doing it opt-in using `dumpFile(..., $append = false)` would have been enough but not possible for BC.
Commits
-------
1f7b753670 [Filesystem] Add appendToFile()
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Filesystem] Add appendToFile()
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | todo
So we could append content to a file:
```php
(new Filesystem)->appendToFile($file, 'bar');
```
instead of doing it in two steps:
```php
if (false === $content = @file_get_contents($file)) {
throw new \Exception();
}
(new Filesystem)->dumpFile($file, $content.'bar');
```
Doing it opt-in using `dumpFile(..., $append = false)` would have been enough but not possible for BC.
Commits
-------
9fb5293122 [Filesystem] Add appendToFile()
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DependencyInjection] moved up ResolveClassPass in the container pass list
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | bug from #21133
| License | MIT
| Doc PR | n/a
Some compiler passes need access to the service class names. But when using an empty class name (the service id being the class name), the resolution happens too late (during the optimization step). This PR fixes this by moving up the ResolveClassPass earlier in the stack.
Commits
-------
2e5b69f8d8 [DependencyInjection] moved up ResolveClassPass in the container pass list
This PR was squashed before being merged into the 2.7 branch (closes#21155).
Discussion
----------
[Validator] Check cascasdedGroups for being countable
Prevents notice for PHP 7.2
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR |
Just repeated for this place https://github.com/symfony/symfony/pull/20859
Waiting travis to fill in the `Tests pass` field
`cascasdedGroups` can be null at this point (according to failures and phpdoc)
Commits
-------
8fa45a130b [Validator] Check cascasdedGroups for being countable
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Yaml] parse multi-line strings
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
When working on #21084, I discovered that the YAML parser does not support (unquoted) multi-line strings (neither as plain strings nor as values for mappings). This PR adds support for them.
Commits
-------
ec593b923b [Yaml] parse multi-line strings
This PR was merged into the 2.7 branch.
Discussion
----------
[Filesystem] Check that directory is writable after created it in dumpFile()
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/20612#discussion_r95077788
| License | MIT
| Doc PR | n/a
In case permissions have been changed meanwhile
Commits
-------
dbc4148535 [Filesystem] Check that the directory is writable after created it in dumpFile()
This PR was merged into the 3.3-dev branch.
Discussion
----------
[TwigBundle] Disable form in tests
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Tests are broken with high deps due to the changes made in #21196
> Symfony\Bundle\TwigBundle\Tests\NoTemplatingEntryTest::test
Symfony\Component\DependencyInjection\Exception\LogicException: Form support cannot be enabled as the Translation component is not installed.
> Symfony\Bundle\TwigBundle\Tests\NoTemplatingEntryTest::test
Symfony\Component\DependencyInjection\Exception\LogicException: The Validator component is required to use the Form component.
This will fix them.
Commits
-------
2a279b9 [TwigBundle] Disable form in tests
This PR was squashed before being merged into the 3.3-dev branch (closes#21196).
Discussion
----------
[FrameworkBundle] changed some default configs from canBeEnabled to canBeDisabled
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
FrameworkBundle configuration is currently "optimized" for when a project
depends on symfony/symfony (which is the vast majority of Symfony projects out
there as that's how Symfony Standard Edition is set up). As all components are
always available, features (forms, validation, translation, serializer, ...)
are disabled by default in FrameworkBundle's configuration (`canBeEnabled`) and
developers must enable them when they need them (that was done mainly for
performance reasons).
That's annoying as it means one configuration step before being able to use
forms for the first time (or validation, or serialization, or translation, ...).
To make features auto-configurable and make the framework a bit more
user-friendly (that's where I think I need to invoke DX :), I'd like Symfony 4
to work in a different way. Instead of relying on symfony/symfony, I want
people to install only the components/bundles they need. In that scenario, we
can auto-configure Symfony FrameworkBundle based on the available components.
If you add symfony/form as a dependency, then it makes sense to automatically
enable the feature in framework bundle (with the possibility to disable it if
needed thanks to `canBeDisabled`).
Let's recap:
* Before:
* You want to use forms; you have symfony/symfony, so nothing to install;
* Using forms does not work out of the box though; you need to know that you
have to edit `app/config/config.yml` to explicitly enable forms;
* Forms work!
* After:
* You want to use forms so you install symfony/form (like for any other
packages out there; want to use Twig for templating, install twig/twig);
* But for Symfony components, there are no other steps; forms are
auto-configured just because you installed the dependency, go work now!
In a way, it makes handling/installing/configuring Symfony components no
different than doing the same for a third party package. That's about relying
even more on Composer and less on configuration. Symfony components have the
extra benefit of being auto-configured via FrameworkBundle. That's not the case
for other third-party packages/bundles, but for those who attended SymfonyCon
Berlin, you know that this is coming soon via Symfony Flex.
That's even more interesting for forms as CSRF protection needs an extra knob
to be turned on currently. With the new way, just install the CSRF security
component. An again, you still have the possibility to turn it off if you want
to.
Anyway, this PR gives us the flexibility to do both: when using
symfony/symfony, everything works as before, if you are using
symfony/framework-bundle, then auto-configuration based on the installed
packages is automatically activated.
This also brings consistency as this behavior is already what we've done for
the Doctrine Annotation library in 3.2.
Last, but not the least, with all the work currently done on the container
lazyness for Symfony 3.3, concerns about performance are less important than
before, so having components auto-enabled when installed should not be a big
deal. We might even go one step further and remove enabling/disabling for
ESI/SSI/fragments/... And whenever we create an independent Session component,
we will be able to do the same with the session configuration. The astute
reader might have noticed that I haven't talked about the templating
configuration, but as the component will be deprecated in 3.3, I prefer to keep
its activation explicit.
In terms of BC, the only change is for people using symfony/framework-bundle
with some packages that were installed but not enabled in the config. I would
say that this should be pretty rare and anyway, the only consequence is a small
performance hit which can be easily offset by explicitly disabling the config.
That's all folks!
Commits
-------
ef80873d06 [FrameworkBundle] changed some default configs from canBeEnabled to canBeDisabled
98ce21a351 [FrameworkBundle] changed the default value of annotation setting based on the existence of Doctrine Annotations
This PR was merged into the 3.3-dev branch.
Discussion
----------
[EventDispatcher] Deprecate ContainerAwareEventDispatcher
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | no
| Fixed tickets | -
| License | MIT
| Doc PR | -
These methods shouldn't be available to end users.
Commits
-------
c4a6a8a47c [EventDispatcher] Deprecate ContainerAwareEventDispatcher
This PR was merged into the 3.3-dev branch.
Discussion
----------
[WebServerBundle] Decouple server commands from the container
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #20429
| License | MIT
| Doc PR | maybe
This removes the need for injecting the container in the new `server:*` commands, registering them as services when used in the framework and thus making them even more discoverable and extensible.
It would then be easy to reconsider extracting them in a `WebServer` component instead of having a bundle only. IMHO it would make sense to use these commands outside of the framework.
If the idea can be considered I'll add some tests at least ensuring that these commands are bootstrap-able. This must be done before that they are covered by the BC promise (3.3).
Commits
-------
2e63025e18 [WebServerBundle] Decouple server:* commands from the container
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Dont call get() when not required - µ-optim
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
(could be applied on 3.2, please advise)
Helps a bit on https://rawgit.com/kocsismate/php-di-container-benchmarks/master/var/benchmark.html
note: if we want more performance, we should consider deprecating case insensitivity of service identifiers.
Commits
-------
7a42199115 [DI] Dont call get() when not required - µ-optim
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Add "inherit-tags" with configurable defaults + same for "public", "tags" & "autowire"
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #20048
| License | MIT
| Doc PR | -
Instead of making services private by default (#20048), which is going to create a big migration burden that might not be worth it, I'd like to propose the idea of changing the default for the current file.
Having a place to redefine some defaults, this can also be used to enable autowiring for a file, making it much lighter in the end.
This PR handles defaults for "public", "autowired" and "tags". Not sure the other options need a configurable default. Please comment if you think otherwise.
Short example (the feat is more interesting with a longer list of services):
```yaml
services:
_defaults:
public: false
autowire: ['_construct', 'set*']
foo:
class: Foo
```
```xml
<?xml version="1.0" encoding="utf-8"?>
<container xmlns="http://symfony.com/schema/dic/services" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://symfony.com/schema/dic/serviceshttp://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<defaults public="false">
<autowire>__construct</autowire>
<tag name="foo"/>
</defaults>
</services>
</container>
```
ping @dunglas @weaverryan
Commits
-------
beec1cff8f [DI] Allow definitions to inherit tags from parent context
05f24d5a6d [DI] Add "defaults" tag to XML services configuration
7b4a18b044 [DI] Add "_defaults" key to Yaml services configuration
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Optional class for named services
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Continues #20264:
- makes the id-to-class mapping context-free (no `class_exist` check),
- deals with ChildDefinition (which should not have this rule applied on them),
- deprecates FactoryReturnTypePass as discussed on slack and reported in this comment: https://github.com/symfony/symfony/pull/19191#issuecomment-269949361
From @hason:
> I prefer class named services (in applications) because naming things are too hard:
``` yaml
services:
Vendor\Namespace\Class:
class: Vendor\Namespace\Class
autowire: true
```
> This PR solves redundant parameter for class:
``` yaml
services:
Vendor\Namespace\Class:
autowire: true
```
> Inspirations: https://laravel.com/docs/5.3/container, #18268, http://php-di.org/,
Commits
-------
a18c4b6ab2 [DI] Add tests for class named services
71b17c7790 [DI] Optional class for named services
This PR was merged into the 3.3-dev branch.
Discussion
----------
[WebServerBundle] Fix package type in composer.json
| Q | A
| ------------- | ---
| Branch? | master
Commits
-------
50baf256d5 [WebServerBundle] Fix package type in composer.json
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI][EventDispatcher] Add & wire closure-proxy argument type
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #12521, #12007, #20039
| License | MIT
| Doc PR | -
By resolving event subscribers at compile time, then wrapping listeners in a closure, we get laziness almost for free. This should solve/replaced all the above linked issues.
(WIP because tests are missing)
Commits
-------
ecdf857b61 [DI][EventDispatcher] Add & wire closure-proxy argument type