Also, not allowing arguments or method calls for autoconfigure. This is a safety
mechanism, since we don't have merging logic. It will allow us to add this in the
future if we want to.
The reason is that parent-child definitions are a different mechanism for "inheritance"
than instanceofConditionas and defaults... creating some edge cases when trying to
figure out which settings "win". For example:
Suppose a child and parent definitions are defined in different YAML files. The
child receives public: false from its _defaults, and the parent receives public: true
from its _defaults. Should the final child definition be public: true (so the parent
overrides the child, even though it only came from _defaults) or public: false (where
the child wins... even though it was only set from its _defaults). Or, if the parent
is explicitly set to public: true, should that override the public: false of the
child (which it got from its _defaults)? On one hand, the parent is being explicitly
set. On the other hand, the child is explicitly in a file settings _defaults public
to false. There's no correct answer.
There are also problems with instanceof. The importance goes:
defaults < instanceof < service definition
But how does parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.
This PR was squashed before being merged into the 3.3-dev branch (closes#22531).
Discussion
----------
Throwing an exception if the class is not found
| 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
We now throw an exception if the user makes a mistake with their PSR-4 prefix and namespace. For example:
```yml
AppBundle\Controller\:
resource: '../../src/AppBundle/{Controller}'
public: true
```
I should not have the `\Controller` at the end of the key. Previously, it would silently not import any services from the directory. Now it throws:
> Expected to find class "AppBundle\Controller\Controller\Admin\BlogController" in file "/path/to/project/src/AppBundle/Controller/Admin/BlogController.php" while importing services from resource "../../src/AppBundle/{Controller}", but it was not found! Check the namespace prefix used with the resource.
The only "downside" is that this prevents someone from importing files from a resource that has a file with no class in it (`functions.php`). @nicolas-grekas and I decided today that we can throw an exception now to be safe, and see if anyone has that valid use-case.
Cheers!
Commits
-------
e85bcc9 Throwing an exception if the class is not found
This PR was merged into the 3.3-dev branch.
Discussion
----------
[FrameworkBundle] Restore 3.2-like behavior for FormPass, to help BC with Sonata
| 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 | -
I tried updating a Sonata project to 3.3, and found it broken.
The issue is that Sonata uses the constructor arguments of the `form.extension` to create its own `form.extension` service - but borrows its first args from the Symfony one.
Here is the form pass doing that:
https://github.com/sonata-project/SonataCoreBundle/blob/3.x/DependencyInjection/Compiler/FormFactoryCompilerPass.php
And the implementation of the form extension:
https://github.com/sonata-project/SonataCoreBundle/blob/3.x/DependencyInjection/SonataCoreExtension.php
Question: is this covered by the BC policy? It shouldn't to me, because that would prevent *any* service reconfiguration.
Thus, I'm proposing the attached patch, which basically reverts the deprecated `FormPass` in FrameworkBundle to its 3.2 state.
I added a check to the new `FormPass` in the Form component so that it doesn't overwrite such compatibility configurations.
See for corresponding fix on https://github.com/sonata-project/SonataCoreBundle/pull/399
Commits
-------
c97b08e6c0 [FrameworkBundle] Restore 3.2-like behavior for FormPass, to help BC with Sonata
This PR was merged into the 2.7 branch.
Discussion
----------
[Asset] Preventing the base path or absolute URL from being prefixed incorrectly
| 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
Fixes an edge case (which I need) where the version strategy returns an absolute URL. Currently, if this happens, the baseUrl or basePath is prefixed - giving `https://baseurl.com/https://pathreturnedfromversioning.com` or `/basePath/https://pathreturnedfromversioning.com`.
I don't see any reason to prevent an absolute URL from being returned by the version strategy. And it's not a BC break, because the previous paths that were returned were nonsense.
Cheers!
Commits
-------
746c91eea4 Preventing the base path or absolute URL from being prefixed incorrectly on an absolute URL
* 3.2:
Fixed the flickering when loading complex profiler panels
[Console] Fix bar width with multilines ProgressBar's format
[DI] Add missing check in PhpDumper
[Serializer] XmlEncoder: fix negative int and large numbers handling
[Console] Fix dispatching throwables from ConsoleEvents::COMMAND
* 2.8:
Fixed the flickering when loading complex profiler panels
[DI] Add missing check in PhpDumper
[Serializer] XmlEncoder: fix negative int and large numbers handling
[Console] Fix dispatching throwables from ConsoleEvents::COMMAND
* 2.7:
[DI] Add missing check in PhpDumper
[Serializer] XmlEncoder: fix negative int and large numbers handling
[Console] Fix dispatching throwables from ConsoleEvents::COMMAND
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Console] Review console.ERROR related behavior
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR is a follow up of #18140 that I wanted to do since a few weeks.
It enhances this work with fixes and behavior changes.
It embeds #22435 and resolves issues like the one described in #20808.
- makes ConsoleErrorEvent *not* extend the deprecated ConsoleExceptionEvent
- replace ConsoleErrorEvent::markErrorAsHandled by ConsoleErrorEvent::setExitCode
- triggers the deprecation in a more appropriate moment
- renames ExceptionListener to ErrorListener
- tweaks the behavior in relation to #22435
Commits
-------
a7c67c9ab2 [Console] Review console.ERROR related behavior
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Cache] Keep only hit/miss (not values) in TraceableAdapter/Cache
| 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 | -
Right now, TraceableAdapter and TraceableCache both keep all fetched values.
This exhaustive reporting is too much data gathering to me.
Here is a PR that keeps only true/false for each hit/miss + all corresponding keys.
That can still be a lot of data (one item per fetched key) - but a bit better.
Should we go further in stats-only gathering? Or should we *not* do this and keep collecting *all* the values?
The PR also fixes "Traversable" handling.
ping @Nyholm
The profiler panel still works (although breaking lines in the middle of words is strange, but this is the profiler's CSS, nothing special to this specific case).
Commits
-------
0c73c5d [Cache] Keep only hit/miss (not values) in TraceableAdapter/Cache
This PR was squashed before being merged into the 3.2 branch (closes#21958).
Discussion
----------
[Console] Fix bar width with multilines ProgressBar's format
| 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 | -
The bar width is badly recalculated when we use multilines (``\n``) and bar placeholer (``%bar%``) in ProgressBar's format. The bar width is reduced because multilines is considered as a big oneline. This PR fixes this.
Commits
-------
3d58ab5bad [Console] Fix bar width with multilines ProgressBar's format
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Allow service subscribers to leverage autowiring to know where their locator should be injected
| 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 | -
Commits
-------
e407b3d42e [DI] Allow service subscribers to leverage autowiring to know where the locator should be injected
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Process] Fix BC break: "exec" should remain an internal "detail"
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22476
| License | MIT
| Doc PR | -
Commits
-------
eedcece20b [Process] Fix BC break: "exec" should remain an internal "detail"
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Fix inlining conflict by restricting IteratorArgument to Reference[]
| 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 | -
`Reference` found in `ArgumentInterface::getValue()` are currently not inlined.
While trying to do so (hint: I failed), I noticed that the current code is broken for `IteratorArgument` which can contain anonymous `Definition` for now, which are then not inlined correctly.
This PR restricts `IteratorArgument` to arrays of `Reference`, and improves a few related things found while doing it.
(fabbot failure is false positive)
Commits
-------
4d3dce1c0f [DI] Fix inlining conflict by restricting IteratorArgument to Reference[]
This PR was merged into the 2.7 branch.
Discussion
----------
[Serializer] XmlEncoder: fix negative int and large numbers handling
| Q | A
| ------------- | ---
| Branch? | 2.7 <!-- see comment below -->
| Bug fix? | yes
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | #22329, #22333 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | n/a
Alternative to #22333.
* Negative integers are now handled
* Float are now handled
* Large numbers are converted to float (as the `JsonEncoder` and native PHP functions like `ceil` do)
@vlastv, I've adapted your test. Can you check if it fixes your problem?
Commits
-------
1eeadb0c98 [Serializer] XmlEncoder: fix negative int and large numbers handling
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Security] Fix json_login default success/failure handling
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no (master only)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22483
| License | MIT
| Doc PR | n/a
This makes the `json_login` listener default configuration stateless oriented by:
- Not using the default (redirect based) failure handler, it returns a 401 (json) response containing the failure reason instead
- Not using the default (redirect based) success handler, just let the original request continue instead (reaching the targeted resource without being redirected).
- Setting `require_previous_session` to `false` by default (I have to set it on `form-login` each time I want it to be stateless)
- Removing the options related to redirections (`default_target_path`, `login_path`, ...) from the listener factory, if one wants redirections then one has to write its own handlers, not the inverse
Commits
-------
9749618ff5 Fix json_login default success/failure handling
This PR was squashed before being merged into the 3.3-dev branch (closes#22234).
Discussion
----------
[DI] Introducing autoconfigure: automatic _instanceof configuration
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes (mostly, a continuation of a new feature)
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/issues/7538
This is a proposal to allow the user to opt into some automatic `_instanceof` config. Suppose I want to auto-tag all of my voters and event subscribers
```yml
# current
services:
_defaults:
autowire: true
_instanceof:
Symfony\Component\Security\Core\Authorization\Voter\VoterInterface:
tags: [security.voter]
Symfony\Component\EventDispatcher\EventSubscriberInterface:
tags: [kernel.event_subscriber]
# services using the above tags
AppBundle\Security\PostVoter: ~
AppBundle\EventListener\CheckRequirementsSubscriber: ~
```
If I'm registering a service with a class that implements `VoterInterface`, when would I ever *not* want that to be tagged with `security.voter`? Here's the proposed code:
```yml
# proposed
services:
_defaults:
autowire: true
autoconfigure: true
# services using the auto_configure_instanceof functionality
AppBundle\Security\PostVoter: ~
AppBundle\EventListener\CheckRequirementsSubscriber: ~
```
The user must opt into this and it only applies locally to this configuration file. It works because each enabled bundle would have the opportunity to add one or more "automatic instanceof" definitions - e.g. SecurityBundle would add the `security.voter` instanceof config, FrameworkBundle would add the `kernel.event_subscriber` instanceof config, etc.
For another example, you can check out the proposed changes to `symfony-demo` - symfony/symfony-demo#483 - the `_instanceof` section is pretty heavy: 81694ac21e/app/config/services.yml (L20)
Thanks!
Commits
-------
18627bf9f6 [DI] Introducing autoconfigure: automatic _instanceof configuration
This PR was merged into the 3.3-dev branch.
Discussion
----------
Persist app bootstrapping logs for logger datacollector
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | yes
| BC breaks? | ?
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21405
| License | MIT
Logs generated during the container build are catched by the BufferingLogger with a special flag.
They are persist by the LoggerDataCollector and are available in the logger profiler.
In the profiler toolbar, the "container build" logs increment the current logs counter (even if the container was previously built).
<img width="540" alt="capture d ecran 2017-02-01 a 20 56 40" src="https://cloud.githubusercontent.com/assets/1017746/22523826/0bc12e4a-e8c1-11e6-830f-7f6238ea7423.png">
<img width="1022" alt="capture d ecran 2017-02-01 a 20 57 55" src="https://cloud.githubusercontent.com/assets/1017746/22523859/2c48a698-e8c1-11e6-9bdb-d85f3e692938.png">
The BufferingLogger now require the cachePath and the filesystem to persist a (unique) container build logs.
If the current workflow is ok, I will update the test coverage (actually they fail). Maybe we can display the appDevDebugProjectContainerCompiler.log content in that logger profile.
Commits
-------
2fd18b5503 [VarDumper] Fine tune dumping log messages
ce3ef6a96e Persist app bootstrapping logs for logger datacollector
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Console] Fix fatal error when logging console.error without command
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22449
| License | MIT
| Doc PR | n/a
Happens now that the console.error event is dispatched on command not found, I ran into using `server:run` on 3.3 without `web-server-bundle` enabled:
> PHP Fatal error: Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: Call to a member function getName() on null
In this case, this first tries to cast the event input as string (less good than when the command name is available, there're extra quotes around the command name) and, if can't be casted, uses a generic message.
Commits
-------
97129fc611 Fix fatal error when logging console.error without a command
* 3.2:
Make .travis.yml more readable
Fold Travis CI output by component
[VarDumper] Minor tweaks to html/css dumps
Add trhows PHPDoc in Application::run
[Debug] Set exit status to 255 on error
[HttpFoundation] Store IANA's RNG files in the repository
[PropertyInfo] Remove a useless call to count() in SerializerExtractor
[PropertyInfo] Prevent returning int values in some cases.
[HttpFoundation] Fix getClientIp @return docblock
Add @throws phpdoc
unify PHPUnit config files
* 2.8:
Make .travis.yml more readable
Fold Travis CI output by component
Add trhows PHPDoc in Application::run
[Debug] Set exit status to 255 on error
[HttpFoundation] Store IANA's RNG files in the repository
[PropertyInfo] Remove a useless call to count() in SerializerExtractor
[PropertyInfo] Prevent returning int values in some cases.
[HttpFoundation] Fix getClientIp @return docblock
Add @throws phpdoc
unify PHPUnit config files
* 2.7:
Make .travis.yml more readable
Fold Travis CI output by component
Add trhows PHPDoc in Application::run
[Debug] Set exit status to 255 on error
[HttpFoundation] Store IANA's RNG files in the repository
[HttpFoundation] Fix getClientIp @return docblock
Add @throws phpdoc
unify PHPUnit config files
This PR was squashed before being merged into the 3.3-dev branch (closes#22425).
Discussion
----------
[Security] Allow to set a check_path on json_login listener
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no, master only
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21948, ~~#22423~~
| License | MIT
| Doc PR | n/a
The listener should allow to restrict authentication to a given check_path, as stated in the docs http://symfony.com/doc/master/security/json_login_setup.html
Commits
-------
9f7eb618a4 [Security] Allow to set a check_path on json_login listener
