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
----------
[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
* 3.2:
[Bridge/PhpUnit] Relax expectedDeprecation for forward compat
[FrameworkBundle] Remove Response* from classes to compile
[Workflow] Removed twig from composer.json (dev section, not used)
This PR was merged into the 3.2 branch.
Discussion
----------
[Bridge/PhpUnit] Relax expectedDeprecation for forward compat
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Instead of a strict match, this makes the annotation check ignore not expected messages, while still requiring all the expected ones in order.
This is needed for forward compat with future deprecations, and should make travis green again.
Commits
-------
a3ba726 [Bridge/PhpUnit] Relax expectedDeprecation for forward compat
This PR was merged into the 3.2 branch.
Discussion
----------
[FrameworkBundle] Remove Response* from classes to compile
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #20560, https://github.com/symfony/symfony-demo/issues/411, https://github.com/FriendsOfSymfony/FOSHttpCacheBundle/issues/276
| License | MIT
| Doc PR | -
When HttpCache is used, Response is loaded first, then the kernel is booted (on cache miss), which triggers the loading of classes.php. Since 3.2 generates a context free classes.php, the Response class is now included there when it was excluded previously. And boom, "Cannot declare class Symfony\Component\HttpFoundation\Response".
Commits
-------
9ab59824a1 [FrameworkBundle] Remove Response* from classes to compile
This PR was squashed before being merged into the 2.7 branch (closes#20972).
Discussion
----------
[HttpFoundation] Improved set cookie header tests
| Q | A
| ------------- | ---
| Branch? | 2.7 (already in master)
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
Separated from #20569
Commits
-------
05bce71d7a [HttpFoundation] Improved set cookie header tests
This PR was squashed before being merged into the 3.3-dev branch (closes#20547).
Discussion
----------
[FrameworkBundle] Allowed symlinks when searching for translation, searialization and validation files
| 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 we have a symlink folder in app/Resources/translations, files inside this symlink are not handled.
Commits
-------
4874e43a4c [FrameworkBundle] Allowed symlinks when searching for translation, searialization and validation files
This PR was merged into the 3.3-dev branch.
Discussion
----------
Deprecate ClassCollectionLoader and Kernel::loadClassCache
| Q | A
| ------------- | ---
| Branch? | "master"
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #20668
| License | MIT
As suggested by @nicolas-grekas in #20668 I added deprecation notices to ClassCollectionLoader and Kernel::loadClassCache.
Commits
-------
660d79a186 Deprecates ClassCache-cache warmer.
This PR was squashed before being merged into the 3.1 branch (closes#21165).
Discussion
----------
[Serializer] int is valid when float is expected when deserializing JSON
| Q | A
| ------------- | ---
| Branch? | 3.1
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | api-platform/api-platform#37
| License | MIT
| Doc PR | n/a
JSON only has a Number type corresponding to both `int` and `float` PHP types.
PHP's `json_encode`, JavaScript's `JSON.stringify`, Go's `json.Marshal` as well as most other JSON encoders convert floating-point numbers like `12.0` to `12` (the decimal part is dropped when possible).
PHP's `json_decode` automatically converts Numbers without a decimal part to integers.
Actually, the Serializer rejects integers when a float is expected, this PR fixes this behavior when denormalizing JSON-based formats.
Port of api-platform/core#714.
/cc @gorghoa @Shine-neko
Commits
-------
4125455775 [Serializer] int is valid when float is expected when deserializing JSON
This PR was merged into the 3.3-dev branch.
Discussion
----------
[PhpUnitBridge] silence warnings on PHPUnit 4.8
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
The concept of warnings is only available since PHPUnit 5. We can later think about whether we need this for PHPUnit 4.8 to or if we should rather aim to drop PHPUnit 4.8 support in 4.0. For now, this change will make the test suite green again.
Commits
-------
2c3de10 silence warnings on PHPUnit 4.8
This PR was squashed before being merged into the 2.7 branch (closes#21124).
Discussion
----------
[Console] increased code coverage of Output classes
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
This PR increases the coverage of Output classes of the Console component from 80.81% to 94.95%
Commits
-------
ab4ba23 [Console] increased code coverage of Output classes
This PR was merged into the 3.3-dev branch.
Discussion
----------
No fallback to REQUEST_TIME in TimeDataCollector
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no (?)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
As of PHP 5.4 the `REQUEST_TIME_FLOAT` is available and the minimum version of PHP is 5.5 in Symfony. I think it's safe to use as I can't find cases where this is _not_ defined.
Commits
-------
ba00543 No fallback to REQUEST_TIME in TimeDataCollector
This PR was merged into the 3.3-dev branch.
Discussion
----------
[PhpUnitBridge] deprecate the testLegacy test name prefix
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #18755
| License | MIT
| Doc PR |
Commits
-------
21b72dd deprecate the Legacy/testLegacy test name prefix
This PR was merged into the 2.8 branch.
Discussion
----------
[Profiler][VarDumper] Fix minor color issue & duplicated selector
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
While working on #21109, I spotted this minor issue with `sf-dump-const` and `.sf-dump-ref`:
| Before | After |
| --- | --- |
|<img width="276" alt="screenshot 2017-01-03 a 20 13 55" src="https://cloud.githubusercontent.com/assets/2211145/21619779/7e1e347e-d1f1-11e6-9d84-fbb1d5d6b1fa.PNG">| <img width="275" alt="screenshot 2017-01-03 a 20 14 04" src="https://cloud.githubusercontent.com/assets/2211145/21619786/86dde5dc-d1f1-11e6-8b13-dcfc5abe466a.PNG">|
Commits
-------
b282076 [Profiler][VarDumper] Fix minor color issue & duplicated selector
This PR was squashed before being merged into the 3.3-dev branch (closes#21039).
Discussion
----------
Web server bundle
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21040
| License | MIT
| Doc PR | n/a
Moved the `server:*` commands to a new bundle. It makes them more easily discoverable and more decoupled. Discoverability is important when not using symfony/symfony. In that case, the commands are not available unless you have the symfony/process component installed. With a dedicated bundle, installing the bundle also installs the dependency, making the whole process easier.
Usage is the same as the current commands for basic usage:
To start a web server in the foreground:
```
bin/console server:run
```
To manage a background server:
```
bin/console server:start
bin/console server:stop
bin/console server:status
```
The big difference is that port is auto-determined if something is already listening on port 8000.
Usage is **different** if you pass options:
```
bin/console server:start 127.0.0.1:8888
bin/console server:stop # no need to pass the address again
bin/console server:status # no need to pass the address again
```
That's possible as the web server now stores its address in a pid file stored in the current directory.
Commits
-------
f39b32735b [WebServerBundle] switched auto-run of server:start to off by default
961d1cea55 [WebServerBundle] fixed server:start when already running
126f4d9ec4 [WebServerBundle] added support for port auto-detection
6f689d6597 [WebServerBundle] changed the way we keep track of the web server
585d4451c8 [WebServerBundle] tweaked command docs
fa7ebc57de [WebServerBundle] moved most of the logic in a new class
951a1a227d [WebServerBundle] changed wording
ac1ba7700e made the router configurable via env vars
48dd2b0dbe removed obsolete check
132902c621 moved server:* command to a new bundle
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DependencyInjection] Implement lazy collection type using generators
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | -
| Fixed tickets | #20875
| License | MIT
| Doc PR | -
Following the RFC https://github.com/symfony/symfony/issues/20875, this PR aims to implement lazy services collections using generators internally.
For now, I suggest to support only XML and PHP definitions. Supporting YAML means adding another convention to the language and this is not the aim of this PR.
- [x] value object holding the semantic (IteratorArgument)
- [x] iterator dumping
- [x] lazyness awareness in CheckCircularReferencesPass & GraphvizDumper
- [x] rewindable iterators
- [x] `*_ON_INVALID_REFERENCE` behavior
- [x] ContainerBuilder::createService
- [x] ArgumentInterface handling in compiler passes
Commits
-------
1dbf52ad03 [DI] Add "=iterator" arguments to Yaml loader
5313943692 [DependencyInjection] Implement lazy collection type using generators
* 3.2:
[Cache] Remove silenced warning tiggered by PhpArrayAdapter
[Cache] Fix order of writes in ChainAdapter
[Console] Fix return type in Terminal docblocks
This PR was merged into the 3.2 branch.
Discussion
----------
[Cache] Remove silenced warning tiggered by PhpArrayAdapter
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Because many reported this silenced warning, which happens all the time unless `cache:warmup` has been run.
Commits
-------
a9dfcd8 [Cache] Remove silenced warning tiggered by PhpArrayAdapter
This PR was merged into the 3.2 branch.
Discussion
----------
[Console] Fix return type in Terminal docblocks
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
This PR updates the docblock to reflect what's already in the code.
Commits
-------
6afb0afa24 [Console] Fix return type in Terminal docblocks
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Console] Show hidden commands in json & xml descriptors
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no (may be considered, but as hidden commands did not exist before 3.2, looks more like a behavior change, hence a feature)
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/pull/20866#issuecomment-266678895
| License | MIT
| Doc PR | N/A
Commits
-------
b6cf240ab5 [Console] Show hidden commands in json & xml descriptors
This PR was merged into the 3.2 branch.
Discussion
----------
[DependencyInjection] Fix the priority order of compiler pass trait
| Q | A
| ------------- | ---
| Branch? | 3.2
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #20332, #20993
| License | MIT
| Doc PR | ~
A regression has appeared between the version `3.1` and `3.2` on the compilation passes using a priority option (see #20332).
Indeed, the order is no longer preserved for service definitions with the same priority. This is caused by the `SplPriorityQueue` class that does not have a FIFO implementation (see this [comment](https://github.com/symfony/symfony/issues/20332#issuecomment-268096527)).
The PR #20993 fixes the problem but only for Forms, not for all compiler passes using the `PriorityTaggedServiceTrait` trait since `3.2`.
Commits
-------
aac9a7e Fix the priority order of compiler pass trait
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] use authenticated token for json authentication
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21123
| License | MIT
| Doc PR | N/A
When using `UsernamePasswordJsonAuthenticationListener` with [LexikJWTAuthenticationBundle](https://github.com/lexik/LexikJWTAuthenticationBundle), we get a type exception
> Type error: Argument 1 passed to Lexik\Bundle\JWTAuthenticationBundle\Security\Http\Authentication\AuthenticationSuccessHandler::handleAuthenticationSuccess() must implement interface Symfony\Component\Security\Core\User\UserInterface, string given, called in .../vendor/lexik/jwt-authentication-bundle/Security/Http/Authentication/AuthenticationSuccessHandler.php on line 47
This error occurs because the `UsernamePasswordJsonAuthenticationListener` send to the authentication success handler the token which have the user as a string and not the authenticated one that have a UserInterface as user.
Commits
-------
208c617716 use authenticated token for json authentication
This PR was squashed before being merged into the 3.3-dev branch (closes#21088).
Discussion
----------
Rename DebugAccessDecisionManager to TraceableAccessDecisionManager
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21085
| License | MIT
[EDIT] No longer WIP, test passing. Also, test added to preserve BC with the SecurityBundle.
Commits
-------
c5e0e59 Rename DebugAccessDecisionManager to TraceableAccessDecisionManager
