* 2.0:
[DependencyInjection] fixed the creation of synthetic services in ContainerBuilder
[Security] PHPDoc in SecurityEvents
[FrameworkBundle] fixed Client::doRequest that must call its parent method (closes#6737)
[Yaml] fixed ignored text when parsing an inlined mapping or sequence (closes#6786)
[Yaml] fixed#6773
[Yaml] fixed#6770
bumped Symfony version to 2.0.23-DEV
Conflicts:
src/Symfony/Component/DependencyInjection/ContainerBuilder.php
src/Symfony/Component/HttpKernel/Kernel.php
src/Symfony/Component/Yaml/Inline.php
src/Symfony/Component/Yaml/Tests/InlineTest.php
As explained in #6775, this has been done for the following reasons:
1. It's also Request::getHost()
2. The term hostname has been obsoleted in
http://tools.ietf.org/html/rfc3986#appendix-D.2 and uses the host only
3. hostname in the RFC was defined as the registered domain name, but we
probably also want to match IP-Adresses with the pattern which is the
host = IP-literal / IPv4address / reg-name for.
This PR was merged into the master branch.
Commits
-------
d5e73e5 [SecurityBundle] changed includes to use the new Twig notation
Discussion
----------
[SecurityBundle] changed includes to use the new Twig notation
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no - couple of unrelated failures
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
* 2.1:
[Yaml] fixed default value
Added Yaml\Dumper::setIndentation() method to allow a custom indentation level of nested nodes.
added a way to enable/disable object support when parsing/dumping
added a way to enable/disable PHP support when parsing a YAML input via Yaml::parse()
fixed CS
[Process] Fix docblocks, remove `return` from `PhpProcess#start()` as parent returns nothing, cleaned up `ExecutableFinder`
fixes a bug when output/error output contains a % character
[Console] fixed input bug when the value of an option is empty (closes#6649, closes#6689)
[Profiler] [Redis] Fix sort of profiler rows.
Fix version_compare() calls for PHP 5.5.
Removed underscores from test method names to be consistent with other components.
[Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)
Fix version_compare() calls for PHP 5.5.
Handle the deprecation of IntlDateFormatter::setTimeZoneId() in PHP 5.5.
removed the .gitattributes files (closes#6605, reverts #5674)
[HttpKernel] Clarify misleading comment in ExceptionListener
Conflicts:
src/Symfony/Bundle/WebProfilerBundle/Resources/views/Profiler/toolbar_style.html.twig
src/Symfony/Component/Form/Tests/Extension/Core/Type/DateTimeTypeTest.php
src/Symfony/Component/Form/Tests/Extension/Core/Type/TimeTypeTest.php
src/Symfony/Component/Form/Tests/Util/PropertyPathTest.php
src/Symfony/Component/HttpKernel/Profiler/RedisProfilerStorage.php
src/Symfony/Component/Process/Process.php
This PR was merged into the master branch.
Commits
-------
9fc7def added the UPGRADE file for Symfony 3.0
e84cad2 [Routing] updated CHANGELOG
65eca8a [Routing] added new schemes and methods options to the annotation loader
5082994 [Routing] renamed pattern to path
b357caf [Routing] renamed hostname pattern to just hostname
e803f46 made schemes and methods available in XmlFileLoader
d374e70 made schemes and methods available in YamlFileLoader
2834e7e added scheme and method setter in RouteCollection
10183de make scheme and method requirements first-class citizen in Route
Discussion
----------
Routing options
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #5989, #5990, #6049
| License | MIT
In #5989, it has unanimously been decided to renamed `hostname_pattern` to `hostname` and `pattern` to `path`. That makes a lot of sense and I would like to do the renaming now as `hostname_pattern` is new in Symfony 2.2, so I'd like to avoid breaking BC just after the release. As we are modifying the route options, I've also included changes introduced by @Tobion in #6049 which were discussed in #5990.
As everything is BC, I think it's wise to include that in 2.2. What do you think?
---------------------------------------------------------------------------
by Tobion at 2013-01-14T18:25:53Z
I agree it should be done in 2.2. Thanks for working on it.
---------------------------------------------------------------------------
by vicb at 2013-01-14T23:11:12Z
@fabpot "Everything is BC" until it breaks BC in 3.0, that's why I'd like to see [deprecations in PR summary](https://github.com/symfony/symfony-docs/pull/2116) what do you think ?
---------------------------------------------------------------------------
by vicb at 2013-01-14T23:16:40Z
it would also be great to update the CHANGELOG with deprecations (it could also help people answering your question)
---------------------------------------------------------------------------
by fabpot at 2013-01-15T07:07:03Z
@vicb: I've just updated the CHANGELOG and created the UPGRADE file for 3.0.
---------------------------------------------------------------------------
by vicb at 2013-01-15T07:15:32Z
@fabpot thanks.
This PR was merged into the master branch.
Commits
-------
76fefe3 updated CHANGELOG and UPGRADE files
f7da1f0 added some unit tests (and fixed some bugs)
f17f586 moved the container aware HTTP kernel to the HttpKernel component
2eea768 moved the deprecation logic calls outside the new HttpContentRenderer class
bd102c5 made the content renderer work even when ESI is disabled or when no templating engine is available (the latter being mostly useful when testing)
a8ea4e4 [FrameworkBundle] deprecated HttpKernel::forward() (it is only used once now and not part of any interface anyway)
1240690 [HttpKernel] made the strategy a regular parameter in HttpContentRenderer::render()
adc067e [FrameworkBundle] made some services private
1f1392d [HttpKernel] simplified and enhanced code managing the hinclude strategy
403bb06 [HttpKernel] added missing phpdoc and tweaked existing ones
892f00f [HttpKernel] added a URL signer mechanism for hincludes
a0c49c3 [TwigBridge] added a render_* function to ease usage of custom rendering strategies
9aaceb1 moved the logic from HttpKernel in FrameworkBundle to the HttpKernel component
Discussion
----------
[WIP] Kernel refactor
Currently, the handling of sub-requests (including ESI and hinclude) is mostly done in FrameworkBundle. It makes these important features harder to implement for people using only HttpKernel (like Drupal and Silex for instance).
This PR moves the code to HttpKernel instead. The code has also been refactored to allow easier integration of other rendering strategies (refs #6108).
The internal route has been re-introduced but it can only be used for trusted IPs (so for the internal rendering which is managed by Symfony itself, or by a trusted reverse proxy like Varnish for ESI handling). For the hinclude strategy, when using a controller, the URL is automatically signed (see #6463).
The usage of a listener instead of a controller to handle internal sub-requests speeds up things quite a lot as it saves one sub-request handling. In Symfony 2.0 and 2.1, the handling of a sub-request actually creates two sub-requests.
Rendering a sub-request from a controller can be done with the following code:
```jinja
{# default strategy #}
{{ render(path("partial")) }}
{{ render(controller("SomeBundle:Controller:partial")) }}
{# ESI strategy #}
{{ render(path("partial"), { strategy: 'esi' }) }}
{{ render(controller("SomeBundle:Controller:partial"), { strategy: 'esi' }) }}
{# hinclude strategy #}
{{ render(path("default1"), { strategy: 'hinclude' }) }}
```
The second commit allows to simplify the calls a little bit thanks to some nice syntactic sugar:
```jinja
{# default strategy #}
{{ render(path("partial")) }}
{{ render(controller("SomeBundle:Controller:partial")) }}
{# ESI strategy #}
{{ render_esi(path("partial")) }}
{{ render_esi(controller("SomeBundle:Controller:partial")) }}
{# hinclude strategy #}
{{ render_hinclude(path("default1")) }}
```
---------------------------------------------------------------------------
by fabpot at 2013-01-03T17:58:49Z
I've just pushed a new version of the code that actually works in my browser (but I've not yet written any unit tests). I've updated the PR description accordingly.
All comments welcome!
---------------------------------------------------------------------------
by Koc at 2013-01-03T20:11:43Z
what about `render(controller="SomeBundle:Controller:partial", strategy="esi")`?
---------------------------------------------------------------------------
by stof at 2013-01-04T09:01:01Z
shouldn't we have interfaces for the UriSigner and the HttpContentRenderer ?
---------------------------------------------------------------------------
by lsmith77 at 2013-01-04T19:28:09Z
btw .. as mentioned in #6213 i think it would make sense to refactor the HttpCache to use a cache layer to allow more flexibility in where to cache the data (including clustering) and better invalidation. as such if you are refactoring HttpKernel .. it might also make sense to explore splitting off HttpCache.
---------------------------------------------------------------------------
by fabpot at 2013-01-04T19:30:07Z
@lsmith77 This is a totally different topic. This PR is just about moving things from FrameworkBundle to HttpKernel to make them more reusable outside of the full-stack framework.
---------------------------------------------------------------------------
by fabpot at 2013-01-05T09:39:52Z
I think this PR is almost ready now. I still need to update the docs and add some unit tests. Any other comments on the whole approach? The class names? The `controller` function thingy? The URI signer mechanism? The proxy protection for the internal controller? The proxy to handle internal routes?
---------------------------------------------------------------------------
by sstok at 2013-01-05T10:08:25Z
Looks good to me 👍
---------------------------------------------------------------------------
by sdboyer at 2013-01-07T18:17:08Z
@Crell asked me to weigh in, since i'm one of the Drupal folks who's likely to work most with this.
i think i've grokked about 60% of the big picture here, and i'm generally happy with what i see. the assumption that the HInclude strategy makes about working with templates probably isn't one that we'll be able to use (and so, would need to write our own), but that's not a big deal since the whole goal here is to make strategies pluggable.
so, yeah. +1.
---------------------------------------------------------------------------
by winzou at 2013-01-09T20:21:44Z
Just for my information: will this PR be merged for 2.2 version? Thanks.
---------------------------------------------------------------------------
by stof at 2013-01-09T20:41:04Z
@winzou according to the blog post announcing the beta 1 release, yes. It is explicitly listed as being one of the reason to make it a beta instead of the first RC.
---------------------------------------------------------------------------
by winzou at 2013-01-09T20:49:36Z
OK thanks, I've totally skipped this blog post.
---------------------------------------------------------------------------
by fabpot at 2013-01-10T15:26:15Z
I've just added a bunch of unit tests and fix some bugs I found while writing the tests.
This PR was merged into the master branch.
Commits
-------
6b1652e [PropertyAccess] Property path, small refactoring, read/writeProperty to read/write Property/Index.
1bae7b2 [PropertyAccess] Extracted PropertyAccess component out of Form
Discussion
----------
[PropertyAccess] Extracted PropertyAccess component out of Form
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
TODO: adapt DoctrineBundle/PropelBundle to pass the "property_accessor" service to EntityType/ModelType
Usage:
```php
$accessor = PropertyAccess::getPropertyAccessor();
// equivalent to $object->getFoo()->setBar('value')
$accessor->setValue($object, 'foo.bar', 'value');
// equivalent to $object->getFoo()->getBar()
$accessor->getValue($object, 'foo.bar');
// equivalent to $object->getFoo()['bar']
$accessor->getValue($object, 'foo[bar]');
// equivalent to $array['foo']->setBar('value')
$accessor->setValue($array, '[foo].bar', 'value');
// equivalent to $array['foo']['bar']
$accessor->getValue($array, '[foo][bar]');
```
Later on, once we have generation and caching of class-specific accessors, configuration will be something like this (consistent with the Form and Validator component):
```php
$accessor = PropertyAccess::getPropertyAccessorBuilder()
->setCacheDirectory(__DIR__ . '/cache')
->setCacheLifeTime(86400)
->enableMagicGetSet()
->enableMagicCall()
->getPropertyAccessor();
```
or
```php
$accessor = PropertyAccess::getPropertyAccessorBuilder()
->setCache($cache)
->getPropertyAccessor();
```
etc.
---------------------------------------------------------------------------
by Burgov at 2013-01-07T08:48:15Z
+1. I use this feature outside of the Form context a lot
---------------------------------------------------------------------------
by stof at 2013-01-07T08:49:34Z
The classes in the Form component should be kept for BC (and deprecated) for people using the feature
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T10:02:19Z
YES YES YES 👍. Sorry for my enthusiasm, but I already copy pasted the PropertyPath class to some of my libraries to avoid linking to the whole Form component. I thus will be glad to officially use this component into my libraries via composer.
---------------------------------------------------------------------------
by norzechowicz at 2013-01-07T10:17:39Z
Same as @michelsalib to avoid linking full Form component I was using copied parts of code. Can't wait to use this component in my lib. 👍
---------------------------------------------------------------------------
by bschussek at 2013-01-07T10:43:41Z
I split away `getValue()` and `setValue()` from `PropertyPath` into a new class `ReflectionGraph`. The component is also named ReflectionGraph now.
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T10:47:10Z
I am not found of the name. What do you intend to do in the component more than what PropertyPath does ?
---------------------------------------------------------------------------
by bschussek at 2013-01-07T10:58:59Z
@michelsalib A `PropertyPath` is simply a string like `foo.bar[baz]`. `getValue()` and `setValue()` interpret this path. There may be different interpretations for the same path, so these methods were split into a new class.
I chose the name `ReflectionGraph` because the functionality is very similar to `ReflectionProperty`.
```php
$reflProperty = new ReflectionProperty('Vendor/Class', 'property');
$reflProperty->setValue($object, 'foo');
$reflGraph = new ReflectionGraph();
$reflGraph->setValue($object, 'property.path', 'foo');
```
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T11:00:42Z
What about naming it `Reflection`, maybe sometime we will want to add more reflection tools for classes, interfaces... ?
---------------------------------------------------------------------------
by bschussek at 2013-01-07T11:02:32Z
@michelsalib I doubt that we will do that. PHP's implementation is sufficient.
---------------------------------------------------------------------------
by vicb at 2013-01-07T11:03:57Z
> Backwards compatibility break: no
Really ?
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T11:05:07Z
Well, that is just a suggestion. If I am the only one to oppose, I won't complain.
---------------------------------------------------------------------------
by bschussek at 2013-01-07T11:09:08Z
> Really ?
@vicb Would you please refrain from such meanginless comments in the future? I'm getting a bit tired of them. If you think that BC is broken somewhere, tell me where so that I can fix it.
---------------------------------------------------------------------------
by stof at 2013-01-07T11:09:43Z
@vicb There is no BC break as he kept deprecated classes for BC
---------------------------------------------------------------------------
by norzechowicz at 2013-01-07T11:13:12Z
@bschussek what do you think about some kind of factory for Reflection? This will prevent creating new Reflection objects each time you want to access properties values.
---------------------------------------------------------------------------
by vicb at 2013-01-07T11:18:47Z
@bschussek my point is that my comment is no more meaningless than closing #6453 because it will break BC.We could also keep BC by extending the classes in the new ns but in both cases BC will ultimately be broken (when the legacy classes are removed)
---------------------------------------------------------------------------
by vicb at 2013-01-07T12:23:45Z
@bschussek @stof I think that modifying the constructor signatures of `EntityChoiceList`, `FormType` are BC breaks (this is not an exhaustive list)
---------------------------------------------------------------------------
by bschussek at 2013-01-07T12:35:13Z
@vicb You are right. I added corresponding entries to the CHANGELOG and adapted the above description.
---------------------------------------------------------------------------
by vicb at 2013-01-08T13:39:13Z
@bschussek looking at this PR, I was wondering if an alternate syntax would make sense:
```php
<?php
$reflGraph = new ReflectionGraph($object);
// equivalent to $object->getFoo()->setBar('value')
$reflGraph['foo.bar'] = 'value';
// equivalent to $object->getFoo()->getBar()
$reflGraph['foo.bar'];
```
_Sorry for the off topic_
---------------------------------------------------------------------------
by vicb at 2013-01-08T13:49:46Z
The advantage of using such a `ReflectionGraph` factory is that it might be easier to return specialized reflection graphs, ie optimized instances (that would be cached).
---------------------------------------------------------------------------
by Toflar at 2013-01-08T14:49:54Z
I was also puzzled by the fact that there will be many `ReflectionGraph` instances although they don't have to. I'm with @vicb and I'd also vote for using the constructor to set the subject you're working on. Otherwise you'll repeat yourself over and over again by passing the subject - say `$object` - to `getValue()` or `setValue()`. If however you don't like the constructor thing then why do we have to have an instance of `ReflectionGraph` rather than just go for static methods and use `ReflectionGraph::getValue()` and `ReflectionGraph::setValue()`?
In my opinion there are a few methods that could be static anyway (especially some private ones) :)
But probably I misunderstood something as I'm just about to discover the SF components and don't have any experience working with them (so basically I just read the PR because of @bschussek's tweet :D)
Couldn't come up with any intuitive name for the component though :(
Generally when we talk about "getting" and "setting" values we call those things "mutators"...so `GraphMutator` might be more intuitive than the word `Reflection` :)
---------------------------------------------------------------------------
by Taluu at 2013-01-08T14:57:42Z
I like the last proposition made by @vicb (implementing `ArrayAccess` on `ReflectionGraph` - or whatever name will be chosen (`PathMutator` for example :D), and also specify which object should be worked on in the constructor rather than in each method).
Would this also be used in the `Validator` component ?
---------------------------------------------------------------------------
by stof at 2013-01-08T15:16:12Z
@Toflar A static ``ReflectionGraph::getValue()`` means you have a coupling to the implementation (as with any static call). The current implementation allows you to replace it with your own implementation as long as you implement the interface as it follows the DI pattern (as done in other places in Symfony).
@vicb The issue with ``$reflGraph = new ReflectionGraph($object);`` is that you cannot inject the ReflectionGraph anymore, as you need a new one each time. This would mean adding a ``ReflectionGraphFactory`` to be injected (and which could then be replaced by a factory using code generation). Using the constructor directly would not allow using a replacement based on code generation later. So the resulting code would more likely be
```php
$reflGraph = new ReflectionGraph();
$mutator = $reflGraph->getMutator($object);
// equivalent to $object->getFoo()->setBar('value')
$mutator['foo.bar'] = 'value';
// equivalent to $object->getFoo()->getBar()
$mutator['foo.bar'];
```
Btw, writing this, I find the naming Mutator suggested by @Taluu good when it concerns the setter, but quite weird when getting the value.
---------------------------------------------------------------------------
by Taluu at 2013-01-08T15:21:00Z
I was not the one to suggest though, it was @everzet. But then something like `PathAccessor`, as it is both a mutator and a getter ? I also like @stof suggestion, still in the idea of avoiding to have to put the object as an argument and also allowing to use an `ArrayAccess` interface..
---------------------------------------------------------------------------
by vicb at 2013-01-08T15:21:54Z
@stof your remark makes sense.
What about `Accessor`, the benefit being that it might well be the name of a coming PHP feature: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
---------------------------------------------------------------------------
by everzet at 2013-01-08T15:27:02Z
```php
$manager = new PropertyManager(new PropertyPath());
$num = $manager->getValue($object, 'foo.num');
$manager->setValue($object, 'foo.num', $num + 1);
$objectManager = new ObjectPropertyManager($object[, $manager]);
$num = $objectManager->getValue('foo.num');
$objectManager->setValue('foo.num', $num + 1);
$objectManager['foo.num'] += 1;
```
---------------------------------------------------------------------------
by bschussek at 2013-01-08T15:28:01Z
It might be me, but I don't like `ArrayAccess` to be misused for features like that. If I access a key in an array access structure, I expect it to be something like a collection, an associative array or a key value store. This class is neither.
Putting that aside, an accessor for a specific object might make sense, but I'm not sure about that yet.
```php
$reflObject->setValue('foo.bar', 'value');
$reflObject->getValue('foo.bar');
```
---------------------------------------------------------------------------
by stof at 2013-01-08T15:28:52Z
@vicb I would vote for PathAccessor then, as we are not doing simple accessor but accessors through a path in an object graph.
In my snippet above, we would then have a ReflectionGraph instance and a PathAccessor instance (``$mutator``).
Btw, I would also keep the methods ``setValue`` and ``getValue``. I find it more clear.
---------------------------------------------------------------------------
by bschussek at 2013-01-08T15:32:07Z
@stof But then we're rather left with the question of ReflectionGraph **vs.** PathAccessor. I don't think that the tiny interface difference (one global, one object-based) justifies the big naming difference.
---------------------------------------------------------------------------
by vicb at 2013-01-08T15:33:24Z
> This class is neither.
It might be `$pa['foo.bar[baz]'] = $pa['foo.bar']['baz'];` I don't know if it would help though.
---------------------------------------------------------------------------
by stof at 2013-01-08T15:35:51Z
@bschussek In my suggestion, ``ReflectionGraph`` is a factory for the PathAccessor objects. It is not accessing anymore itself (which would probably continue to cause issues to implement it with code generation). But the naming could indeed be changed to something else.
This PR was merged into the master branch.
Commits
-------
67d7423 Remove use of deprecated HttpKernel LoggerInterface
dca4528 [HttpKernel] Extend psr/log's NullLogger class
1e5a890 [Monolog] Mark old non-PSR3 methods as deprecated
91a86f8 [HttpKernel][Monolog] Add PSR-3 support to the LoggerInterface
Discussion
----------
[HttpKernel][MonologBridge] PSR-3 support
This enables PSR-3 support and monolog 1.3+. The first commit is the main part. The rest deals with deprecation of short-hand methods (warn/err/crit/emerg) that are fully expanded in PSR-3 (warning/error/critical/emergency).
The downside of deprecating them is that for bundles it's a bit harder to support older and newer versions. If that is too much of a hassle you can drop that for now and cherry pick the first commit.
The upside is that it forces people to move towards PSR-3 compatible stuff, which means eventually we could completely drop the LoggerInterface from the framework. In any case I think the documentation should only mention the `Psr\Log\LoggerInterface` and people should start hinting against that. The change should be done in core as well I suppose.
Anyway I wanted to throw this out there as it is to get feedback.
---------------------------------------------------------------------------
by stof at 2013-01-09T09:15:15Z
@Seldaek I also think you should change the typehint to use the PSR LoggerInterface in all classes using the logger
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:54:55Z
OK updated according to all the feedback. I tested it in an app and it still seems to work so there shouldn't be any major issues.
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:59:55Z
@fabpot if you merge please merge also the bundle PR, otherwise it won't be possible to update without conflict.
---------------------------------------------------------------------------
by frosas at 2013-01-10T14:59:20Z
I'm trying to understand why a `composer update` of a Symfony 2.1.* resulted in a fatal error. Shouldn't a stable version don't break like this?
As @olaurendeau points, why Symfony depends 1.* instead of 1.2.*? Or why Monolog 1.3 breaks its public interface (EDIT: I'm not sure about it)? Or why isn't this PR being merged (into branch 2.1) at the same time Monolog 1.3 is released?
Please, understand I'm not looking for who to blame, it's just I want to know if this situation is unexpected or if otherwise a `composer update` on a stable branch is not as innocent as it seems.
---------------------------------------------------------------------------
by stof at 2013-01-10T15:06:51Z
@frosas it cannot be merged into 2.1 as it is a BC break. The 2.1 branch has been updated to forbid Monolog 1.3 already
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:11:58Z
@frosas you can blame me for releasing as 1.3.0 and not 2.0, but technically for monolog this isn't really a BC break, I just added an interface. The problem is due to the way it's used in symfony, it ended up as a fatal error. In any case the situation is now sorted out I think.
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:26:43Z
@stof now I see this `>=1.0,<1.3-dev` change in the 2.1 branch. Now, shouldn't a new (2.1.7) version be released for all of us not in the dev minimum-stability?
@Seldaek then do you see feasible to rely only in X.Y.* versions to avoid this kind of errors?
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:45:22Z
@frosas relying on X.Y.* is painful because you always need to wait until someone updates the constraint to get the new version. Of course using ~1.3 like in this PR means if I fuck up and break BC people will update to it, but that's a less likely occurrence than the alternative I think, so I would rather not use X.Y.*
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:50:50Z
@Seldaek you are right about this, but I was thinking more in changing it only for the stable versions. EDIT: I mean, how often do you need a new feature in a branch you only apply fixes to?
---------------------------------------------------------------------------
by stof at 2013-01-10T15:57:32Z
@frosas Monolog and Symfony have separate release cycles. Foorcing Symfony users to use an old version of Monolog until they update to a new version of Symfony whereas the newer Monolog is compatible is a bad idea. Thus, as Monolog keeps BC, it does not maintain bugfix releases for all older versions (just like Twig does too). So it would also forbid you to get the fixes done in newer Monolog versions.
The incompatibility between Symfony 2.1 LoggerInterface and PSR-3 (whereas they expect exactly the same behavior and signature for methods with the same name) is unfortunate and is the reason why we get some issues here.
---------------------------------------------------------------------------
by frosas at 2013-01-10T16:21:06Z
@stof I appreciate you prefer to allow newer versions at the price of having to be constantly monitoring its changes to avoid breaks.
Another similar but safer strategy would be to stick to X.Y.* versions and upgrade to X.Y+1.* once the new version integration is tested, but I understand this is discutible in projects as close to Symfony as Monolog.
Returning to the issue, what do you say to release this 2.1.7 version? Or is it only me who is having issues here?
---------------------------------------------------------------------------
by stof at 2013-01-10T16:26:20Z
@frosas a minor release should not break BC when following smeantic versionning (Symfony warned about the fact it is not strictly followed for the first releases of 2.x). But as far as monolog is concerned, 1.3 is BC with 1.2.
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T16:49:55Z
@frosas sorry I didn't get you still had the problem. I tagged a 2.1.7 of monologbundle which hopefully fixes your issue.
This PR was merged into the master branch.
Commits
-------
73db84f [Security] Move translations file to 'security' domain
324703a [Security] Switch to English messages as message keys
aa74769 [Security] Fix CS + unreachable code
2d7a7ba [Security] Fix `AuthenticationException` serialization
50d5724 [Security] Introduced `UsernameNotFoundException#get/setUsername`
39da27a [Security] Removed `get/setExtraInformation`, added `get/set(Token|User)`
837ae15 [Security] Add note about changed constructor to changelog
d6c57cf [FrameworkBundle] Register security exception translations
d7129b9 [Security] Fix exception constructors called in `UserChecker`
0038fbb [Security] Add initial translations for AccountStatusException childs
50e2cfc [Security] Add custom `getMessageKey` AccountStatusException childs
1147977 [Security] Fix InsufficientAuthenticationException constructor calls
79430b8 [Security] Fix AuthenticationServiceException constructor calls
42cced4 [Security] Fix AuthenticationException constructor calls
963a1d7 [Security] Add initial translations for the exceptions
ed6eed4 [Security] Add `getMessageKey` and `getMessageData` to auth exceptions
694c47c [Security] Change signature of `AuthenticationException` to match `\Exception`
Discussion
----------
[2.2][Security] AuthenticationException enhancements
Bug fix: semi
Feature addition: yes
Backwards compatibility break: yes
Symfony2 tests pass: [](http://travis-ci.org/asm89/symfony)
Fixes the following tickets: #837
License of the code: MIT
This PR adds the functionality discussed in #837 and changes the constructor of the `AuthenticationException` to match that of `\Exception`. This PR will allow developers to show a translated (save) authentication exception message to the user. :)
*Todo:*
- Add some functional test to check that the exceptions can indeed be translated?
- Get feedback on the current English messages
---------------------------------------------------------------------------
by asm89 at 2012-07-15T14:04:11Z
ping @schmittjoh
---------------------------------------------------------------------------
by schmittjoh at 2012-07-15T14:57:32Z
Looks good to me.
While you are at the exceptions, I think we can also get rid of the "extra information" thing and replace it by explicit getters/setters. Mostly that will mean adding set/getToken, set/getUser, set/getUsername. Bundles might add custom exceptions which have other data. This will make it a bit more useful and predictable.
---------------------------------------------------------------------------
by asm89 at 2012-07-15T15:40:45Z
@schmittjoh I removed the `get/setExtraInformation` and added the more explicit getters/setters as you suggested.
---------------------------------------------------------------------------
by asm89 at 2012-07-15T19:33:15Z
@fabpot Did you reschedule this for 2.2? Why? It was originally a 2.1 ticket. I think it is an important one because at the moment there is no reliable way to show users the cause of an `AuthenticationException` without the threat of exposing sensitive information. This issue has been around for a while, see the original issue this PR refers to, or for example [this TODO comment in FOSUB](https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Controller/SecurityController.php#L37).
The PR itself is ready to merge now. My only question that remains is about whether the actual translations should be functional tested?
---------------------------------------------------------------------------
by fabpot at 2012-07-15T19:43:19Z
We need to stop at some point. If not, we never release anything. beta3 was scheduled for today and I don't plan any other one before the first RC and I won't have time to review this PR next week. So, if you, @schmittjoh, @vicb, @stof, and a few other core devs "validate" this PR, I might consider merging it before 2.1.
---------------------------------------------------------------------------
by asm89 at 2012-07-15T19:46:09Z
@fabpot I totally agree with your point of view. I just have been trying to pickup some security issues that were still open. :)
---------------------------------------------------------------------------
by stof at 2012-07-15T19:50:29Z
This looks good to me
---------------------------------------------------------------------------
by asm89 at 2012-08-12T09:06:24Z
Since the beta period is over I assume the window was missed to get this security related PR in 2.1. If I have feedback from @fabpot I'll still try to make it mergeable asap though.
---------------------------------------------------------------------------
by fabpot at 2012-08-13T10:10:32Z
@asm89 This would indeed be considered for merging in 2.2.
---------------------------------------------------------------------------
by Antek88 at 2012-10-03T10:30:46Z
+1
---------------------------------------------------------------------------
by stof at 2012-10-04T21:27:15Z
@asm89 could you rebase this PR ? It conflicts with master
---------------------------------------------------------------------------
by fabpot at 2012-10-05T17:16:44Z
What's the status of this PR? @asm89 Have you taken all the feedback into account?
---------------------------------------------------------------------------
by stof at 2012-10-13T17:48:48Z
@asm89 ping
---------------------------------------------------------------------------
by fabpot at 2012-10-29T09:48:40Z
@asm89 If you don't have time, I can finish the work on this PR, but can you just tell me what's left?
---------------------------------------------------------------------------
by asm89 at 2012-10-29T10:02:22Z
I can pick this up, but I have two outstanding questions:
- One about adding `::create()`? https://github.com/symfony/symfony/pull/4935#discussion_r1358297
- And what is the final verdict on the messages? https://github.com/symfony/symfony/pull/4935#discussion_r1165701 The initial idea was that the exception itself have an exception message which is plain english and informative for the developer. If you want to display the 'safe' user messages you have the optional dependency on the translator. There is a comparison made with the Validator component, but in my opinion that's a different case because the violations always contain the message directed at the user and have no plain english message for the developer. Apart from that the Validator component contains it's own code for replacing `{{ }}` variables in messages (duplication? not as flexible as the translator). Concluding I'd opt for: optional dependency on translator component if you want to show 'safe' user messages + message keys.
@schmittjoh Any things to add?
---------------------------------------------------------------------------
by schmittjoh at 2012-10-29T10:14:09Z
Message keys sound good to me. I wouldn't add the ``create`` method for now.
On Mon, Oct 29, 2012 at 11:02 AM, Alexander <notifications@github.com>wrote:
> I can pick this up, but I have two outstanding questions:
>
> - One about adding ::create()? symfony/symfony#4935<https://github.com/symfony/symfony/issues/4935#discussion_r1358297>
> - And what is the final verdict on the messages? symfony/symfony#4935<https://github.com/symfony/symfony/issues/4935#discussion_r1165701>The initial idea was that the exception itself have an exception message
> which is plain english and informative for the developer. If you want to
> display the 'safe' user messages you have the optional dependency on the
> translator. There is a comparison made with the Validator component, but in
> my opinion that's a different case because the violations always contain
> the message directed at the user and have no plain english message for the
> developer. Apart from that the Validator component contains it's own code
> for replacing {{ }} variables in messages (duplication? not as
> flexible as the translator). Concluding I'd opt for: optional dependency on
> translator component if you want to show 'safe' user messages + message
> keys.
>
> @schmittjoh <https://github.com/schmittjoh> Any things to add?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/4935#issuecomment-9861016>.
>
>
---------------------------------------------------------------------------
by fabpot at 2012-10-29T10:27:37Z
As I said in the discussion about the translations, I'm -1 for the message keys to be consistent with how we manage translations everywhere else in the framework.
---------------------------------------------------------------------------
by stof at 2012-10-29T10:30:50Z
@fabpot When we changed the English translation for the validation errors in 2.1, we had to tag the commit as a BC rbeak as it was changing the source for all other translations. And if you look at the state of the files now, you will see that we are *not* using the English as source anymore in some places as some validation errors have a pluralized translation but the source has not been changed.
So I think using a key is more future-proof.
---------------------------------------------------------------------------
by asm89 at 2012-10-30T19:44:49Z
Any final decision on this? On one hand I have @stof and @schmittjoh +1 on message keys, on the other @fabpot -1. I guess it's your call @fabpot.
Edit: also @vicb seemed to be +1 on message keys earlier on.
---------------------------------------------------------------------------
by drak at 2012-11-01T20:19:00Z
I am also -1, I agree with @fabpot
---------------------------------------------------------------------------
by asm89 at 2012-11-12T09:38:51Z
@fabpot Can you please give a definite answer on this? I personally think @stof and @vicb have good points to do message keys, but with all these different people +1 and -1'ing the PR I'm lost on what it should actually do.
---------------------------------------------------------------------------
by asm89 at 2012-11-14T09:59:06Z
ping @fabpot
---------------------------------------------------------------------------
by asm89 at 2012-11-26T10:01:27Z
ping @fabpot We talked about this in Berlin. Any final thoughts on the PR? :) One idea was to do message keys + opt depend on the translator component if you want to use them, or use your own implementation.
---------------------------------------------------------------------------
by fabpot at 2012-11-26T14:01:37Z
The conclusion is: keep using plain English.
On Mon, Nov 26, 2012 at 11:01 AM, Alexander <notifications@github.com>wrote:
> ping @fabpot <https://github.com/fabpot> We talked about this in Berlin.
> Any final thoughts on the PR? :) One idea was to do message keys + opt
> depend on the translator component if you want to use them, or use your own
> implementation.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/4935#issuecomment-10709997>.
>
>
---------------------------------------------------------------------------
by Inori at 2012-11-26T15:00:22Z
is this final? if not, then +1 for message keys
---------------------------------------------------------------------------
by vicb at 2012-11-27T22:33:47Z
@fabpot I can't understand why we keep discussing this for months as this implementation use *both* keys and plain Englis, ie using keys is optional ( if it was not it would not be an issue according to #6129)
---------------------------------------------------------------------------
by asm89 at 2013-01-02T21:43:46Z
@fabpot @vicb I'll rebase this PR, fix the comments and refactor the message keys to use plain English + {{ }} syntax for the placeholders.
---------------------------------------------------------------------------
by asm89 at 2013-01-07T15:00:58Z
@fabpot If I fix this tonight, will it make the beta?
---------------------------------------------------------------------------
by fabpot at 2013-01-07T15:53:00Z
yes, definitely.
---------------------------------------------------------------------------
by asm89 at 2013-01-07T20:13:38Z
@fabpot I switched the implementation to English messages instead of message keys and fixed the final comments + rebased. Anything you want me to do after this?
Still happy with `getMessageKey()`?
This PR was merged into the master branch.
Commits
-------
6703fb5 added changelog entries
1997e2e fix phpdoc of UrlGeneratorInterface that missed some exceptions and improve language of exception message
f0415ed [Routing] made reference type fully BC and improved phpdoc considerably
7db07d9 [Routing] added tests for generating relative paths and network paths
75f59eb [Routing] add support for path-relative and scheme-relative URL generation
Discussion
----------
[2.2] [Routing] add support for path-relative URL generation
Tests pass: yes
Feature addition: yes
BC break: <del>tiny (see below)</del> NO
deprecations: NO
At the moment the Routing component only supports absolute and domain-relative URLs, e.g.
`http://example.org/user-slug/article-slug/comments` and
`/user-slug/article-slug/comments`.
But there are two link types missing: schema-relative URLs and path-relative URLs.
schema-relative: e.g. `//example.org/user-slug/article-slug/comments`
path-relative: e.g. `comments`.
Both of them would now be possible with this PR. I think it closes a huge gap in the Routing component.
Use cases are pretty common. Schema-relative URLs are for example used when you want to include assets (scripts, images etc) in a secured website with HTTPS. Path-relative URLs are the only option when you want to generate static files (e.g. documentation) that can be downloaded as an HTML archive. Such use-cases are currently not possible with symfony.
The calculation of the relative path based on the request path and target path is hightly unit tested. So it is really equivalent. I found several implemenations on the internet but none of them worked in all cases. Mine is pretty short and works.
I also added an optional parameter to the twig `path` function, so this feature can also be used in twig templates.
Ref: This implements path-relative URLs as suggested in #3908.
<del>[BC BREAK] The signature of UrlGeneratorInterface::generate changed to support scheme-relative and path-relative URLs. The core UrlGenerator is BC and does not break anything, but users who implemented their own UrlGenerator need to be aware of this change. See UrlGenerator::convertReferenceType.</del>
---------------------------------------------------------------------------
by jalliot at 2012-04-16T09:56:56Z
@Tobion For completeness, you should add the option to the `url` and `asset` twig functions/template helpers.
---------------------------------------------------------------------------
by stof at 2012-04-16T10:46:06Z
@jalliot adding the option to ``url`` does not make any sense. The difference between ``path`` and ``url`` is that ``path`` generates a path and ``url`` generates an absolute url (thus including the scheme and the hostname)
---------------------------------------------------------------------------
by Tobion at 2012-04-16T12:27:49Z
@stof I guess jalliot meant we could then generate scheme-relative URLs with `url`. Otherwise this would have no equivalent in twig.
---------------------------------------------------------------------------
by jalliot at 2012-04-16T12:34:08Z
@stof Yep I meant what @Tobion said :)
---------------------------------------------------------------------------
by Tobion at 2012-04-18T11:57:04Z
The $relative parameter I added besides the existing $absolute parameter of the `->generate` method was not clear enough. So I merged those into a different parameter `referenceType`. I adjusted all parts of symfony to use the new signature. And also made the default `UrlGenerator` implementation BC with the old style. So almost nobody will recognize a change. The only BC break would be for somebody who implemented his own `UrlGenerator` and did not call the parent default generator.
Using `referenceType` instead of a simple Boolean is much more flexible. It will for example allow a custom generator to support a new reference type like http://en.wikipedia.org/wiki/CURIE
---------------------------------------------------------------------------
by Tobion at 2012-04-18T13:34:58Z
ping @schmittjoh considering your https://github.com/schmittjoh/JMSI18nRoutingBundle/blob/master/Router/I18nRouter.php would need a tiny change
---------------------------------------------------------------------------
by schmittjoh at 2012-04-18T13:37:39Z
Can you elaborate the necessary change?
---------------------------------------------------------------------------
by Tobion at 2012-04-18T13:51:10Z
This PR changes the signature of `generate` to be able to generate path-relative and scheme-relative URLs. So it needs to be
`public function generate($name, $parameters = array(), $referenceType = self::ABSOLUTE_PATH)` and your implementation would need to change `if ($absolute && $this->hostMap) {` to `if (self::ABSOLUTE_URL === $referenceType && $this->hostMap) {`
I can do a PR if this gets merged.
---------------------------------------------------------------------------
by schmittjoh at 2012-04-18T13:52:14Z
If I understand correctly, the old parameter still works, no?
edit: Ah, ok I see what you mean now.
---------------------------------------------------------------------------
by Tobion at 2012-04-18T13:56:33Z
Yeah the old parameter still works but $absolute would also evaluate to true (a string) in your case for non-absolute URLs, i.e. paths.
---------------------------------------------------------------------------
by Tobion at 2012-04-19T21:09:46Z
ping @fabpot
---------------------------------------------------------------------------
by fabpot at 2012-04-20T04:30:18Z
Let's discuss that feature for 2.2.
---------------------------------------------------------------------------
by Tobion at 2012-04-20T10:40:59Z
What are your objections against it? It's already implemented, it works and it adds support for things that are part of a web standard. The BC break is tiny at the moment (almost nobody is affected) because the core UrlGenerator works as before. But if we waited for 2.2 it will be much harder to make the transition because 2.1 is LTS. So I think is makes sense to add it now. Furthermore it makes it much more future-proof as custom generators can more easiliy add support for other link types like CURIE. At the moment a Boolean for absolute URLs is simply too limited and also somehow inconsistent because $absolute = false stands for an absolute path. You see the awkwardness in this naming.
Btw, I added a note in the changelog. And I will add documentation of this feature in symfony-docs once this is merged.
---------------------------------------------------------------------------
by fabpot at 2012-04-20T12:14:32Z
nobody has ever said that 2.1 would be LTS. Actually, I think we are going to wait for 2.3 for LTS.
---------------------------------------------------------------------------
by Tobion at 2012-04-20T12:27:18Z
Well what I meant is, the longer we wait with this, the harder to apply it.
In 04ac1fdba2 you modified `generate` signature for better extensibility that is not even made use of. I think changing `$abolute` param goes in the same direction and has direct use.
I'd like to know your reason to wait for 2.2. Not enough time to review it, or afraid of breaking something, or marketing for 2.2?
---------------------------------------------------------------------------
by stof at 2012-04-20T16:28:27Z
@Tobion the issue is that merging new features forces to postpone the release so that it is tested by enough devs first to be sure there is no blocking bug in it. Big changes cannot be merged when we are hunting the remaining bugs to be able to release.
---------------------------------------------------------------------------
by schmittjoh at 2012-04-20T16:42:11Z
Considering the changes that have been made to the Form component, and are still being made, I think this is in comparison to that a fairly minor change.
Maybe a clearer guideline on the release process, or the direction would help, and avoid confusion, or wrong expectations on contributors' part.
---------------------------------------------------------------------------
by Tobion at 2012-10-05T13:52:11Z
@fabpot this is ready. So if you agree with it, I would create a documentation PR.
---------------------------------------------------------------------------
by stof at 2012-10-13T16:09:47Z
@fabpot what do you think about this PR ?
---------------------------------------------------------------------------
by Crell at 2012-11-01T16:05:01Z
This feels like it's overloading the generate() method to do double duty: One, make a URl based on a route. Two, make a URI based on a URI snippet. Those are two separate operations. Why not just add a second method that does the second operation and avoid the conditionals? (We're likely to do that in Drupal for our own generator as well.)
---------------------------------------------------------------------------
by Tobion at 2012-11-01T16:38:39Z
@crell: No, you must have misunderstood something. The generate method still only generates a URI based on a route. The returned URI reference can now also be a relative path and a network path. Thats all.
---------------------------------------------------------------------------
by Tobion at 2012-12-13T18:30:28Z
@fabpot this is ready. It is fully BC! I also improved phpdoc considerably.
---------------------------------------------------------------------------
by Tobion at 2012-12-14T20:51:38Z
@fabpot Do you want me to write documentation for it? I would also be interested to write about the new features of the routing component in general. I wanted to do that anyway and it would probably be a good fit for your "new in symfony" articles.
---------------------------------------------------------------------------
by fabpot at 2012-12-14T20:58:16Z
Im' going to review this PR in the next coming days. And to answer your second question, more documentation or better documentation is always a good thing, so go for it.
---------------------------------------------------------------------------
by Tobion at 2013-01-02T21:50:20Z
@fabpot ping. I added changelog entries.
This PR was merged into the master branch.
Commits
-------
586a16e [Validator] Changed DefaultTranslator::getLocale() to always return 'en'
58bfd60 [Validator] Improved the inline documentation of DefaultTranslator
cd662cc [Validator] Added ExceptionInterface, BadMethodCallException and InvalidArgumentException
e00e5ec [Validator] Fixed failing test
cc0df0a [Validator] Changed validator to support pluralized messages by default
56d61eb [Form][Validator] Added BC breaks in unstable code to the CHANGELOG
1e34e91 [Form] Added upgrade instructions to the UPGRADE file
b94a256 [DoctrineBridge] Adapted DoctrineBridge to translator integration in the validator
c96a051 [FrameworkBundle] Adapted FrameworkBundle to translator integration in the validator
92a3b27 [TwigBridge] Adapted TwigBridge to translator integration in the validator
e7eb5b0 [Form] Adapted Form component to translator integration in the validator
46f751c [Validator] Extracted message interpolation logic of ConstraintViolation and used the Translation component for that
Discussion
----------
[Validator] Integrated the Translator in the Validator component
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #5844, #6117
Todo: -
License of the code: MIT
Documentation PR: -
This PR allows to replace the default message substitution strategy in the validator (`strtr()`) by passing an implementation of `Symfony\Component\Translation\TranslatorInterface`. The motivation for this are both #5844 and the need to replace the translation strategy in Drupal's integration of the Validator.
In the stand-alone usage of the validator, both the translator and the default translation domain can now be passed to `ValidatorBuilderInterface`:
```php
$validator = Validation::createValidatorBuilder()
->setTranslator(new MyTranslator())
->setTranslationDomain('validators')
->getValidator();
```
References:
* #5844
* #6117
* #6129
* [Add a validation framework to Drupal 8](http://drupal.org/node/1845546)
* [Add the symfony validator component to core despite Symfony potentially releasing BC-breaking updates after 2.3.](http://drupal.org/node/1849564)
---------------------------------------------------------------------------
by Tobion at 2012-11-28T08:53:25Z
no BC break? Looking at ValidatorBuilderInterface there is definitely one.
---------------------------------------------------------------------------
by bschussek at 2012-11-28T08:55:01Z
ValidatorBuilderInterface is not part of the stable API. You are not supposed to implement this interface.
---------------------------------------------------------------------------
by Tobion at 2012-11-28T09:01:07Z
We're not only documenting bc breaks for stable API, otherwise we could remove 90% of the upgrade file since few methods are tagged with API.
An interface that nobody should implement?
---------------------------------------------------------------------------
by bschussek at 2012-11-28T09:30:02Z
The question is what to consider a BC break. Something will always break for someone. Should we consequently mark everything as BC break? I don't think so.
For example, since 2.1, you are supposed to use `Validation::createValidator*()` for creating a validator. Because of that, I won't consider changing the constructor signature of `Validator` a BC break anymore from 2.1 on.
The same for the unstable interfaces. These are currently meant to be used only, that is, type hint against them and call their methods. But we don't guarantee that we won't add methods to them.
---------------------------------------------------------------------------
by Tobion at 2012-11-28T09:38:19Z
I agree that almost any change could be considered a BC break. So we probably need to better define what a BC break is and what not. Otherwise Symfony will stop evolving after 2.3 because from then on Fabien wanted to prevent BC breaks which is almost impossible in a strict definition of bc break.
---------------------------------------------------------------------------
by fabpot at 2012-11-28T11:37:22Z
BC breaks should always be documented, and we guarantee BC only for things tagged with @api. I'm going to update the docs to make things clearer.
---------------------------------------------------------------------------
by bschussek at 2012-11-28T13:09:57Z
@fabpot I documented these changes now in the CHANGELOG: af99ebb1206ac92889b7193ba1ecc12bf2617e85
Are we sure we want to document *all* BC breaks from now on, even in non-@api code? This could rather scare people looking at our changelogs (lots of BC BREAKS there).
---------------------------------------------------------------------------
by fago at 2012-11-28T17:29:58Z
Unfortunately, it turns out the symfony translator interface does not mach the Drupal translation system as well as we initally thought, see http://drupal.org/node/1852106. Given that, this would integrating the validator component into Drupal even harder, because it introduces the dependency on the (unwanted) translation component. :(
---------------------------------------------------------------------------
by stof at 2012-11-28T18:19:36Z
If this does not help Drupal anyway, maybe #5844 is a better way to manage translations for people using the validator outside forms ?
and the Drupal guys would simply follow a similar approach, but based on their own translator instead of the symfony one.
---------------------------------------------------------------------------
by fago at 2012-11-28T18:50:12Z
Yeah. The only problem I see with the approach of #5844 is that *after* validation only the translated messages are available. We'd need to have access to the untranslated messages also.
---------------------------------------------------------------------------
by fago at 2012-11-29T09:49:47Z
As our translation system handles translating pluralized messages differently, the current ExecutionContextInterface::addViolation() method poses a problem also. We need to pass on - both the single and plural - message, as the message gets chosen during translation, see http://api.drupal.org/api/drupal/core!includes!common.inc/function/format_plural/8
So maybe, we could allow adding an already created ConstraintViolation object also? Then, we could implement a "PluralConstraintViolation" class that takes both message templates.
---------------------------------------------------------------------------
by bschussek at 2012-12-03T15:52:36Z
I updated this PR to support pluralized messages by default in the validator. This should solve the problem of the Drupal guys, because their implementation of `TranslatorInterface::transChoice($id, $number, ...)` can now simply split the $id by pipes (`|`) and pass the parts to their own `format_plural($count, $singular, $plural, ...)` function.
For us, it breaks BC because translation catalog sources had to be adapted.
---------------------------------------------------------------------------
by fabpot at 2012-12-03T16:25:52Z
Most of the XLF files are broken (the end is missing now).
IIUC, we now have a hard dependency on the Translation component, which is something we wanted to avoid.
---------------------------------------------------------------------------
by fabpot at 2012-12-03T16:27:56Z
Oops, clicked on the "comment" button too fast.
So, the dependency is hard (you need to install the dep) but light as we only rely on the translation interface from the component (when using the default translator). It looks acceptable to me, especially because we now use Composer to manage dependencies.
---------------------------------------------------------------------------
by bschussek at 2012-12-03T16:54:10Z
@fabpot Thanks for the hint. Going to fix this.
---------------------------------------------------------------------------
by bschussek at 2012-12-04T11:34:43Z
@fabpot Fixed.
---------------------------------------------------------------------------
by bschussek at 2012-12-07T12:40:24Z
Is there anything missing for this PR to be merged?
* 2.1:
[Console] Fix style escaping parsing
[Console] Make style formatter matching less greedy to avoid having to escape when not needed
[Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
[Component] [Security] fixed PSR-2 coding violation in ClassUtilsTest class.
[Form] Fixed EntityChoiceList when loading objects with negative integer IDs
[TwigBundle] There is no CSS visibility of display, should be visible instead
[Form] corrected source node for a Danish translation
[DependencyInjection] fixed a bug where the strict flag on references were lost (closes#6607)
[HttpFoundation] Check if required shell functions for `FileBinaryMimeTypeGuesser` are not disabled
[CssSelector] added css selector with empty string
[HttpFoundation] Docblock for Request::isXmlHttpRequest() now points to Wikipedia
[DependencyInjection] refactored code to avoid logic duplication
[Form] Deleted references in FormBuilder::getFormConfig() to improve performance
[HttpFoundation] Update docblock for non-working method
Conflicts:
src/Symfony/Bundle/TwigBundle/Resources/views/Exception/trace.html.twig
src/Symfony/Bundle/TwigBundle/Resources/views/Exception/traces.html.twig
* 2.0:
[Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
[TwigBundle] There is no CSS visibility of display, should be visible instead
[DependencyInjection] fixed a bug where the strict flag on references were lost (closes#6607)
[HttpFoundation] Check if required shell functions for `FileBinaryMimeTypeGuesser` are not disabled
[CssSelector] added css selector with empty string
[HttpFoundation] Docblock for Request::isXmlHttpRequest() now points to Wikipedia
[DependencyInjection] refactored code to avoid logic duplication
Conflicts:
src/Symfony/Bundle/FrameworkBundle/Resources/config/esi.xml
src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php
src/Symfony/Component/HttpFoundation/File/MimeType/FileBinaryMimeTypeGuesser.php
* 2.1: (24 commits)
updated license year
Update src/Symfony/Component/HttpFoundation/Response.php
[Form] Fixed inheritance of "error_bubbling" in RepeatedType
[Form] Fixed DateType when used with the intl extension disabled.
[HttpFoundation] fix return types and handling of zero in Response
[HttpFoundation] better fix for non-parseable Expires header date
Fixed missing plural message in portuguese validator
Fix Expires when the header is -1
[DoctrineBridge] Allowing memcache port to be 0 to support memcache unix domain sockets.
[Console] fixed unitialized properties (closes#5935)
[Process] Prevented test from failing when pcntl extension is not enabled.
Revert "[DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option"
[Form] Fixed failing tests for DateTimeToStringTransformer.
[Locale] Fixed the StubLocaleTest for ICU versions lower than 4.8.
[Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
[Form] Fixed test regression introduced in #6440
[Tests] Fix namespaces
Fixed php doc of GenericEvent::__construct
HttpUtils must handle RequestMatcher too
use preferred_choices in favor of preferred_query
...
Conflicts:
src/Symfony/Bridge/Propel1/Form/ChoiceList/ModelChoiceList.php
* 2.0:
updated license year
Update src/Symfony/Component/HttpFoundation/Response.php
[Console] fixed unitialized properties (closes#5935)
[Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
bumped Symfony version to 2.0.21-DEV
updated VERSION for 2.0.21
updated CHANGELOG for 2.0.21
Conflicts:
src/Symfony/Bundle/SwiftmailerBundle/LICENSE
src/Symfony/Component/Filesystem/LICENSE
src/Symfony/Component/HttpFoundation/Response.php
src/Symfony/Component/HttpKernel/Kernel.php
This PR was merged into the master branch.
Commits
-------
5e359d3 made the kernel optional in all data collectors
Discussion
----------
made the kernel optional in all data collectors
This PR was merged into the master branch.
Commits
-------
bf9e238 [Form] Add options with_minutes to DateTimeType & TimeType
Discussion
----------
[Form] Add option with_minutes to the DateTimeType & TimeType
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Fixes the following tickets: -
Todo: -
Hey,
One of my project requires the datetime usage only with hours. I have submit a patch allowing to disable minutes like seconds are disabled.
---------------------------------------------------------------------------
by stloyd at 2012-04-09T16:26:11Z
You should also extend tests for those `Types`
---------------------------------------------------------------------------
by egeloen at 2012-04-09T16:31:51Z
Oups, I have looked at tests but I didn't find it at my first reading. I will do it :)
---------------------------------------------------------------------------
by stloyd at 2012-04-09T16:34:42Z
@egeloen Here you can find tests for Form Types: https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Form/Tests/Extension/Core/Type
---------------------------------------------------------------------------
by egeloen at 2012-04-09T16:42:42Z
@stloyd I have added tests. Can you give me some feedbacks ?
---------------------------------------------------------------------------
by stloyd at 2012-04-09T16:46:33Z
@egeloen I'm not sure if we should allow user to set `with_minutes=false` and `with_seconds=true`. But in overall seems quite ok.
---------------------------------------------------------------------------
by egeloen at 2012-04-09T16:51:37Z
Yes, you're right. But I'm unsure how can I do this following the good way.
---------------------------------------------------------------------------
by inanimatt at 2012-05-03T15:46:02Z
Just make it throw an InvalidConfigurationException.php exception, no? :)
---------------------------------------------------------------------------
by egeloen at 2012-06-09T18:27:41Z
I have updated the PR in order to throw an ``InvalidConfigurationException`` if we enable seconds & disable minutes.
---------------------------------------------------------------------------
by egeloen at 2012-07-09T19:08:11Z
@bschussek I have removed the useless code.
I think I have found an issue about my PR. I have added 3 tests in order to show it. It seems if we disable minutes, the text widget is broken.
---------------------------------------------------------------------------
by stof at 2012-10-13T16:00:43Z
@egeloen can you rebase your PR as it conflicts with master ?
---------------------------------------------------------------------------
by egeloen at 2012-10-13T17:15:22Z
@stof rebase
Like explain previously, my PR is still failling if we disable minutes & use the text widget.
---------------------------------------------------------------------------
by egeloen at 2012-10-13T18:09:03Z
I have fixed the last issue. IMO, the PR can now be merge.
---------------------------------------------------------------------------
by stof at 2012-10-13T18:20:00Z
@bschussek @fabpot ping
---------------------------------------------------------------------------
by egeloen at 2012-10-16T18:13:00Z
@bschussek Do yo think this PR can be merge?
---------------------------------------------------------------------------
by egeloen at 2012-10-30T19:14:00Z
@fabpot is there something missing before merging?
---------------------------------------------------------------------------
by fabpot at 2012-10-31T08:22:55Z
I'm waiting for @bschussek approval.
---------------------------------------------------------------------------
by geoffrey-brier at 2012-11-13T10:49:52Z
I really need the `with_minute => false` enhancement on a project as I don't want to write CSS/JS hacks, could @bschussek approve/disapprove it so that I can make a decision?
---------------------------------------------------------------------------
by henrikbjorn at 2012-11-13T10:52:12Z
@geoffrey-brier you could do you own FieldType that extends the current one and add the option your self.
---------------------------------------------------------------------------
by egeloen at 2012-11-13T13:20:44Z
@bschussek Yes... :) I have updated the PR according to your feedback.
I needed to update the `DateTimeToStringTransformer` because it tries to create a `DateTime` only from the value (with no format). In my case, the `'03'` value is not enougt to create it. So, if the date time creation fails, it then try to create the datetime from the format. I don't know if it is the best approach but it works well.
By the way, why does it first try to create a `DateTime` without format, **then only** try to use the format ?
---------------------------------------------------------------------------
by bschussek at 2012-11-13T14:20:13Z
@egeloen Good question, I think the transformer is a bit flawed there. I'm working on that. The rest of the PR looks good. Thank you!
---------------------------------------------------------------------------
by bschussek at 2012-12-13T18:14:58Z
I fixed the transformer in #6333. Once that is merged into 2.1, and once 2.1 is merged into master after that, you can rebase this PR on master. Then we can merge it.
---------------------------------------------------------------------------
by egeloen at 2012-12-22T14:54:38Z
I have rebased & squashed commits. The PR is ready to merge. ping @fabpot
If you want your code to work on both version, use the following syntax:
{% render url('foo') with {}, {'bar': 1} %}
where the empty array is not used in 2.2.
* 2.1:
fixed typo
[FrameworkBundle] fixed ESI calls
[FrameworkBundle] fixed ESI calls
bumped Symfony version to 2.1.6-DEV
updated VERSION for 2.1.5
updated CHANGELOG for 2.1.5
bumped Symfony version to 2.0.21-DEV
[FrameworkBundle] fixed trusted_proxies configuration for some edge cases
[FrameworkBundle] fixed XSD for the trusted-proxies setting
updated VERSION for 2.0.20
update CONTRIBUTORS for 2.0.20
updated CHANGELOG for 2.0.20
Conflicts:
src/Symfony/Bundle/FrameworkBundle/HttpKernel.php
src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/ConfigurationTest.php
src/Symfony/Component/HttpKernel/Kernel.php
* 2.0:
bumped Symfony version to 2.0.21-DEV
[FrameworkBundle] fixed trusted_proxies configuration for some edge cases
[FrameworkBundle] fixed XSD for the trusted-proxies setting
updated VERSION for 2.0.20
update CONTRIBUTORS for 2.0.20
updated CHANGELOG for 2.0.20
Conflicts:
CONTRIBUTORS.md
src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/ConfigurationTest.php
src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/Fixtures/xml/full.xml
src/Symfony/Component/HttpKernel/Kernel.php
* 2.1:
[FrameworkBundle] added support for URIs as an argument to HttpKernel::render()
[FrameworkBundle] restricted the type of controllers that can be executed by InternalController
[Process] Allow non-blocking start with PhpProcess
Making it easier to grab the PR template.
[Locale] fixed a test
Fixed failing test
fix double-decoding in the routing system
Conflicts:
src/Symfony/Component/Process/PhpProcess.php
* 2.0:
[FrameworkBundle] added support for URIs as an argument to HttpKernel::render()
[FrameworkBundle] restricted the type of controllers that can be executed by InternalController
Making it easier to grab the PR template.
fix double-decoding in the routing system
Conflicts:
README.md
src/Symfony/Bundle/FrameworkBundle/EventListener/RouterListener.php
src/Symfony/Component/Security/Http/HttpUtils.php
This PR was merged into the 2.0 branch.
Commits
-------
8b2c17f fix double-decoding in the routing system
Discussion
----------
fix double-decoding in the routing system
@fabpot @vicb This should fix it. You know what ;) Don't want to leak more information.
And the good thing, it's no hack nor does it break BC.
This PR was merged into the master branch.
Commits
-------
163564b [WebProfilerBundle] replaced yaml_dump by json_encode to make the Web Profiler independent from the YAML component
1c92307 [WebProfilerBundle] fixed exception panel when no exception is thrown
00e08be [WebProfilerBundle] replaced usage of the render tag by the render function (to decouple the bundle from TwigBundle)
0e2418c [TwigBundle] added the HttpKernel extension to the default Twig loaded extensions
f0d9be0 [TwigBridge] added an extension for the HttpKernel component
Discussion
----------
Added an HttpKernelExtension in Twig bridge and used it in the WebProfiler
The first commit introduces a new HttpKernelExtension in the Twig bridge that allows the rendering of a sub-request from a template (the code mostly comes from Silex, and will replace the code there at some point).
The name `render` is probably not the best one as it does not really tell you what it does (the same goes for the `render` tag we have in Symfony2 by the way).
Here is a list of possible names:
* `render()`
* `render_request()`
* `request()`
* `subrequest()`
* `include_request()`
I don't really like the last one, but it is (perhaps) consistent with the `include` tag/function in Twig.
This new `render()` function is also a first step towards replacing the `render` tag (with support for ESI, SSI, ...). But it won't happen before we refactor the way it's managed now (a lot of the code is in the FrameworkBundle right now and that prevents Silex or Drupal to reuse it).
The other commits make use of this new extension to make the Web Profiler truly independent from TwigBundle and FrameworkBundle.
This PR was merged into the master branch.
Commits
-------
6efae29 [TwigBundle] fixed configuration to avoid key normalizations for paths and globals (closes#5998)
e31d4f1 [Config] allowed the disabling of key normalization on some array nodes
Discussion
----------
Config key normalization
This is a quick proof-of-concept for a better fix of #6086, where key normalizations can be disabled on specific nodes. The previous patch was not really useful as you were only able to disable key normalization globally for a configuration.
ping @lolautruche
The second commit fixes#5998.
---------------------------------------------------------------------------
by lolautruche at 2012-12-15T15:39:00Z
+1
The approach is neat and much better than my workaround. Gives better control and avoids magic 😃 (even if this *normalization* is still a bit obscure to me).
This PR was merged into the master branch.
Commits
-------
a498261 [Webprofiler] increased hitboxSize of the close button the webprofiler toolbar. Otherwise it's very hard to close it on a tablet
Discussion
----------
[Webprofiler] increased hitboxSize of the close button the webprofiler
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets:
Todo:
License of the code: MIT
Documentation PR:
Increased the hitbox Size of the close button on webprofiler, otherwise it's very hard to close it on a tablet. Apple recommends 40x40 pixels for touch stuff
see issue https://github.com/symfony/symfony/issues/6264
---------------------------------------------------------------------------
by nicam at 2012-12-16T13:45:36Z
@stloyd done
This PR was merged into the master branch.
Commits
-------
5a73d55 Added small test to check if time limit works
7f6e99b Fixed MongoDB storage missing time range. Fixed UI not searching properly. Removed unnecessary time query.
3a0ed58 Added ability to search by time when using the profiler
Discussion
----------
[WebProfilerBundle] [HttpKernel][Profiler] Added ability to search by time when using the profiler
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~
This PR adds the ability to search in a certain time range for profiles.
---------------------------------------------------------------------------
by fabpot at 2012-12-11T14:36:21Z
Anyone willing to help for the MongoDB support? ping @jmikola
---------------------------------------------------------------------------
by jmikola at 2012-12-11T18:42:00Z
Totally. I'm flying between Turkey and New York tomorrow and if I have wifi on the plane (good chance) I'll check this out. Otherwise, later in the week.
---------------------------------------------------------------------------
by dlsniper at 2012-12-11T22:42:19Z
I could have a look on this matter as well tomorrow but I'm not really sure about my schedule. Any help would be greatly appreciated. Thanks!
---------------------------------------------------------------------------
by jmikola at 2012-12-13T21:56:26Z
@dlsniper: Had no wifi on the plane, but I'm available to work on this now. How can we go about it?
Should I submit a PR against your branch? Then you can accept that and my commit should show up in this PR.
---------------------------------------------------------------------------
by dlsniper at 2012-12-13T22:05:21Z
@jmikola I haven't had too much time either but yes, that would be great.
The change should go here: b631cd989c/src/Symfony/Component/HttpKernel/Profiler/MongoDbProfilerStorage.php (L172) but I clearly lack the skill of making the necessary changes for it.
Thank you very much!
---------------------------------------------------------------------------
by dlsniper at 2012-12-15T21:39:39Z
I've fixed MongoDB driver, adjusted search by time like @jmikola suggested and fixed a UI bug. Can someone please validate this over?
Thanks!
---------------------------------------------------------------------------
by dlsniper at 2012-12-15T21:55:51Z
The tests seem to be failing because of some locale changes not related to these commits. I encounter the same problem on my laptop and I could try and fix it into a different branch but last time I've tried to fix it it was ok on my side and failing on Travis. Any hints for that?
* 2.1:
[FrameworkBundle] fixed broken tests
[FrameworkBundle] Fixed logic under test environment.
[Session] Added exception to save method
[Session] Fixed a bug with the TestListener
Added comment
[FrameworkBundle] Added tests for trusted_proxies configuration.
[FrameworkBundle] Added a check on file mime type for CodeHelper::fileExcerpt()
checked for a potentially missing key
[FrameworkBundle] used the new method for trusted proxies
remove realpath call
Conflicts:
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
* 2.0:
Added comment
[FrameworkBundle] Added tests for trusted_proxies configuration.
[FrameworkBundle] Added a check on file mime type for CodeHelper::fileExcerpt()
checked for a potentially missing key
[FrameworkBundle] used the new method for trusted proxies
remove realpath call
Conflicts:
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
This PR was merged into the 2.0 branch.
Commits
-------
f0743b1 Merge pull request #1 from pylebecq/2.0
555e777 [FrameworkBundle] Added tests for trusted_proxies configuration.
a0e2391 [FrameworkBundle] used the new method for trusted proxies
Discussion
----------
[FrameworkBundle] used the new method for trusted proxies
This makes the framework bundle using the new method from the request class.
---------------------------------------------------------------------------
by fabpot at 2012-12-05T10:38:20Z
As this is a sensitive issue, can you add some tests? Thanks.
---------------------------------------------------------------------------
by bamarni at 2012-12-06T13:00:24Z
Well I don't know why it fails on travis, I can't run the full test suite locally because of a segfault but ```phpunit src/Symfony/Bundle/``` marks all the tests as passing.
---------------------------------------------------------------------------
by fabpot at 2012-12-06T13:08:11Z
But it looks like the failing tests come from what you've changed.
---------------------------------------------------------------------------
by bamarni at 2012-12-06T13:29:33Z
Yes, I'm not saying it's not my fault but I can't reproduce this as locally it tells me they pass, I'll try to fix this this evening.
---------------------------------------------------------------------------
by bamarni at 2012-12-06T17:49:28Z
Apparently it fails only when running the whole testsuite, looking at other travis builds I can see this one on 2.0 : https://travis-ci.org/symfony/symfony/jobs/3495511 which fails in a similar way than here (https://travis-ci.org/symfony/symfony/jobs/3530928). Because of a place trying to access an undefined $_SERVER key : ```PHP Notice: Undefined index: SCRIPT_NAME ...``` but I can't find where, and the stack trace references some phpunit classes.
I'd be happy if someone could give me some pointers in here as I don't have any clue about how to fix this..
---------------------------------------------------------------------------
by bamarni at 2012-12-06T18:00:57Z
As a consulsion I'd say I can't run the whole testsuite locally (it fails even when I revert my commit), so there is no reliable way for me to fix this, if anyone is up for continuing this feel free.
---------------------------------------------------------------------------
by fabpot at 2012-12-11T09:47:48Z
@bamarni Can you just update this PR with the code change and no tests at all? I will then finish the PR. Thanks.
---------------------------------------------------------------------------
by bamarni at 2012-12-11T16:58:17Z
@fabpot: thanks for helping me out on this, hope you won't run into the same issue!
This PR was merged into the master branch.
Commits
-------
6b10550 Merge branch 'master' of github.com:symfony/symfony into deprecationErrors
1d82112 [Form] Fix two cases where deprecated methods were being used
b8cdbdc [Form] Catch deprecation errors that are caused by BC code
ebcb432 [Form] [FrameworkBundle] catch deprecation errors in tests
c21b12e [Form] handle BC use of deprecated stuff in non-test-methods.
fc2be6d [Form] catch deprecated errors in tests
800a032 [Form] replace bindRequest() with bind(), as bindRequest is deprecated
d5b2638 [Form] Trigger errors for deprecated methods in Form Component
f3d6966 [Validator] Stop using deprecated methods
d57ad32 [Form] Catch deprecation errors when using deprecated methods/classes in tests
3241157 [Validator] Trigger errors for deprecations
1f9eb7f return value of handleError
b35de9e Handle errors using a custom error handler
f49704b trigger errors for deprecated methods in HttpFoundation component
Discussion
----------
trigger_error() for deprecations
See also #6173 and #6139.
Started triggering errors in the HttpFoundation component.
It seems as if most of the time the error is just duplicating the text in the @deprecation comment.
Any opinions on if duplicating the text is acceptable, or if fetching the comment text to output the error makes sense?
---------------------------------------------------------------------------
by Seldaek at 2012-12-04T13:39:42Z
IMO it's fine to just duplicate the `@deprecated` note in the message, since anyway this code is meant to be completely deleted, this duplication should not do much harm.
---------------------------------------------------------------------------
by fabpot at 2012-12-06T08:22:21Z
@colinfrei I've merged PR #6173. Do you have time to implement the `trigger_error()` call everywhere? Thanks.
---------------------------------------------------------------------------
by colinfrei at 2012-12-06T08:36:55Z
Yep I'll finish that, probably until the beginning of next week.
---------------------------------------------------------------------------
by bschussek at 2012-12-10T10:15:12Z
Thank you for working on this!
---------------------------------------------------------------------------
by fabpot at 2012-12-12T11:08:53Z
@colinfrei: Is this PR finished? Can I merge it?
---------------------------------------------------------------------------
by colinfrei at 2012-12-12T12:09:19Z
@fabpot not quite - I lost some work due to a computer crash over the weekend. The only thing open is fixing the tests for the Form Component and catching the cases where the Form Component intentionally uses deprecated stuff.
---------------------------------------------------------------------------
by colinfrei at 2012-12-15T07:32:28Z
@fabpot - finished adding trigger_errors and catching them in Tests and as needed.
Travis is failing, but that seems to be master being broken due to the Finder changes?
I changed a few cases where the code was using deprecated methods which wasn't necessary in my eyes, specifically 1d8211249b, 800a032f07, f3d696636a
This PR was merged into the master branch.
Commits
-------
74a8fcf [FrameworkBundle] Added support for default templates per render tag
Discussion
----------
[FrameworkBundle] Added support for default templates per render tag
This commit allows you to specify default templates per render tag when using hinclude.
E.G:
The following will use the specific default template for the render:
```` {% render "AcmeDemoBundle:Controller:action" with {}, {"standalone" : "js", "default" : "AcmeDemoBundle:Default:content.html.twig"} %}````
or if you don't want to use a template for the default content but just a string, you can do the following
```` {% render "AcmeDemoBundle:Controller:action" with {}, {"standalone" : "js", "default" : "Loading..."} %}````
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Fixes the following tickets: #3356
Todo: -
Documentation
---------------------------------------------------------------------------
by fabpot at 2012-12-14T12:25:40Z
Looks good to me. Can you add a note in the CHANGELOG of the component and send a PR on symfony/symfony-docs about this new feature? Thanks.
---------------------------------------------------------------------------
by pierredup at 2012-12-14T14:30:00Z
@fabpot done, documentation PR symfony/symfony-docs#2021
* 2.1:
[Console] Add support for parsing terminal width/height on localized windows, fixes#5742
[Form] Fixed treatment of countables and traversables in Form::isEmpty()
refactor ControllerNameParser
[Form] Fixed FileType not to throw an exception when bound empty
- Test undefined index #
Maintain array structure
Check if key # is defined in $value
Update src/Symfony/Component/Validator/Resources/translations/validators.pl.xlf
This PR was merged into the master branch.
Commits
-------
d5426f0 [Form] Add tests to prove that label is not rendered when is marked as false
120547c [Form][TwigBridge] Don't set label attributes if is marked as not to be rendered [Form][FrameworkBundle] Add option to disable rendering of label for fields
36e4556 [Form] Option for not displaying a label by setting label to false. [Form] Fixed formatting & translation ..
Discussion
----------
[Form] Added option for not displaying a form-label by setting label to false
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Replaces: #5421
@fabpot @BenjaminBeck: I was just not sure what to do with "table based" forms, so I left `<td></td>` rendered when there is no label, because I'm not sure that we can hide it easily.
---------------------------------------------------------------------------
by XWB at 2012-12-11T09:30:14Z
👍
* 2.1:
fixed CS
fixed CS
[Security] fixed path info encoding (closes#6040, closes#5695)
[HttpFoundation] added some tests for the previous merge and removed dead code (closes#6037)
Improved Cache-Control header when no-cache is sent
removed unneeded comment
Fix to allow null values in labels array
fix date in changelog
removed the Travis icon (as this is not stable enough -- many false positive, closes#6186)
Revert "merged branch gajdaw/finder_splfileinfo_fpassthu (PR #4751)" (closes#6224)
Fixed a typo
Fixed: HeaderBag::parseCacheControl() not parsing quoted zero correctly
[Form] Fix const inside an anonymous function
[Config] Loader::import must return imported data
[DoctrineBridge] Fixed caching in DoctrineType when "choices" or "preferred_choices" is passed
[Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
[HttpFoundation] fixed a small regression
Conflicts:
src/Symfony/Component/HttpFoundation/Tests/Session/Storage/Handler/MongoDbSessionHandlerTest.php
This PR was squashed before being merged into the master branch (closes#6232).
Commits
-------
7428bf9 [WebProfilerBundle] Some eye candy for deprecated calls
Discussion
----------
[WebProfilerBundle] Some eye candy for deprecated calls
.
@fabpot is [`|raw`](https://github.com/symfony/symfony/pull/new/deprecated#L0R117) a twig defect ?
---------------------------------------------------------------------------
by Baachi at 2012-12-08T09:12:12Z
Really nice 👍
---------------------------------------------------------------------------
by vicb at 2012-12-11T10:00:24Z
should be ready now
This PR was merged into the master branch.
Commits
-------
abe244f [TwigBundle] Fixed tests on windows
Discussion
----------
[TwigBundle] Fixed tests on windows
This PR was merged into the master branch.
Commits
-------
f48b22a Added configuration pass that adds Twig Loaders
Discussion
----------
[Twig] [DI Pass] Added configuration pass that adds Twig Loaders
Bug fix: [no]
Feature addition: [yes]
Backwards compatibility break: [no]
Symfony2 tests pass: [yes]
Todo: Documentation?
License of the code: MIT
- Defined new Chain loader service with symfony Filesystem loader added
by default.
- Added compiler class which picks up any services tagged "twig.loader"
- If there are any instances of "twig.loader" the "twig.loader" alias is
set to the Twig_Loader_Chain service ID instead of the filesystem
loader.
I think I still like the explicitness of the other pull request, but I defer to your judgment :) This is certainly much easier for the developer.
---------------------------------------------------------------------------
by dantleech at 2012-12-03T08:31:08Z
Will update the PR later today / tomorrow
---------------------------------------------------------------------------
by dantleech at 2012-12-03T18:19:09Z
ok, updated. I throw a `Symfony\Component\DependencyInjection\Exception\LogicException` if there are no loaders -- not sure if that is the best thing to do, or if that is the best exception.
---------------------------------------------------------------------------
by fabpot at 2012-12-05T15:28:24Z
Looks good to me. Can you add a note in the CHANGELOG about this new possibility and update the documentation accordingly? Thanks.
---------------------------------------------------------------------------
by dantleech at 2012-12-05T17:50:37Z
ok. updated change log and changed both count() comparisons to be strict. @fabpot which documentation should I update? or should I add `cookbook/templating/registering_multiple_loaders.rst`?
---------------------------------------------------------------------------
by stof at 2012-12-05T20:07:37Z
@dantleech at least the DIC tags reference need to be updated to mention the new tag. I'm not sure a dedicated article is needed for it (but @weaverryan will decide if it is worth it)
---------------------------------------------------------------------------
by dantleech at 2012-12-06T17:57:20Z
Made a PR for documentation: https://github.com/symfony/symfony-docs/pull/2005
---------------------------------------------------------------------------
by dantleech at 2012-12-07T16:44:00Z
ok. have updated the correct CHANGELOG and squashed to one commit
- Added compiler class which picks up any services tagged "twig.loader"
- If there is one loader registered we set the alias to this loader
- If there is more than one we set the alias to a chain loader and all
the loaders to it
- If there is no loaders we throw an Exception
This PR was squashed before being merged into the master branch (closes#5860).
Commits
-------
d0057d0 Added failure_path_parameter to mirror target_path_parameter
Discussion
----------
Added failure_path_parameter to mirror target_path_parameter
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
Enable login failure redirect path can be assigned in a form field just like target path.
---------------------------------------------------------------------------
by stof at 2012-10-29T09:40:17Z
Please also open a PR to the doc repo to document this new feature
---------------------------------------------------------------------------
by leevigraham at 2012-10-29T09:56:29Z
@stof @fabpot Done.
This PR was merged into the master branch.
Commits
-------
7f16c1f [HttpKernel] Add DI extension configs as ressources when possible
Discussion
----------
[HttpKernel] Add DI extension configs as ressources when possible
/cc @rdohms @richardmiller
---------------------------------------------------------------------------
by vicb at 2012-11-30T11:57:48Z
btw @fabpot what about having a base class for `Extension` in the DI ? Would make it easier to re-use it when using standalone components, Di and (the suggested) Config as the greatest part of the class is not HttpKernel specific.
---------------------------------------------------------------------------
by fabpot at 2012-12-06T08:47:28Z
@vicb your suggestion makes sense.
Can you also explain the goal of this PR?
---------------------------------------------------------------------------
by vicb at 2012-12-06T09:01:58Z
The goal of this PR is to avoid having to sfcc when you modify a DI extension configuration. I think @rdohms got trapped.
---------------------------------------------------------------------------
by vicb at 2012-12-06T09:08:08Z
see https://twitter.com/rdohms/status/274059267428978688
---------------------------------------------------------------------------
by stof at 2012-12-06T09:20:54Z
I thought about it several times but never took time to implement it. It is annoying to have to clear the cache when you modify a default value in the Configuration class. So +1
This PR was squashed before being merged into the master branch (closes#6083).
Commits
-------
6236c18 [FrameworkBundle] Added caching to TemplateController
Discussion
----------
[FrameworkBundle] Added caching to TemplateController
Because the main purpose for the `TemplateController` seems to be to render static pages like "disclaimer" and such, it seems useful to allow caching.
imprint:
pattern: /imprint
defaults:
_controller: SymfonyFrameworkBundle:Template:template
template: "::pages/imprint.html.twig"
maxAge: 86400
---------------------------------------------------------------------------
by pierredup at 2012-11-21T20:24:53Z
IMHO I think the caching should be allowed to be set optionally
---------------------------------------------------------------------------
by KingCrunch at 2012-11-21T20:38:54Z
I wrote it this way, because I assume, that it will cover more use-cases, than the other way round, but you are right, that this will change the current behaviour. Would like to hear other opinions, because I don't think one uses this action for anything else than fully-static content (means: The current behaviour doesn't feel very useful to me).
---------------------------------------------------------------------------
by pierredup at 2012-11-21T20:48:19Z
I totally agree, but I would then suggest keep the caching on by default, but have the option to turn it off if necessary
---------------------------------------------------------------------------
by pierredup at 2012-11-21T20:52:01Z
Actually I think to have caching permanently enabled for static content would probably be the best scenario, but I like to think in terms of flexibility and specific user requirements. It would be great to get some opinions from others on this
---------------------------------------------------------------------------
by KingCrunch at 2012-11-23T21:12:45Z
I thought about it and I come to the conclusion, that it is probably a not so good idea to enable caching by default, because ... well, it's not possible to disable it again. I guess something like this
{{ render '@AcmeBundle:ArticleController:latest' with {count: 1} }}
may be not so uncommon as I suggested in the first commit.
---------------------------------------------------------------------------
by fabpot at 2012-12-03T22:18:51Z
Can you make a PR for the docs? (symfony/symfony-docs). Thanks.
This PR was squashed before being merged into the master branch (closes#6173).
Commits
-------
4878ec0 [HttpKernel] [WebProfilerBundle] Better handling of deprecated methods
Discussion
----------
[HttpKernel] [WebProfilerBundle] Better handling of deprecated methods
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes, if you were expecting E_USER_DEPRECATED or E_DEPRECATED to throw an exception
Symfony2 tests pass: yes
Fixes the following tickets: #6139 partly, I'd go through and add the actual trigger_error() calls in another (or possibly one per component) PR
Todo: call trigger_error()
License of the code: MIT
Documentation PR: -
I added the deprecation count with the Exception icon in the Profiler Toolbar, and changed the color of it to be yellow for deprecations and red for exceptions (was yellow for exceptions).
---------------------------------------------------------------------------
by fabpot at 2012-12-03T09:43:09Z
Adding trigger_error calls should be done in one PR to ease the merging. thanks.
This PR was merged into the master branch.
Commits
-------
51223c0 added upgrade instructions
50e6259 adjusted tests
98f3ca8 [Routing] removed tree structure from RouteCollection
Discussion
----------
[Routing] removed tree structure from RouteCollection
BC break: yes (see below)
Deprecations: RouteCollection::getParent(); RouteCollection::getRoot()
tests pass: yes
The reason for this is so quite simple. The RouteCollection has been designed as a tree structure, but it cannot at all be used as one. There is no getter for a sub-collection at all. So you cannot access a sub-collection after you added it to the tree with `addCollection(new RouteCollection())`. In contrast to the form component, e.g. `$form->get('child')->get('grandchild')`.
So you can see the RouteCollection cannot be used as a tree and it should not, as the same can be achieved with a flat array!
Using a flat array removes all the need for recursive traversal and makes the code much faster, much lighter, less memory (big problem in CMS with many routes) and less error-prone.
BC break: there is only a BC break if somebody used the PHP API for defining RouteCollection and also added a Route to a collection after it has been added to another collection.
So
```
$rootCollection = new RouteCollection();
$subCollection = new RouteCollection();
$rootCollection->addCollection($subCollection);
$subCollection->add('foo', new Route('/foo'));
```
must be updated to the following (otherwise the 'foo' Route is not imported to the rootCollection)
```
$rootCollection = new RouteCollection();
$subCollection = new RouteCollection();
$subCollection->add('foo', new Route('/foo'));
$rootCollection->addCollection($subCollection);
```
Also one must call addCollection from the bottom to the top. So the correct sequence is the following (and not the reverse)
```
$childCollection->->addCollection($grandchildCollection);
$rootCollection->addCollection($childCollection);
```
Remeber, this is only needed when using PHP for defining routes and calling methods in a special order. There is no change required when using XML or YAML for definitions. Also, I'm pretty sure that neither the CMF, nor Drupal routing, nor Silex is relying on the tree stuff. So they should also still work.
cc @fabpot @crell @dbu
One more thing: RouteCollection wasn't an appropriate name for a tree anyway as a collection of routes (that it now is) is definitely not a tree.
Yet another point: The XML declaration of routes uses the `<import>` element, which is excatly what the new implementation of addCollection without the need of a tree does. So this is now also more analogous.
---------------------------------------------------------------------------
by Koc at 2012-11-26T17:34:15Z
What benefit of this?
---------------------------------------------------------------------------
by Tobion at 2012-11-26T17:56:53Z
@Koc Why did you not simply wait for the description? ^^
---------------------------------------------------------------------------
by dbu at 2012-11-26T18:33:09Z
i love PR that remove more code than they add whithout removing functionality.
---------------------------------------------------------------------------
by Crell at 2012-11-26T18:49:52Z
There's an issue somewhere in Drupal where we're trying to use addCollection() as a shorthand for iterating over one collection and calling add() on the other for each item. We can't do that, however, because the subcollections are not flattened properly when reading back and our current dumper can't cope with that. So this change would not harm Drupal at all, and would mean I don't have fix a bug in our dumper. :-) I cannot speak for any other projects, of course.
---------------------------------------------------------------------------
by Tobion at 2012-11-27T19:06:34Z
Ok, this is ready.
* 2.0:
[TwigBundle] Moved the registration of the app global to the environment
needs to use simpleContent in xsd to allow empty elements
bumped Symfony version to 2.0.19-DEV
removed wrong routing xsd statement `mixed="true"`
removed unused attribute from routing.xsd
updated VERSION for 2.0.19
update CONTRIBUTORS for 2.0.19
updated CHANGELOG for 2.0.19
Conflicts:
CONTRIBUTORS.md
src/Symfony/Bundle/TwigBundle/Resources/config/twig.xml
src/Symfony/Bundle/TwigBundle/TwigEngine.php
src/Symfony/Component/HttpKernel/Kernel.php
This makes the app global variable available also when accessing the Twig
environment directly instead of using the TwigEngine.
Conflicts:
src/Symfony/Bridge/Twig/CHANGELOG.md
src/Symfony/Bundle/TwigBundle/Resources/config/twig.xml
src/Symfony/Bundle/TwigBundle/TwigEngine.php
* 2.1: (29 commits)
[DependencyInjection] fixed composer.json
[Validator] Fix typos in validators.ru.xlf
Edited some minor grammar and style errors in russian validation file
Updated Bulgarian translation
[Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
[Form] simplified a test from previous merge
Update src/Symfony/Component/Form/Extension/Core/Type/FileType.php
fixed CS
Xliff with other node than source or target are ignored
small fix of #5984 when the container param is not set
Filesystem Component mirror symlinked directory fix
[Process][Tests] fixed chainedCommandsOutput tests
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
info about session namespace
fix upgrade info about locale
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
...
* 2.0:
[DependencyInjection] fixed composer.json
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
fixed CS
small fix of #5984 when the container param is not set
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
[Security] remove escape charters from username provided by Digest DigestAuthenticationListener
[Security] added test extra for digest authentication
fixed CS
[Security] Fixed digest authentication
[Security] Fixed digest authentication
[SecurityBundle] Convert Http method to uppercase in the config
Use Norm Data instead of Data
Conflicts:
src/Symfony/Bridge/Doctrine/Form/EventListener/MergeCollectionListener.php
src/Symfony/Bundle/FrameworkBundle/Controller/RedirectController.php
src/Symfony/Component/DependencyInjection/composer.json
This PR was merged into the master branch.
Commits
-------
c8e65a2 [FrameworkBundle][Routing] Resolve placeholders in hostnamePattern rules
Discussion
----------
[FrameworkBundle][Routing] Resolve placeholders in hostnamePattern rules
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #6135
License of the code: MIT
Currently the placeholders in the `hostname_pattern` rule are not resolved, so that's why this PR is it for.
---------------------------------------------------------------------------
by nomack84 at 2012-11-28T14:18:02Z
@fabpot Could you please merge this? I really need this fix to be solve.
Thanks!
In the previous form of twig's service definitions, it was impossible to
use a chain loader correctly because the TwigBundle was registering paths
on the twig.loader service. This patch fixes that by creating a
twig.loader.filesystem definition and an alias twig.loader that points
to twig.loader.filesystem by default.
this can happen when the config for the router is unset, but this method
does not need to depend on routing. reading an unset config would raise an exception.
This PR was merged into the 2.0 branch.
Commits
-------
64b54dc Use better default ports in urlRedirectAction
64216f2 Add tests for urlRedirectAction
Discussion
----------
Default to current port in urlRedirectAction
I was a bit surprised when I used urlRedirectAction from a non-standard port (8000) it redirected me to port 80. I would argue that the default should be to use the current port instead. This is a simple patch to change that. This should only break in the case someone is relying on the current default to redirect from a non-standard port to the standard port, which should be a really rare case...
---------------------------------------------------------------------------
by Tobion at 2012-11-11T20:29:54Z
The idea is right but the implementation not. Seems this patch is not as "simple" as you said.
When you're on HTTPS and want to redirect to $scheme = HTTP, then it still uses the current HTTPS port which is wrong.
---------------------------------------------------------------------------
by flojon at 2012-11-11T20:36:47Z
Ah, I see the problem. So I guess the correct behavior would be to use the current port if staying with the same scheme or go to standard port if switching scheme. Unless the user has specified a port which will always override...
---------------------------------------------------------------------------
by Tobion at 2012-11-11T20:42:18Z
That would be the best solution that is currently possible but not the best solution that should be possible.
Because if you switch scheme but the other scheme does not use the standard port, it still doesn't work.
Ideally the Request class had an option that allows to define the ports symfony should use for HTTP and HTTPS.
This logic is in RequestContext, but it's not used here.
---------------------------------------------------------------------------
by flojon at 2012-11-11T21:32:55Z
Bummer, I forgot to check if the current port is a standard port...
---------------------------------------------------------------------------
by Tobion at 2012-11-11T21:35:13Z
add some tests
---------------------------------------------------------------------------
by flojon at 2012-11-11T23:28:18Z
Added tests and fixed my previous error
---------------------------------------------------------------------------
by flojon at 2012-11-15T18:25:12Z
@Tobion is there anything else I needed for this?
---------------------------------------------------------------------------
by fabpot at 2012-11-19T12:56:04Z
To be consistent with how we manage HTTP ports elsewhere, I'd rather use the values of the `request_listener.http_port` and `request_listener.https_port`:
```php
if (null === $httpPort) {
$httpPort = $this->container->getParameter('request_listener.http_port');
}
if (null === $httpsPort) {
$httpsPort = $this->container->getParameter('request_listener.https_port');
}
```
This is done in the `security.authentication.retry_entry_point` service and for the `router_listener` listener.
The parameter name is probably not the best one, but that could be changed then in master.
---------------------------------------------------------------------------
by flojon at 2012-11-19T13:49:18Z
@fabpot But then you would need to set that parameter manually right? It wouldn't automatically redirect you to the same port, which was what I wanted to achieve...
Could this be the right order of preference:
If a value was specified in the route use that.
Otherwise use the current port
unless switching scheme then use the parameter value
---------------------------------------------------------------------------
by fabpot at 2012-11-19T13:52:17Z
Your order of preference looks good to me.
---------------------------------------------------------------------------
by flojon at 2012-11-19T19:13:19Z
Man this was more involved than I thought... :)
Changed the logic to use the parameters when not using the current port. Also tried clean up the tests a little bit... Enjoy!
This PR was merged into the master branch.
Commits
-------
9f1cd84 moved most static assets directly into the templates
Discussion
----------
moved most static assets directly into the templates
This has been done for several reasons:
* for consistency with the way we already manage the WDT and the
profiler icons;
* it makes the Exception independent from the location of the assets
(and from the asset() function)
* this is the second step to make the WebProfiler useable outside the
full-stack framework
see dbcd171dd3
---------------------------------------------------------------------------
by stof at 2012-11-13T17:52:39Z
the images blue_picto_more and blue_picto_less are also used in DoctrineBundle (and probably in JMSDebuggingBundle but I haven't checked). Could you submit a PR inlining the images too before removing them ?
---------------------------------------------------------------------------
by fabpot at 2012-11-13T18:02:18Z
Any image useful for other bundles should not be deleted. So, if DoctrineBundle is using the blue_pico_* images, I'm going to revert their deletion.
---------------------------------------------------------------------------
by schmittjoh at 2012-11-13T18:07:02Z
I'm using them in two bundles, JMSDebuggingBundle and JMSJobQueueBundle (same for the exception related templates).
---------------------------------------------------------------------------
by dlsniper at 2012-11-13T22:22:29Z
Wouldn't it be better to have the encoded icons in a separate CSS file as different classes/background images?
---------------------------------------------------------------------------
by fabpot at 2012-11-14T11:28:24Z
ok, I've reverted the removal of the images that might be useful in third-party bundles.
This has been done for several reasons:
* for consistency with the way we already manage the WDT and the
profiler icons;
* it makes the Exception independent from the location of the assets
(and from the asset() function)
* this is the second step to make the WebProfiler useable outside the
full-stack framework
see dbcd171dd3
* 2.1: (24 commits)
forced Travis to use source to workaround their not-up-to-date Composer on PHP 5.3.3
[Routing] removed irrelevant string cast in Route
Fixed typo
Make YamlFileLoader and XmlFileLoader file loading extensible
[HttpKernel] fix typo
Fixed singularization of "prices"
[Form] Removed an exception that prevented valid formats from being passed, e.g. "h" for the hour, "L" for the month etc.
[HttpKernel] fixed Client when using StreamedResponses (closes#5370)
fixed PDO session handler for Oracle (closes#5829)
[HttpFoundation] fixed PDO session handler for Oracle (closes#5829)
[Locale] removed a check that is done too early (and it is done twice anyways)
Update src/Symfony/Component/Validator/Resources/translations/validators.fa.xlf
Adding new localized strings for farsi validation.
[HttpFoundation] moved the HTTP protocol check from StreamedResponse to Response (closes#5937)
[Form] Fixed forms not to be marked invalid if their children are already marked invalid
[Form] Excluded some tests in NumberToLocalizedStringTransformerTest which fail on ICU 4.4, but work on ICU 4.8
added missing tests from previous merge
[Form] Fixed NumberToLocalizedStringTransformer to accept both comma and dot as decimal separator, if possible
Fix export-ignore on Windows
Show correct class name InputArgument in error message
...
Conflicts:
.travis.yml
src/Symfony/Component/Form/Extension/Core/DataTransformer/NumberToLocalizedStringTransformer.php
The goal is to make things more decoupled and more reusable across
different bundles.
There will be a PR for the distribution bundle too to simplify the code
based on this PR.
This PR was merged into the master branch.
Commits
-------
56fe8d1 duplicated the code helper code to the Twig bundle
Discussion
----------
moved code helper code to the Twig bundle
These helpers are very specific and are only used in TwigBundle for the
profiler and the exception templates.
---------------------------------------------------------------------------
by schmittjoh at 2012-11-12T09:12:56Z
Is there a reason for this BC break other than a cosmetical tweak?
If not strictly necessary, I'd like to see these kind of changes being scheduled for 3.0.
---------------------------------------------------------------------------
by fabpot at 2012-11-12T09:29:35Z
Of course, I don't want to make this change without a reason and indeed, I forgot to mention the why of this change. Let me explain.
I've been working on the integration of the Symfony web profiler into other OSS that use HttpKernel like Silex and Drupal for quite some time now. That's why I developed the new namespace feature in Twig, that's why I've refactored the web profiler to only use Twig and not the templating component. One of the last step is this PR, which reduces the number of dependencies to be able to use the WebProfiler bundle.
So, this change is not cosmetic, but one more step towards the goal of making the web profiler more reusable.
---------------------------------------------------------------------------
by schmittjoh at 2012-11-12T13:22:28Z
I see, makes sense. How about duplicating the code for now?
After looking through the history, it doesn't seem like it changes often
(the last real code change was a year ago). So, it should not be much more
maintenance effort, and we could keep BC here.
On Mon, Nov 12, 2012 at 10:29 AM, Fabien Potencier <notifications@github.com
> wrote:
> Of course, I don't want to make this change without a reason and indeed, I
> forgot to mention the why of this change. Let me explain.
>
> I've been working on the integration of the Symfony web profiler into
> other OSS that use HttpKernel like Silex and Drupal for quite some time
> now. That's why I developed the new namespace feature in Twig, that's why
> I've refactored the web profiler to only use Twig and not the templating
> component. One of the last step is this PR, which reduces the number of
> dependencies to be able to use the WebProfiler bundle.
>
> So, this change is not cosmetic, but one more step towards the goal of
> making the web profiler more reusable.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/5986#issuecomment-10281201>.
>
>
---------------------------------------------------------------------------
by fabpot at 2012-11-12T13:32:33Z
Of course, that's a possibility. But what for? I doubt that people are using this code. Are you using this code somewhere?
---------------------------------------------------------------------------
by schmittjoh at 2012-11-12T13:37:24Z
Yes, I believe that I'm using it both in JMSDebuggingBundle, and
JMSJobQueueBundle as both are rendering exception stack traces at some
point.
On Mon, Nov 12, 2012 at 2:32 PM, Fabien Potencier
<notifications@github.com>wrote:
> Of course, that's a possibility. But what for? I doubt that people are
> using this code. Are you using this code somewhere?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/5986#issuecomment-10287353>.
>
>
---------------------------------------------------------------------------
by fabpot at 2012-11-12T14:11:50Z
ok, fair enough. The code is now in the framework bundle as well.
The code has been duplicated and not moved for BC reasons.
This code has been duplicated in the Twig bundle to be able to decouple
the web profiler and the exception templates.
* 2.1:
removed unused use statements
[Form] Adapted HTML5 format in DateTimeType as response to a closed ICU ticket
[2.1][HttpFoundation] Fixed Php doc in Request::get
bumped Symfony version to 2.1.4-DEV
updated VERSION for 2.1.3
update CONTRIBUTORS for 2.1.3
updated CHANGELOG for 2.1.3
merged branch jakzal/yamlDoubleQuotesDumperFix (PR #4320)
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
This PR was merged into the master branch.
Commits
-------
aecc9b1 fixed tests when OpenSsl is not enabled in PHP, renamed a missnamed test, added missing license doc blocks
ca567b5 fixed CS
5cdf696 added a SecureRandomInterface
234f725 rename String to StringUtils
5849855 moved the secure random dep for remember me as a constructor argument
248703f renamed Prng to SecureRandom
c0c8972 simplified the Prng code
e5dc7af moved the secure random class from JMSSecurityExtraBundle to Symfony (closes#3595)
Discussion
----------
[2.2][Security] Add a PRNG (closes#3595)
As per #3595, I have moved the secure random class from JMSSecurityExtraBundle to Symfony.
It has more impact than I expected ;)
As you will see, the implementation has been refactored a bit. The most notable change is that Doctrine support has been moved to the bridge with the addition of a proper Doctrine seed provider (Doctrine is not a special case anymore).
The Doctrine configuration has been moved to the DoctrineBundle: doctrine/DoctrineBundle#91schmittjoh/JMSSecurityExtraBundle#65 removes the code that has been moved.
---------------------------------------------------------------------------
by Seldaek at 2012-07-05T13:26:01Z
I'm all for more security features, and both the String class & the Prng class for wrapping openssl make a lot of sense IMO, but I fail to see the use of the rest.
If we just want a seed to have a fallback in case openssl is missing, I'd rather have a secret in the config.yml than a million classes to store the same secret in the DB. Maybe I'm missing something though? /cc @schmittjoh
---------------------------------------------------------------------------
by schmittjoh at 2012-07-05T16:32:10Z
Having the configuration in different places (SecurityBundle & DoctrineBundle) feels a bit weird. I would prefer an approach similar to ACL, or the user provider/firewall section with factories. The latter being a bit more work to implement and the former potentially asking for complaints about too tight coupling to Doctrine.
Regarding testing, we probably need to move the disableOpenSsl method to the SecureRandom class in order to allow OpenSSL to be disabled for testing and we also need to change the byte generation algorithm to produce the same output for the same starting seed. I agree that it does not make sense to introduce an interface for SecureRandom as only the seed providers should be replaced.
As for the seed itself, it is constantly updated and does not stay the same as in the beginning. Thus, we need a provider that we can write to, and not only read from. I'm also not sure about using OpenSSL on Windows as I have read enough resources which claimed that the entropy on Windows is not always good (including OpenSSL docs). Always using the custom seed provider at least always ensured proper entropy even if OpenSSL's speed issues have been fixed in newer PHP versions.
---------------------------------------------------------------------------
by stof at 2012-07-05T16:44:24Z
@schmittjoh everything is in SecurityBundle now as it does not use a database anymore
---------------------------------------------------------------------------
by stof at 2012-07-05T16:44:59Z
and there is no seed provider anymore either
---------------------------------------------------------------------------
by schmittjoh at 2012-07-05T16:53:39Z
Not having a seed provider is not such a good idea, but having a file-based seed provider is.
---------------------------------------------------------------------------
by Seldaek at 2012-07-05T17:01:18Z
@schmittjoh why would you need to replace the seed provider? Don't you think that people serious about security to the point that they would want a stronger seed provider would enable openssl instead?
---------------------------------------------------------------------------
by stof at 2012-07-05T17:06:50Z
Well, what I meant is that there is no interchangeable provider anymore. The Prng class uses the file directly.
And btw, I think the Prng class should be mockable for tests, so it should either have an interface or not be final (I vote for adding an interface)
---------------------------------------------------------------------------
by jalliot at 2012-07-09T18:46:12Z
@fabpot @schmittjoh What about using more fallbacks for `openssl_random_pseudo_bytes` like in @Seldaek's post ["Unpredictable hashes for humans"](http://seld.be/notes/unpredictable-hashes-for-humans)?
Trying `mcrypt_create_iv` first might also be faster.
---------------------------------------------------------------------------
by Seldaek at 2012-07-10T08:52:46Z
@jalliot I think mcrypt should be after if you make it use /dev/urandom, not 100% sure but openssl is probably higher quality than urandom.
---------------------------------------------------------------------------
by schmittjoh at 2012-07-10T09:12:07Z
The fallback algorithm that I added should be enough (it passes the
statistical randomness tests).
On Tue, Jul 10, 2012 at 10:52 AM, Jordi Boggiano <
reply@reply.github.com
> wrote:
> @jalliot I think mcrypt should be after if you make it use /dev/urandom,
> not 100% sure but openssl is probably higher quality than urandom.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/4763#issuecomment-6870145
>
---------------------------------------------------------------------------
by stof at 2012-10-13T17:20:06Z
@fabpot please send a PR to the doc so that this can be merged 😃
---------------------------------------------------------------------------
by stof at 2012-10-13T17:22:08Z
hmm, actually, some comments have not been taken into account yet so it is not ready to be merged
---------------------------------------------------------------------------
by stof at 2012-10-27T07:14:43Z
you forgot the SecureRandom file
---------------------------------------------------------------------------
by fabpot at 2012-10-27T08:49:54Z
I think I've addressed all the comments. If everyone agree with the current implementation, I'm going to start updating the documentation.
---------------------------------------------------------------------------
by fabpot at 2012-10-27T10:51:15Z
I've fixed the remaining CS issues.
---------------------------------------------------------------------------
by fabpot at 2012-10-28T07:00:31Z
Documentation is here: symfony/symfony-docs#1858
This PR was merged into the 2.1 branch.
Commits
-------
3553276 [ConfigDumpReference] avoid notice for variable nodes
Discussion
----------
[ConfigDumpReference] avoid notice for variable nodes
When a variable node has an array as default value, a notice occurs later on because of an "array to string conversion", which is turned to an exception in debug mode (mandatory in order to run this command).
* 2.1: (28 commits)
Delete use of CreationExeption
[Form] Fixed error message in PropertyPath to not advice to use a non-existing feature
[Form] Fixed creation of multiple money fields with different currencies
[Form] Fixed setting the "data" option to an object in "choice" and "entity" type
Fixed Serbian plural translations.
Fixed IPv6 Check in RequestMatcher
Fix typo
change what I think is a typo
[Console] Fix error when mode is not in PATH
[WebProfilerBundle] fixed macro usage (to be forward compatible with Twig 2.x)
Change monolog require-dev to use the branch alias instead of dev-master
[FrameworkBundle] partially reverted previous merge
[2.1] Added missing error return codes in commands
Made the router lazy when setting the context
[WebProfilerBundle] fixed typos
Fix incorrect variable in FileProfilerStorage
UnitTest fix
UnitTest fix
added a unit test
fixed#5384
...
This PR was squashed before being merged into the 2.1 branch (closes#5586).
Commits
-------
6b66bc3 [2.1] Added missing error return codes in commands
Discussion
----------
[2.1] Added missing error return codes in commands
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
See: #5585
---------------------------------------------------------------------------
by fabpot at 2012-09-24T12:10:47Z
Exit code values are standardized and some values have some well-defined meaning. Have a look here for more info: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Process/Process.php#L67
This PR was merged into the master branch.
Commits
-------
b31ae34 [WebProfilerBundle] Remove the now unneeded BC var and fixed a typo
d07ce03 [TwigBundle] Moved the registration of the app global to the environment
Discussion
----------
[TwigBundle] Moved the registration of the app global to the environment
This makes the app global variable available also when accessing the Twig
environment directly instead of using the TwigEngine.
The controllers are not relying on the DIC anymore and only Twig
is used for rendering (instead of the Templating component).
The Exception controller has not been updated yet as it relies on many
external dependencies (and other bundles).
This has been done for several reasons:
* for consistency with the way we already manage the WDT icons;
* it makes the WebProfiler independant from the location of the assets (and from the asset() function)
* this is the very first step to make the WebProfiler useable outside the full-stack framework (more commits soon)
There is still one asset() call though, which will be removed later on.
[Security] changed default iterations of Pbkdf2PasswordEncoder to 1000 instead of 5000
[Security] Improved description of PBKDF2 encoder
[SecurityBundle] added PBKDF2 PasswordEncoder
updated CHANGELOG.md
[Security] Use the build-in hash_pbkdf2() when available
[SecurityBundle] added information about hash_algorithm for configuration
[Security] always check algorithm and fixed CS
* 2.1:
fixed CS
added doc comments
added doc comments
[Validator] Updated swedish translation
Update src/Symfony/Component/Validator/Resources/translations/validators.de.xlf
[2.1] Exclude tests from zips via gitattributes
[HttpKernel][Translator] Fixed type-hints
Updated lithuanian validation translation
[DomCrawler] Allows using multiselect through Form::setValues().
[Translation] forced the catalogue to be regenerated when a resource is added (closes symfony/Translation#1)
Unit test for patched method OptionsResolver::validateOptionValues().
validateOptionValues throw a notice if an allowed value is set and the corresponding option isn't.
[Form] Hardened code of ViolationMapper against errors
[HttpFoundation] Fixed#5611 - Request::splitHttpAcceptHeader incorrect result order.
[Form] Fixed negative index access in PropertyPathBuilder
Update src/Symfony/Component/Validator/Resources/translations/validators.ro.xlf
Conflicts:
src/Symfony/Component/DomCrawler/Form.php
src/Symfony/Component/Process/Process.php
This PR was merged into the master branch.
Commits
-------
4b86765 [FrameworkBundle] recursively resolve container parameter placeholders for arrays in router _defaults
Discussion
----------
[2.2] [FrameworkBundle] avoid trying to resolve container placeholders on arrays on router _defaults
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~
Permits to pass arrays in route `_defaults`.
---------------------------------------------------------------------------
by stof at 2012-07-20T13:07:36Z
This seems weird. An array could contain parameters in it.
---------------------------------------------------------------------------
by docteurklein at 2012-07-20T13:17:00Z
@stof An object too then, no ? Why accepting objects but not arrays ? Would you propose to recursively resolve array values ?
---------------------------------------------------------------------------
by stof at 2012-07-20T13:31:06Z
@docteurklein Resolving array values recursively would be consistent with the way the DIC parameters are resolved. I don't really see how you would resolve objects (and btw, it is pretty much an edge case as you cannot really put an object in your routes if you define them in your YAML or XML config files or with annotations)
---------------------------------------------------------------------------
by docteurklein at 2012-07-20T13:36:43Z
@stof I agree. I can manage recursive array resolving if needed.
---------------------------------------------------------------------------
by fabpot at 2012-07-23T13:58:07Z
Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by docteurklein at 2012-07-23T14:39:17Z
@fabpot done.
In a template, you can now use native Twig template names, instead of
the Symfony ones:
Before (still works):
{% extends "AcmeDemoBundle::layout.html.twig" %}
{% include "AcmeDemoBundle:Foo:bar.html.twig" %}
After:
{% extends "@AcmeDemo/layout.html.twig" %}
{% include "@AcmeDemo/Foo/bar.html.twig" %}
Using native template names is also faster.
The only drawback is that the new notation looks similar to the way we
locate resources in Symfony, which would be
@AcmeDemoBundle/Resources/views/Foo/bar.html.twig. We could have used
the same notation, but it is rather verbose (and by the way, using this
notation did not work anyway in templates).
The ContainerAwareTraceableEventDispatcher class was tied to both the
Symfony container and the HttpKernel profiler. It made it non reusable
in another context.
The new TraceableEventDispatcher only keeps the HttpKernel profiler
integration and is able to wrap any other event dispatcher. It makes it
reusable in frameworks using the Symfony HttpKernel component like
Silex.
The only drawback is that we don't have access to the listener
priorities in the collected data anymore (but the listeners are still
ordered correctly). The change is still worth it I think.
This PR was squashed before being merged into the master branch (closes#5518).
Commits
-------
3303ca2 WPB and WDT improvements
be194cb Changed icons to be a bit more consistent
08241b8 Added minimize option to Web Profiler panels
Discussion
----------
[2.2][WebProfilerBundle] Added minimize option to Web Profiler panels
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~
I've added a minimize option to the profiler bundle so that you can have more space to work with on the panels.
You can view it in action here:http://sf2demo.rodb.ro/app_dev.php/
Feedback is welcomed!
Thanks!
---------------------------------------------------------------------------
by dlsniper at 2012-09-15T13:36:51Z
I could add a remember option via a cookie if you think this would help, I know I'd want one, but I'm not sure about the general opinion about this. Let me know if I should do it.
---------------------------------------------------------------------------
by stof at 2012-09-15T17:05:58Z
The profiler is totally broken when minimizing the menu in your demo.
---------------------------------------------------------------------------
by lennerd at 2012-09-15T17:10:54Z
I would not make it disappear completely. So I think a combination of Cookie and a small visual for open it again would be great to have.
---------------------------------------------------------------------------
by dlsniper at 2012-09-15T17:15:06Z
@stof I've only enabled a few panels to work in the demo, rest defaults to DB panel. If this is what you mean then it's not broken, it's designed to do so. I've tested the thing on Opera, FF and Chrome (on Linux) before uploading the demo/PR so I'm not sure what's broken. Can you please provide a screenshot?
@lennerd I could be doing something like only display it in the upper left corner and appear on mouse over as an overlay. Would that be better?
---------------------------------------------------------------------------
by stof at 2012-09-15T17:21:22Z
@dlsniper what I mean is that the text of the menu does not disappear. It simply goes over the panel itself as the menu becomes smaller. And this appears for all panels I tried.
---------------------------------------------------------------------------
by stof at 2012-09-15T17:22:32Z
hmm, sorry. It is a browser cache issue. It seems like your server was sending cache headers for the assets, and as I already looked at the demo previously (for your DoctrineBundle PR), it kept the old CSS
---------------------------------------------------------------------------
by dlsniper at 2012-09-15T17:25:09Z
@stof no problem, the server is configured a bit more on caching side in order to speed it up and save bandwidth ;)
---------------------------------------------------------------------------
by lennerd at 2012-09-15T17:38:41Z
@dlsniper I would use the close button changing to maybe an arrow in the bottom right. So it's more intuitive and you can simply show and hide it if you only want to take a quick look at a small detail behind it.
---------------------------------------------------------------------------
by henrikbjorn at 2012-09-15T18:08:02Z
What about making this the default, the icons are self explanatory already. The title would then be the "link" text instead.
---------------------------------------------------------------------------
by dlsniper at 2012-09-15T20:30:51Z
@henrikbjorn I wouldn't make this by default as new people might find it a bit confusing. Hence the suggestion to use the cookie to remember the preference.
---
Also I'm trying not to break the current format of the menu too much as hiding all that stuff by hand is pain but if I'm allowed to break the current way of displaying the left menu then this is going to be easy.
What I didn't understood so far is why is the toolbar displayed on the top as well since we have it on the left side already so I've remove it from my current changes (will be up soonish).
---------------------------------------------------------------------------
by dlsniper at 2012-09-15T21:10:03Z
@lennerd what exactly do you mean by 'I would use the close button' there's no close button on the profiler page, only on the toolbar.
---------------------------------------------------------------------------
by lennerd at 2012-09-15T21:21:20Z
That was the button I was talking about. So that there is a little close button at the bottom right for toggling the toolbar.
---------------------------------------------------------------------------
by dlsniper at 2012-09-15T23:14:06Z
I've changed the way the menu minimizes now, it hides in the top left corner and it maintains its state on refresh. I'll do something similar for the toolbar tomorrow.
You can view it on the same URL.
Please do leave feedback. Thanks!
---------------------------------------------------------------------------
by lennerd at 2012-09-16T01:02:27Z
Sorry. I misunderstand your PR.
---------------------------------------------------------------------------
by stof at 2012-09-16T03:01:06Z
@dlsniper The toolbar is displayed at the top because it gives a quick overview without having to go in each panel. So removing it is a bad idea IMO.
And hiding everything is a bad idea IMO. It means navigating is impossible, making it usable when minimizing it (and btw, this would make the cookie a non-sense as it would hide the menu for subsequent pages)
---------------------------------------------------------------------------
by fabpot at 2012-09-16T06:38:08Z
-1 for removing the toolbar at the top
I prefer the first version where you only hide the menu text but leave the icons. Keeping the state in a cookie is also a must (that cookie might be used to store some other states in the profiler too).
---------------------------------------------------------------------------
by Partugal at 2012-09-16T08:14:11Z
i'm not see first version but show icons without text is more useful.
imho minimize trigger should be always placed on top as it showns in minized state
---------------------------------------------------------------------------
by Partugal at 2012-09-16T08:24:49Z
http://s14.postimage.org/qkdcr8d4h/image.png
---------------------------------------------------------------------------
by dlsniper at 2012-09-16T09:06:50Z
@fabpot I've just had a look on how the timeline stores the selected value and it's using the local storage capabilities. Should I drop the cookie and use the local storage as well to have some sort of uniformity?
Also is there any reason why no generic JS library is used? I'm thinking now about jQuery mostly but any other should do just fine I think. I'm not saying that we should use a library when displaying the WDT as it might bump into issues with the frontend but for the rest of the profiler I guess it wouldn't be a problem to use a library, no?
---------------------------------------------------------------------------
by fabpot at 2012-09-16T09:15:37Z
Let's use the local storage for better consistency. I don't want to embed a JS library as we only need basic JS scripts.
---------------------------------------------------------------------------
by lennerd at 2012-09-16T10:29:20Z
@dlsniper Do we need the up and down arrows any longer?
---------------------------------------------------------------------------
by dlsniper at 2012-09-16T14:24:27Z
I've added a minimize mode to the toolbar but the 'design' isn't the best all around, I'll try to improve it in the future.
It also remembers the state of the toolbar so that you don't need to hide it every time.
@lennerd we don't need the up/down arrows for now, I've removed on the last commit. Thank you for the new icons ;)
L.E.
I've made some sort of rounded corner/gradient background in for the minimized toolbar
---------------------------------------------------------------------------
by dlsniper at 2012-09-18T22:02:35Z
@pborreli thanks for the idea regarding to auto-minimize on window resize, I'll implement it soon, I don't really have time right now to add the event handling part to Sfjs.
L. E.
I'm not going to implement the auto-resize as it proved not to be that useful given the fixed width of the panel. If it proves to be a requested thing then I'll improve it if no one else does it before me :)
---------------------------------------------------------------------------
by dlsniper at 2012-09-19T20:52:43Z
If there's nothing else left to be changed/improved/added, I'll lift the WIP tag of this PR so that it can be merged if you consider it.
@fabpot, if this gets its way to the repository, should I rebase this before merging so that it catches the next Symfony 2.1 release as it doesn't break anything? I don't mean the very next release which I've read that it would be done when Doctrine will release their new version but the version after that.
---------------------------------------------------------------------------
by fabpot at 2012-09-19T20:56:45Z
This is a new feature, so it can only be included in the master branch.
---------------------------------------------------------------------------
by dlsniper at 2012-09-23T12:27:41Z
As soon as this feature goes in master I'll start working on adding AJAX requests to the toolbar to make it even more useful.
Let me know if this change is good to merge or needs more work.
Thanks @stof for all the input and @lennerd for the icons.
---------------------------------------------------------------------------
by stof at 2012-09-23T13:40:38Z
Adding which ajax requests to the toolbar ?
---------------------------------------------------------------------------
by dlsniper at 2012-09-23T13:49:43Z
'Userland' AJAX requests, so that one could access the information from an AJAX request more straight forward
* 2.1:
Added Base64 encoding, decoding to MongoDBProfilerStorage
Fix duplicated code and a field name
refactor src/Symfony/Component/Translation/Loader/MoFileLoader.php
fixed typo
Update src/Symfony/Component/Validator/Resources/translations/validators.pl.xlf
fixed issue #5596 (Broken DOM with the profiler's toolbar set in position top)
[Form] Fixed the testsuite for PHPUnit 3.6 as travis still uses it
added dirs generated by build-data.php in locale component to .gitignore
[Process] Fixed bug introduced by 7bafc69f38.
[Process][Tests] Prove process fail (Add more test case)
[Process][Tests] Prove process fail
[HttpFoundation] Fixed the tests
[DomCrawler] Added test for supported encodings by mbstring
[Config] Fixed preserving keys in associative arrays
[Console] Fixed return value for Command::run
[Locale] Fixed tests
[Console] Fix some input tests
[Filesystem] Fixed tests on Windows
[Config] Fixed tests on Windows
Commits
-------
22e9036 updated CHANGELOG
bafe890 [FrameworkBundle] changed Client::enableProfiler() behavior to fail silently when the profiler is not available (it makes it easier to write functional tests)
f41872b [FrameworkBundle] added a way to enable the profiler for the very next request in functional tests (closes#4307)
67b91e5 [HttpKernel] added a way to enable a disable Profiler
Discussion
----------
[2.2] added a way to enable the profiler for the very next request in a functional test
Bug fix: yes/no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4307
Todo: -
License of the code: MIT
Documentation PR: should be done before merging
After merging this PR, we need to disable the profiler in the test environment in Symfony SE.
* 2.1:
Create CONTRIBUTING.md file for auto-linking in PR's
Added Bulgarian translation
[Profiler]Use the abstract method to get client IP
Typo fix
Fixing incorrect word in twig:lint command description
Rename $key parameter to $name for consistency
=Minor chnage: replaced function by method
Fixed the phpdoc in the DependencyInjection component
Commits
-------
3f8127c fixed '0' problem
7bec460 fixed phpdoc
4c5bfab [FrameworkBundle] non-permanent redirect should be status code 404 according to spec
Discussion
----------
[FrameworkBundle] non-permanent redirect to unknown location with 404
according to spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html see 410 Gone
bc break: tiny when omitting 2 parameter (I can avoid this with `func_num_args` but i think its not necessary and makes the code strange and inconsistent)
* 2.0:
updated VERSION for 2.0.17
updated CHANGELOG for 2.0.17
updated vendors for 2.0.17
fixed XML decoding attack vector through external entities
prevents injection of malicious doc types
disabled network access when loading XML documents
refined previous commit
prevents injection of malicious doc types
standardized the way we handle XML errors
Redirects are now absolute
Conflicts:
CHANGELOG-2.0.md
src/Symfony/Component/DependencyInjection/Loader/XmlFileLoader.php
src/Symfony/Component/DomCrawler/Crawler.php
src/Symfony/Component/HttpKernel/Kernel.php
tests/Symfony/Tests/Component/DependencyInjection/Loader/XmlFileLoaderTest.php
tests/Symfony/Tests/Component/Routing/Loader/XmlFileLoaderTest.php
tests/Symfony/Tests/Component/Serializer/Encoder/XmlEncoderTest.php
tests/Symfony/Tests/Component/Translation/Loader/XliffFileLoaderTest.php
tests/Symfony/Tests/Component/Validator/Mapping/Loader/XmlFileLoaderTest.php
vendors.php
Commits
-------
85a53c1 [FrameworkBundle] fixed *FrameworkExtensionTest::testTranslator fail on Windows on master branch
Discussion
----------
[FrameworkBundle] fixed *FrameworkExtensionTest::testTranslator fail on Windows on master branch
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5345
Todo: -
License of the code: MIT
Documentation PR:
fixed using some
str_replace('/', DIRECTORY_SEPARATOR, <value>)
so it works on Windows because it replaces the / in \ and shouldn't affect linux based OS, since it will replace / with /.
Not very nice, but it works, if anyone wants to do better, he/she is most welcome.
Commits
-------
933e821 Add minimum-stability (dev) in each component
Discussion
----------
Add minimum-stability (dev) in each component
This fixes the ability to run the test suite in each component if a `composer install` is needed.
---------------------------------------------------------------------------
by stof at 2012-08-22T13:57:14Z
If you really want to run the testsuite standalone, some dev requirements are missing (SecurityBundle needs the FrameworkBundle for its functional tests for instance). If you have some time to check the missing dev requirement, it would be great.
Anyway, 👍 for this
---------------------------------------------------------------------------
by willdurand at 2012-08-22T13:59:15Z
Yes I already did that once. I'll try to fix more components later.
On Wed, Aug 22, 2012 at 3:57 PM, Christophe Coevoet <
notifications@github.com> wrote:
> If you really want to run the testsuite standalone, some dev requirements
> are missing (SecurityBundle needs the FrameworkBundle for its functional
> tests for instance). If you have some time to check the missing dev
> requirement, it would be great.
> Anyway, [image: 👍] for this
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/5318#issuecomment-7934886>.
>
>
---------------------------------------------------------------------------
by stof at 2012-08-22T14:02:23Z
Well, I think most components should be good now (as some work has been done on them). But the bridges and bundles may need some work (bundles were not having any dev requirements until yesterday when @guilhermeblanco added some on FrameworkBundle)
---------------------------------------------------------------------------
by pborreli at 2012-08-22T14:14:00Z
what about having for each READ-ONLY repo his own .travis.yml and travisci hook activated ?
---------------------------------------------------------------------------
by fabpot at 2012-08-22T14:30:13Z
please, don't add more travis files. The main already tests everything, and that's all we need.
---------------------------------------------------------------------------
by stof at 2012-08-22T14:33:46Z
@pborreli tests should not be different for subtree split repos as the code is the same and the tests are the same (except that more tests could be skipped because of missing deps).
Note that for the bundles, it is likely to be different currently as I think some skip tests are missing (just like dev requirements are). But fixing this does not require enablign travis.
---------------------------------------------------------------------------
by pborreli at 2012-08-22T14:42:30Z
ok, i was just thinking about a way to be sure each component is usable individually but yeah that would require to relaunch each tests and add a bunch of travis files + hook
---------------------------------------------------------------------------
by hason at 2012-08-24T13:12:04Z
@stof, @eriksencosta, @fabpot: Tests are different for Locale component, see #5235
---------------------------------------------------------------------------
by stof at 2012-08-24T13:35:07Z
@hason no. You also need to do it when running the tests of the Locale component as part of the full run.
Commits
-------
9c20634 fixes pre for var_dump with xdebug
Discussion
----------
Displaying var_dump with xdebug in exceptions
When debugging code I often use `var_dump` to quickly look into variables. Since 2.1 alle output generated by `var_dump` is displayed in one line. http://screencast.com/t/11LuIlIdHsvP
It seems to be no problem for small objects, but it becomes a real pain when displaying huge arrays or objects.
This is caused by the changed word-wrapping for the pre tag introduced in #3827
With fix: http://screencast.com/t/GdA3dkpWxU
---------------------------------------------------------------------------
by dlsniper at 2012-08-17T17:22:38Z
👍
Commits
-------
cdfbe72 handle inheritance in config:dump-reference when a bundle name is passed to the command
Discussion
----------
handle inheritance in config:dump-reference
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: ?
Fixes the following tickets: -
License of the code: MIT
Currently when passing in a bundle name that identifies a bundle that is a parent to another bundle, it will not return the reference for the requested bundle, but for the inheriting (even if that bundle has no configuration class).
F.e.
app/console config:dump-reference SymfonyCmfBlockBundle
will fail if there is a Bundle SandboxBlockBundle that has SymfonyCmfBlockBundle set as the parent.
* 2.0:
Fixes incorrect class used in src/Symfony/Bundle/FrameworkBundle/Console/Application.php
[FrameworkBundle] added test for fix broken command registration
corrected phpdoc
Issue must be related to commit 7a5f614240 (merged 2.0), specifically this file src/Symfony/Bundle/FrameworkBundle/Console/Application.php, lines 86-88.
Presumably to do "instanceof Bundle" correct class has to be imported at the top of the file:
instead of
use Symfony\Component\HttpKernel\Bundle;
this should be
use Symfony\Component\HttpKernel\Bundle\Bundle;
Conflicts:
src/Symfony/Bundle/FrameworkBundle/Console/Application.php
Commits
-------
0b78fdf Only call registerCommand on bundles that is an instance of Bundle
Discussion
----------
Only call registerCommand on bundles that is an instance of Bundle
Fixes GH-5133
---------------------------------------------------------------------------
by travisbot at 2012-08-01T09:41:05Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2008252) (merged 0b78fdff into 1da896dc).
---------------------------------------------------------------------------
by henrikbjorn at 2012-08-01T10:05:00Z
Build failed because of HTTP request error.
---------------------------------------------------------------------------
by lsmith77 at 2012-08-01T11:31:08Z
wondering if it would be good if you could include the commit from #5133 in this PR .. then we get the test and the fix at once.
Commits
-------
b982883 [Form] Moved FormHelper back to FrameworkBundle
cb62d05 [Form] [Validator] Fixed issues mentioned in the PR
2185ca8 [Validator] Added entry point "Validation" for more convenient usage outside of Symfony2
ed87361 [Form] Moved FormHelper creation to TemplatingExtension
87ccb6a [Form] Added entry point "Forms" for more convenient usage outside of Symfony
Discussion
----------
[Form] [Validator] Added more convenient entry points for stand-alone usage
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR greatly simplifies the usage of the Form and Validator component when used outside of Symfony2. Check out the below code to get an idea about the simplified usage:
```php
<?php
use Symfony\Component\Validator\Validation;
use Symfony\Component\Validator\Mapping\Cache\ApcCache;
use Symfony\Component\Form\Forms;
use Symfony\Component\Form\Extension\HttpFoundation\HttpFoundationExtension;
use Symfony\Component\Form\Extension\Csrf\CsrfExtension;
use Symfony\Component\Form\Extension\Csrf\CsrfProvider\SessionCsrfProvider;
use Symfony\Component\Form\Extension\Templating\TemplatingExtension;
use Symfony\Component\Form\Extension\Validator\ValidatorExtension;
use Symfony\Component\HttpFoundation\Session;
use Symfony\Component\Templating\PhpEngine;
$session = new Session();
$secret = 'V8a5Z97e...';
$csrfProvider = new SessionCsrfProvider($session, $secret);
$engine = new PhpEngine(/* ... snap ... */);
$validator = Validation::createValidator();
// or
$validator = Validation::createValidatorBuilder()
->addXmlMapping('path/to/mapping.xml')
->addYamlMapping('path/to/mapping.yml')
->addMethodMapping('loadValidatorMetadata')
->enableAnnotationMapping()
->setMetadataCache(new ApcCache())
->getValidator();
$formFactory = Forms::createFormFactory();
// or
$formFactory = Forms::createFormFactoryBuilder()
// custom types, if you're too lazy to create an extension :)
->addType(new PersonType())
->addType(new PhoneNumberType())
->addTypeExtension(new FormTypeHelpTextExtension())
// desired extensions (CoreExtension is loaded by default)
->addExtension(new HttpFoundationExtension())
->addExtension(new CsrfExtension($csrfProvider))
->addExtension(new TemplatingExtension($engine, $csrfProvider, array(
'FormBundle:Form'
))
->addExtension(new ValidatorExtension($validator))
->getFormFactory();
$form = $formFactory->createBuilder()
->add('firstName', 'text')
->add('lastName', 'text')
->add('age', 'integer')
->add('gender', 'choice', array(
'choices' => array('m' => 'Male', 'f' => 'Female'),
))
->getForm();
if (isset($_POST[$form->getName()])) {
$form->bind($_POST[$form->getName()]);
if ($form->isValid()) {
// do stuff
}
}
return $engine->render('AcmeHelloBundle:Hello:index.html.php', array(
'form' => $form->createView(),
));
```
---------------------------------------------------------------------------
by bschussek at 2012-07-30T10:08:42Z
I should maybe add a comment about the benefits of this change, in case they are not self-explanatory:
* class construction with default configuration is now a one-liner
* userland code is decoupled from core implementations → userland code doesn't break if we change constructor signatures
* easier to understand, since many core classes are now created internally
* easy to discover the possible settings → just look at (FormFactory|Validator)BuilderInterface
* usage of custom interface implementations is supported, just like before
---------------------------------------------------------------------------
by fabpot at 2012-07-31T08:18:53Z
The new syntax is great.
I have one comment though about this PR about support of PHP as a templating system (support for Twig is provided by the bridge and it was already easy to configure Twig as a templating system for forms -- see Silex for instance).
The `FormHelper` has been moved into the Form component. This helper is only useful when using the PHP templating system (which is not what we recommend people to use), but the default templates are still in the Framework bundle. So using the Form component as standalone with PHP as a templating system still requires to install the bundle to get access to the default templates. Am I missing something? Do we want to move the PHP templates to the Form component too?
---------------------------------------------------------------------------
by stof at 2012-07-31T08:28:28Z
@fabpot it is even worse than that: the FormHelper currently uses the theme by using ``$theme . ':' . $block . '.html.php`` IIRC. This is not compatible with the default template name parser of the component expecting a path. And the FrameworkBundle template name parser does not support accessing a template outside a bundle AFAIK.
So moving the templating to the component would require some refactoring in the FormHelper and the template name parser. However, I think it is worth it. Some people complained that using the form rendering (outside the full-stack framework) was requiring either setting up Twig with the bridge, or adding FrameworkBundle in the project (which means including most of the code of the full-stack framework). Having the Templating rendering in the standalone component could be a great idea
---------------------------------------------------------------------------
by fabpot at 2012-07-31T08:42:53Z
But then, I don't want to promote the Templating component or the PHP templating system. Twig is always a better alternative and this should be what people use most of the time, PHP being the rare exception.
Anyway, we are too close from the first 2.1 RC, so any big refactoring will have to wait for 2.2.
---------------------------------------------------------------------------
by stof at 2012-07-31T09:02:10Z
then maybe we should keep the FormHelper in FrameworkBundle for now as it is tied to the FrameworkBundle template name parser anyway currently.
---------------------------------------------------------------------------
by bschussek at 2012-07-31T14:22:35Z
> it it is even worse than that: the FormHelper currently uses the theme by using ``$theme . ':' . $block . '.html.php`` IIRC. This is not compatible with the default template name parser of the component expecting a path.
This is why the templates are still in FrameworkBundle. I think they should be moved too, but then we have to change
* the default theme to an absolute file path
* the FrameworkBundle name parser to accept absolute paths
I think this can wait until 2.2. Baby steps.
> I don't want to promote the Templating component or the PHP templating system.
We can both promote Twig while making Templating as easy to use as possible. If people want to use Templating, they probably have a reason. We don't have to make their lives more painful than necessary.
Btw: Templating is a *lot* faster for rendering forms than Twig. On Denis' form, Templating takes 1.15 seconds while Twig takes 2.
About moving the helpers, we have two choices:
* Move each helper to the respective component. This would not require new releases of the Templating component when we add more helpers in other component.
* Move all helpers to Templating. This does not make that much sense for Form, as then Form has support for Templating (TemplatingRendererEngine) and Templating has support for Form (FormHelper), which is a bit weird. I personally prefer a stacked architecture, where Templating is at the bottom and Form-agnostic, and Form (or any other component) builds upon that.
I'm fine with both approaches. I'll move FormHelper back to FrameworkBundle, and we can decide for a direction in 2.2.
---------------------------------------------------------------------------
by bschussek at 2012-07-31T14:36:30Z
Done.
Commits
-------
03bbaaf [Routing] Add an interface for configuring strict_parameters
Discussion
----------
[RFC][Routing] Add an interface for configuring strict_parameters
This is a proposal to fix#4697 (related to #4592).
The main point left to discuss was the name of the interface, which is now `LenientInterface`. We could change the name to anything else is someone has a better idea.
@stof @Tobion what do you think ?
---------------------------------------------------------------------------
by stof at 2012-07-30T16:34:20Z
@vicb I already said I had no idea to name it, and it has not changed. :)
So let's wait for other people to see if they have a better idea
---------------------------------------------------------------------------
by breerly at 2012-07-30T16:38:38Z
Maybe `PermissibleInterface` or `PermissiveInterface`.
---------------------------------------------------------------------------
by Partugal at 2012-07-30T17:00:09Z
`StrictUrlGeneratorInterface`, `StrictParametersInterface` or `StrictInterface`
---------------------------------------------------------------------------
by pborreli at 2012-07-30T17:04:46Z
👍 for `PermissiveInterface`
---------------------------------------------------------------------------
by stof at 2012-07-30T17:07:59Z
yes, because the Router currently can only use this interface to set it to ``not-strict``. It assumes that the url generator is already strict by default (which is probably a bad assumption btw as the base class for the generated generator can be changed)
---------------------------------------------------------------------------
by pborreli at 2012-07-30T17:09:33Z
@stof thx, got it
---------------------------------------------------------------------------
by Partugal at 2012-07-30T17:10:03Z
this interface realize setting Strict by setStrictParameters, and get by getStrictParameters, and imho named it by `Strictable` is more logic
---------------------------------------------------------------------------
by pborreli at 2012-07-30T17:11:07Z
@Partugal let's try to find an english term :)
---------------------------------------------------------------------------
by Partugal at 2012-07-30T17:11:31Z
)
---------------------------------------------------------------------------
by breerly at 2012-07-30T17:15:23Z
@Partugal I like using "able" in interface names because it describes a behavior instead of a noun. This type of naming makes following the Interface Segregation Principle easy to follow. Good work.
---------------------------------------------------------------------------
by vicb at 2012-07-30T18:24:26Z
As explained by @stof I did not consider `StrictInterface` because as of now the interface is used to disabled the strict bevahior (which is enabled by default).
I am not satisfied with `PermissiveInterface` / `LenientInterface` because implementing this interface does not mean that the generator will be permissive but only that the behavior is configurable - yes I did consider `Configurable` but the term is a too vague.
---------------------------------------------------------------------------
by breerly at 2012-07-30T18:35:45Z
I see. Perhaps ```StrictConfigurableInterface``` would do the trick.
---------------------------------------------------------------------------
by Tobion at 2012-07-30T21:02:21Z
I think renaming strict_parameters to `strict_requirements` is the way to go because it determines how requirements are handled when generating a URL. Also we should allow another option:
strict_requirements = true: throw exception for mismatching requirements
strict_requirements = null: return null as URL for mismatching requirements and log it.
strict_requirements = false: return the URL with the given parameters without checking the requirements and don't log it.
(Maybe use constants for these).
The Interface I would then call `ConfigurableRequirementsInterface` or `RequirementsHandlingInterface`.
---------------------------------------------------------------------------
by vicb at 2012-07-31T07:23:24Z
Thanks all for the feeback, this is what is now implemented:
- A `ConfigurableRequirementsInterface` that should be implemented by generators that can be configure not to throw an exception when the parameters do not match the requirements,
- The interface has two methods: `setStrictRequirements()` and `isStrictRequirements()`,
- `setStrictRequirements()` always gets called to configure the generator (whatever the option value is)
Note: The Router option name has not changed (i.e. `strict_parameters`)
Does that fit everyone ?
---------------------------------------------------------------------------
by vicb at 2012-07-31T07:39:22Z
So the option name is now consistent (`strict_requirements`) with the interface. We should sync the change [in the standard edition](https://github.com/symfony/symfony-standard/blob/master/app/config/config.yml#L11) if we agree to merge this.
---------------------------------------------------------------------------
by fabpot at 2012-07-31T07:51:47Z
@vicb you forgot to rename the property in `UrlGenerator` as @stof mentioned above.
---------------------------------------------------------------------------
by vicb at 2012-07-31T07:59:57Z
@fabpot fixed. If the code is ok, I'll squash the commits and open a PR on symfony-standard
Commits
-------
39157a8 [Security] fixes multiple overlapping definitions of DefaultFailureHandler and DefaultSuccessHandler in AbstractFactory
Discussion
----------
[Security] fixes multiple overlapping definitions of DefaultFailureHandler and DefaultSuccessHandler in AbstractFactory
If more than one listener extends AbstractFactory, you'll have multiple calls to createAuthenticationFailureHandler and createAuthenticationSuccessHandler with the same id.
Implicitly it's going to use the one generated by the last factory generating unexpected behavior.
This is related to commits 915704c071 and c6aa392df7
Commits
-------
1474aa5 [Form] Fixed consideration of Twig's template inheritance and added another performance-improving check
b4ec7f5 Fixed my rubbish English
d11f8b5 [Form] Fixed passing of variables in the FormRenderer
629093e [Form] Extracted common parts of FormHelper and FormExtension into separate classes
216c539 [Form] Implemented a more intelligent caching strategy in FormHelper (PHP +100ms, Twig +100ms)
Discussion
----------
[Form] Merged FormHelper and FormExtension and implemented a better caching strategy
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR extracts common parts of `FormHelper` and `FormExtension` into implementations of the new interfaces `FormRendererInterface` and `FormRendererEngineInterface`. The implemented `AbstractRendererEngine` features a more intelligent caching strategy than the one used before. When this strategy was implemented directly in `FormHelper`, the performance of [this specific, heavy form](http://advancedform.gpserver.dk/app_dev.php/taxclasses/1) could be improved from **2.5** to **2.25 seconds** on my machine for PHP templates.
Due to the abstraction and delegation, the performance gain is not that big anymore, but we still have a performance gain of about **0.1 seconds** for both PHP and Twig in the above example. The second, big improvement of this PR is maintainability - the differences between PHP and Twig templates are now contained in relatively small classes - and extendability (it is very easy now to support different template engines).
---------------------------------------------------------------------------
by stof at 2012-07-14T13:47:19Z
should a similar refactoring be done for the [Twig rendering](https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Extension/FormExtension.php) ?
---------------------------------------------------------------------------
by bschussek at 2012-07-14T13:49:25Z
Yes. I would like to merge the common parts of Twig's FormExtension and PHP's FormHelper into an abstract class. Before that I need to have a [working, heavy Twig Form](https://twitter.com/webmozart/status/224135287377371138) in order to measure whether I don't actually decrease the performance with Twig. Can you help me there?
---------------------------------------------------------------------------
by vicb at 2012-07-16T21:48:24Z
Would it make sense to create a 'renderer' folder in the form component and move related classes there ?
---------------------------------------------------------------------------
by stof at 2012-07-16T22:06:58Z
@vicb It makes sense to keep the Twig renderer in the brisge. This is what the bridge is about. Moving the Twig class to the component would not be consistent. And the PHP renderer is already in the component (but it could make sense to move the helper from FrameworkBundle to the TemplatingExtension of the Form component though)
---------------------------------------------------------------------------
by vicb at 2012-07-16T22:16:50Z
@stof I was only referring to the classes located in the Component/Form folder.
---------------------------------------------------------------------------
by vicb at 2012-07-16T22:27:27Z
Overall I don't really know what to think of this PR. PHP and Twig use a different way to support blocks:
- PHP has one block per file,
- Twig could have many blocks per templates.
I am not sure if this PR is optimal for Twig and improves maintainability ?
---------------------------------------------------------------------------
by stof at 2012-07-16T22:46:11Z
@vicb it avoids duplicating the whole rendering logic for each engine (there is at least a third one in [SmartyBundle](https://github.com/noiselabs/SmartyBundle/blob/master/Extension/FormExtension.php) btw)
---------------------------------------------------------------------------
by bschussek at 2012-07-17T07:16:42Z
@vicb I don't think a renderer subfolder makes sense. The interfaces belong to the main namespace, and then the subfolder would only contain two classes.
Considering maintainability for Twig, I think that this PR in fact increases it. TwigExtension before always had to check the whole type hierarchy, while now the code in AbstractRendererEngine makes sure that this process is speeded up.
Before:
```
load _some_entity_field_label:
- check _some_entity_field_label
- check entity_label
- check choice_label
- check form_label
load _some_other_entity_field_label
- check _some_other_entity_field_label
- check entity_label
- check choice_label
- check form_label
a.s.o.
```
After:
```
load _some_entity_field_label:
- check _some_entity_field_label
- check entity_label (hits the cache if entity_label was checked before)
- check choice_label (hits the cache if choice_label was checked before)
- check form_label
load _some_other_entity_field_label
- check _some_other_entity_field_label
- check entity_label (now definitely hits the cache)
a.s.o.
```
Since many fields share the same ancestors in the inheritance tree, this definitely improves performance.
As can also be deducted here, custom block names such as `_some_entity_field_label` are now a major drawback. There is nothing we can cache for them, so they need to be checked for every individual block that we load. Removing this feature surprisingly gains no performance for Twig (I need to investigate why at some point), but it speeds up rendering for **250ms** using the PHP engine on [this example form](advancedform.gpserver.dk/app_dev.php/taxclasses/1), dropping the rendering time from 1.25 to 1 sec on my local machine. I'm not sure what we should do here.
---------------------------------------------------------------------------
by stof at 2012-07-17T07:21:31Z
@bschussek could it be possible to have an implementation checking the custom block and another one skipping it ? This way, the user could disable this feature when he does not need it.
---------------------------------------------------------------------------
by bschussek at 2012-07-17T07:38:34Z
@stof It would be possible to add a switch to `FormRenderer` that controls whether custom blocks are checked or not.
If this switch is disabled by default, we break BC. If this switch is enabled by default, it will be pretty useless. People will start designing away for custom blocks, and once they want to improve performance, they can't turn off the switch anymore because it would require too many changes.
---------------------------------------------------------------------------
by stof at 2012-07-17T08:08:38Z
@fabpot what do you think about it ?
---------------------------------------------------------------------------
by bschussek at 2012-07-17T08:41:43Z
Another option that just came to mind is to remove inheritance checks for anything but _widget and _row. I.e., if we render `entity_widget`, check
```
_id_widget
entity_widget
choice_widget
form_widget
```
But if we render `entity_label`, only check
```
_id_label
form_label
```
This improves PHP Templating for **170ms** and Twig for **20ms**. We gain another **150ms** for PHP Templating and **~15ms** for Twig if we also restrict custom fields (_id_widget) to the _widget and _row suffixes (it's really hard to tweak the renderer for Twig.. I think a lot of its performance bottlenecks lie in Twig itself).
Do you have any data on how often blocks other than _widget and _row are customized for specific types/IDs?
---------------------------------------------------------------------------
by stof at 2012-07-17T09:47:38Z
Well, I think most of the time other blocks are not even customized based on the type :)
---------------------------------------------------------------------------
by Tobion at 2012-07-17T14:32:39Z
From my experience rendering the form components individually is easier and more flexible than customizing by ID or type.
But there are still use cases for customizing like library-like bundles (e.g. Bootstrap).
Commits
-------
df2406f [Security] Add note to changelog about BC break
01b2e39 [Security] Extract default logout success handling logic
Discussion
----------
[Security] Extract default logout success handling logic
Bug fix: no
Feature addition: no
Backwards compatibility break: yes, small one for people using the component
Symfony2 tests pass: [](http://travis-ci.org/asm89/symfony)
License of the code: MIT
As discussed earlier with @fabpot and @schmittjoh. This PR extracts the default logout success handling logic to a separate class that users can extend.
Note: build status is red, but that is because of a failing performance test in the form component? ..
