Commits
-------
3a5e84f [Validator] Add CollectionSize constraint
Discussion
----------
[Validator] Add CollectionSize constraint
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
I will also send a PR to the documentation as soon as this one is accepted.
---------------------------------------------------------------------------
by bschussek at 2012-04-29T08:24:28Z
-1
I dislike the rising amount of very specific constraints in the core. Can't we add this to Size?
---------------------------------------------------------------------------
by vicb at 2012-04-29T09:01:39Z
@bschussek #3918 implements what you propose but then the messages are not valid any more:
```php
<?php
public $minMessage = 'This value should be {{ limit }} or more';
public $maxMessage = 'This value should be {{ limit }} or less';
public $invalidMessage = 'This value should be a valid number';
```
I can imagine 2 solutions:
- adding some more message,
- rename the `Size` constraint to `Range` and create a new `Size` constraint for arrays / countables.
What do you think ?
---------------------------------------------------------------------------
by bschussek at 2012-04-29T09:27:53Z
I'd prefer the second solution and merge `Size` with `SizeLength` as well.
---------------------------------------------------------------------------
by vicb at 2012-04-29T09:34:50Z
@bschussek It would make sense. @makasim @Herzult any one of you would like to contribute this (i.e. rename the current Size to Range and create a new Size supporting arrays / countables / strings) ?
---------------------------------------------------------------------------
by Herzult at 2012-04-29T14:31:12Z
Yep, I'm on it.
---------------------------------------------------------------------------
by stof at 2012-04-29T15:22:44Z
@Herzult could you take the other comment into account and merge SizeLength into you Size ?
---------------------------------------------------------------------------
by vicb at 2012-04-29T15:33:05Z
The guessers should also be modified (it might also affect the ODM which is in an other repo, if so it would be good to sync the changes).
---------------------------------------------------------------------------
by Herzult at 2012-04-29T16:38:19Z
@stof the problem merging SizeLength into Size is that they don't have the same required options & messages.
---------------------------------------------------------------------------
by Herzult at 2012-04-29T16:47:40Z
And what about renaming Range to Interval and SizeLength to IntervalLength?
---------------------------------------------------------------------------
by stof at 2012-04-29T16:54:38Z
Well, SizeLength is about matching the length of a string currently. Nothing related to intervals
---------------------------------------------------------------------------
by Herzult at 2012-04-29T17:29:40Z
Here are the current names:
* **Size** for collection (countable) size
* **Range** for numbers
* **SizeLength** for strings
Merging **SizeLength** into **Size** is maybe not appropriate because collections and strings are different things. It'll be hard to find messages that fit both collections and strings. Maybe we had better to find a better name for both. What do you think?
About the ValidatorTypeGuesser, I'll update it as soon as we know ow to name the constraints.
---------------------------------------------------------------------------
by vicb at 2012-04-29T17:43:01Z
Size is a good name for both strings and "collections", could we have two sets of strings and select according to the type ?
---------------------------------------------------------------------------
by Herzult at 2012-04-29T22:39:55Z
I tried to merge them together, what do you think?
---------------------------------------------------------------------------
by vicb at 2012-04-30T06:52:37Z
I think your changes are great, may be @bschussek has more feedback. The ValidatorTypeGuesser and the translation are yet to be updated.
---------------------------------------------------------------------------
by hhamon at 2012-05-01T12:32:28Z
Am I missing something or `SizeLength` for strings is a duplicate for `MinLength` and `MaxLength` constraints?
---------------------------------------------------------------------------
by Herzult at 2012-05-02T13:29:36Z
Yep, that's true. But the only link between this PR and the SizeLength constraint is that I merged it to the one I introduced.
---------------------------------------------------------------------------
by Herzult at 2012-05-07T07:48:01Z
@bschussek what do you think?
---------------------------------------------------------------------------
by vicb at 2012-05-10T19:51:26Z
@Herzult this PR looks good to me, could you update the changelog and update guides, try to factorize the code and squash the commits ? Thanks.
---------------------------------------------------------------------------
by travisbot at 2012-05-11T15:42:35Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1306112) (merged 8d8e6443 into 4ac3bddb).
---------------------------------------------------------------------------
by vicb at 2012-05-11T21:42:21Z
* could #4259 be helpful ?
* please squash the commits.
* please create a PR / issue on [symfony-docs](https://github.com/symfony/symfony-docs)
thanks for the updates.
---------------------------------------------------------------------------
by travisbot at 2012-05-13T18:38:18Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1321123) (merged eeda9044 into 4ac3bddb).
---------------------------------------------------------------------------
by travisbot at 2012-05-13T18:45:12Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1321146) (merged 491ca19a into 8b54eb56).
---------------------------------------------------------------------------
by travisbot at 2012-05-14T11:29:39Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1326110) (merged 44865024 into 8b54eb56).
---------------------------------------------------------------------------
by vicb at 2012-05-14T11:49:37Z
@Herzult what about plural translations ?
---------------------------------------------------------------------------
by travisbot at 2012-05-14T16:52:37Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1328677) (merged 93480f95 into 46ffbd52).
---------------------------------------------------------------------------
by travisbot at 2012-05-14T17:03:13Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1328705) (merged 326c3b81 into 46ffbd52).
---------------------------------------------------------------------------
by vicb at 2012-05-14T20:19:18Z
thanks for the updates, this PR looks fine to me. @bschussek ?
---------------------------------------------------------------------------
by vicb at 2012-05-16T06:45:51Z
@Herzult can you squash your commits ?
---------------------------------------------------------------------------
by travisbot at 2012-05-16T11:20:44Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1344811) (merged 3a5e84f4 into 58b6ef23).
[Validator] Rename constraint Size to Range
[Validator] Rename constraint CollectionSize to Size
[Validator] Merge the SizeLength into the Size constraint
[Validator] Update messages in Size constraint for consistancy
[Validator] Add english and french translation for Size messages
[Validator] Tweak expected types for exceptions in SizeValidator
[Validator] Fix CS in SizeValidator
[Validator] Update the ValidatorTypeGuesser
[Validator] Tweak SizeValidator
[Validator] Update CHANGELOG
[Validator] Complete previous CHANGELOG updates
[Form] Update validator type guesser
[Validator] Pluralize collection size english messages
[Validator] Pluralize Size french messages
Commits
-------
b2afd9f use require instead of include
1ed8b72 Autoloader should not throw exception because PHP will continue to call other registered autoloaders.
Discussion
----------
[DoctrineBundle] Proxy autoloader should not throw exception
Also change 'require' to non-fatal '@include' in the event no file is generated.
---------------------------------------------------------------------------
by stof at 2012-05-01T06:13:34Z
The goal of the exception was to make debugging easier. And all Symfony2 autoloaders are using ``require``
---------------------------------------------------------------------------
by robocoder at 2012-05-01T16:09:04Z
I changed the include back to a require.
Whether or not the exception makes debugging easier is debatable. But throwing an exception from an autoloader is both unconventional and unexpected given that (1) exceptions are propagated while php calls other registered autoloaders, and (2) php will throw a fatal error where the usage actually occurs if the class doesn't exist.
---------------------------------------------------------------------------
by fabpot at 2012-05-15T06:01:11Z
ping @beberlei
---------------------------------------------------------------------------
by beberlei at 2012-05-15T10:20:06Z
Its tricky, the message does try to give some additional information - but later autoloaders could handle this issue anyways. I guess the PR makes sense as users have absolutely no control over this autoloader and it should therefore behave less strictly.
Commits
-------
498b814 [FrameworkBundle] minor fix in TranslationUpdateCommand <info> was not properly closed.
Discussion
----------
[FrameworkBundle] TranslationUpdateCommand <info> was not properly closed.
---------------------------------------------------------------------------
by travisbot at 2012-05-13T13:43:06Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1319869) (merged 498b8140 into e1934527).
---------------------------------------------------------------------------
by fabpot at 2012-05-13T17:06:25Z
Can you reopen a PR on the 2.0 branch as this is a bug fix? Thanks.
---------------------------------------------------------------------------
by stof at 2012-05-13T18:09:39Z
@fabpot this command is a 2.1 feature (even if it was added 6 month ago and so seems already old). There is nothing to fix in 2.0
Since the redesign of the Web-Debug-Toolbar, a new PHP icon has been
set, but its color was a bit darker (#000000) than the other icons in
the toolbar (#302e32 for the Symfony2 logo). This commit aims to ajust
the background color of the PHP logo to keep a certain homogeneity.
Commits
-------
709be4b [WDT] added documentation link
Discussion
----------
[WDT] added documentation link
This adds a documentation link in the WDT for the appropriate branch according to the current symfony version.
@weaverryan there is no documentation branch yet for the currently created 2.1 branch.
Also it might be a nice feature to redirect the dev branch to master automatically on the website. I.e. `http://symfony.com/doc/2.1/index.html` -> `http://symfony.com/doc/master/index.html`
@fabpot It might be a good idea to introduce a `Kernel::BRANCH` constant. So there would be no need to extract the branch from the symfony version in `ConfigDataCollector`. And bumping new versions/branches would be in one place.
---------------------------------------------------------------------------
by vicb at 2012-04-27T14:17:07Z
Maybe the documentation server should redirect to the right version according to `Kernel::VERSION` (i.e. using rewritting) ?
---------------------------------------------------------------------------
by Tobion at 2012-04-27T14:31:49Z
That would be best yes.
---------------------------------------------------------------------------
by fabpot at 2012-05-10T06:03:45Z
FYI, I've added some more constants about the Symfony version: 48099a852c (modeled after PHP constants)
---------------------------------------------------------------------------
by fabpot at 2012-05-10T07:08:57Z
I've just updated the website to accept any `HttpKernel::VERSION` string. Some redirection examples:
* 2.0.12 -> current
* 2.0 -> current
* 2.0.12-DEV -> current
* 2.1 -> master
* 2.1.0-DEV -> master
---------------------------------------------------------------------------
by Tobion at 2012-05-10T12:49:16Z
👍 for updating the website. But I think you missed to return 404 for a non-existent main doc page.
http://symfony.com/doc/2.4/book/controller.html -> 404 as expected
http://symfony.com/doc/2.4/index.html -> does not return 404 (and all links there are dead)
---------------------------------------------------------------------------
by travisbot at 2012-05-10T15:12:07Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1296057) (merged 04adf361 into a01dec00).
---------------------------------------------------------------------------
by fabpot at 2012-05-10T17:21:06Z
I've fixed the doc index for non-existing versions. Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by Tobion at 2012-05-10T22:49:18Z
done
---------------------------------------------------------------------------
by travisbot at 2012-05-10T22:52:13Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1300414) (merged 709be4b7 into fae4523f).
Commits
-------
1e84f1e [TwigBundle] implemented context auto-escaping in Twig templates based on the template extension
Discussion
----------
[2.2] Implements context escaping for Twig (fixes#839)
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Currently the ports in RetryAuthenticationEntryPoint are fixed in the constructor call, there is no way to set them when you run your application on different ports.
With this fix the ports are taken from the router configuration.
Commits
-------
246c885 [Form] Fixed: Default value of 'error_bubbling' is now determined by the 'single_control' option
d3bb4d0 [Form] Renamed option 'primitive' to 'single_control'
167e64f [Form] Fixed: Field attributes are not rendered in the label anymore. Label attributes are now passed in "label_attr"
68018a1 [Form] Dropped useless test that is guaranteed by OptionsParser tests and that needs to be adapted very often
649752c [Form] Fixed: CSRF token was not displayed on empty complex forms
c623fcf [Form] Fixed: CSRF protection did not run if token was missing
eb75ab1 [Form] Fixed results of the FieldType+FormType merge.
Discussion
----------
[Form] Fixed errors introduced in the FieldType+FormType merge
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3994, #4000, #2294, #4118
Todo: -
---------------------------------------------------------------------------
by Tobion at 2012-04-22T15:39:20Z
`primitive` is a pretty abstract option name. It depends on the person what he considers primitive. Maybe more explicit naming or better documentation what it means.
---------------------------------------------------------------------------
by bschussek at 2012-04-22T15:47:29Z
Better suggestions?
The distinction here is between primitive and complex forms, where primitive forms are such forms that can be represented by a single HTML tag. This obviously needs to be documented.
---------------------------------------------------------------------------
by Tobion at 2012-04-22T15:49:45Z
Maybe `single_widget` or something like that.
---------------------------------------------------------------------------
by vicb at 2012-04-23T13:09:43Z
@Tobion @bschussek would `elementary` be better than `primitive` ?
---------------------------------------------------------------------------
by vicb at 2012-04-23T13:17:04Z
and `compound \ composite` better than `complex` ?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T14:08:33Z
@vicb I fail to see how elementary/compound is easier to understand than primitive/complex. Maybe single_widget, but what's the opposite of this case? multi_widget?
---------------------------------------------------------------------------
by vicb at 2012-04-23T14:15:09Z
Actually I am fine with anything... as long as it is documented.
---------------------------------------------------------------------------
by bschussek at 2012-04-23T14:22:31Z
Still I think that this unveals a more profound naming problem. How do we (also in the documentation) name forms with children (formerly "forms") and forms without children (formerly "fields")?
Should we refer to them as
* forms and fields?
* complex and primitive forms?
* ...
We must first answer this question before we can find an intuitive option name. If the documentation always switches between different terminologies, neither will it be understandable nor will this option be easy to remember.
---------------------------------------------------------------------------
by vicb at 2012-04-23T15:10:32Z
> Still I think that this unveals a more profound naming problem. How do we (also in the documentation) name forms with children (formerly "forms") and forms without children (formerly "fields")?
To make it clear, I would rather say forms that **can have** children and forms that **can not have** children (i.e. Empty collections have no children but they can have and this is reason why you have to introduce those options, right ? - that could be a good example for the doc).
It will probably be better to refer to "complex" / "primitive" forms in the doc (and use the "form" / "field" terms to explain them).
Note: I think @Tobion concern is that "primitive" / "complex" could be pejorative terms (this is why I have proposed "elementary" / "compound").
---------------------------------------------------------------------------
by Tobion at 2012-04-23T16:00:54Z
1. primitive/complex is subjective (and could be pejorative too)
2. elementary/compound is more explicit so probably better than primitive/complex
3. I dislike this option in general. Does it make sense to change this option from a user perspective? I guess it's always the same as long as the widget structure stays the same. So it should be resolved at a higher level dynamically from the widget structure and not exposed to any configuration.
4. In documentation I would use the terms forms and fields. Because all people with HTML knowledge will understand that fields cannot have sub-fields whereas forms can. But since this distinction is not findable in code, it should be mentioned that all these are implemented as a form hierarchy.
---------------------------------------------------------------------------
by mvrhov at 2012-04-23T16:02:00Z
how about simple and complex?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T16:06:33Z
@Tobion It does not make sense to change this option from the user perspective, still the overloading type has to propagate to FormType whether it is a form or a field, so that the default behaviour is correct.
A second option how to implement this is to add a method `isField` to FormTypeInterface that can be overloaded and receives the options. I don't really like to introduce new methods here unless absolutely required.
What about renaming the option "primitive" to "is_field"? The blocks in the template would then be named "form_widget_field" and "form_widget_form".
---------------------------------------------------------------------------
by tristanbes at 2012-04-25T14:01:06Z
Oh, I should've seen this before, i thought I was doing something wrong. (empty collections gets an input field bug)
Please big :UP: on this. When will it be merged ? @bschussek
---------------------------------------------------------------------------
by Tobion at 2012-04-25T15:30:28Z
+1 for "is_field" and "form_widget_field" but I would rather use "form_widget_compound" instead of "form_widget_form" which is quite strange.
---------------------------------------------------------------------------
by bschussek at 2012-04-26T16:34:04Z
@Tobion "simple" and "compound" then?
---------------------------------------------------------------------------
by Tobion at 2012-04-26T16:49:58Z
no "field" and "compound"
---------------------------------------------------------------------------
by bschussek at 2012-04-26T17:17:02Z
I don't like "field" for a simple reason: Consider the "date" type. We are typically speaking of the "date" field there. But technically, the "date" field is a compound field. So?
---------------------------------------------------------------------------
by Tobion at 2012-04-26T21:17:37Z
I don't understand the open question. You proposed "is_field" and "form_widget_field" yourself. So calling the template block "form_widget_field" is a comprehensible consequence of "is_field". I wouldn't call the date type with multiple inputs a field.
---------------------------------------------------------------------------
by tristanbes at 2012-04-26T21:52:39Z
We should take a decision cause right here i got all my forms that are broken because of the empty collection rendering as input field :-).
I guess we are many in that situation.
---------------------------------------------------------------------------
by bschussek at 2012-04-27T08:28:16Z
I renamed "primitive" to "single_control" now to match with the HTML specification which names all input elements (input, select etc.) "controls". The opposite is now "compound".
Meanwhile, I added a fix for #4118.
@fabpot This is ready for merge now.
---------------------------------------------------------------------------
by Tobion at 2012-04-27T10:22:49Z
Hm, I know naming things is hard and sometimes not really important. But since users need to know which block to override, it is essential to make it clear. I think there is still one issue.
The block is named `form_widget_single_control` in order, as you said, to abstract away if it's an input, select etc. But in fact it can only render `input` and nothing else. So this is misleading.
So you could also simply name it `form_widget_input`.
Apart from that I agree with everything.
English:
The value is not a country.
Danish translation in the latest commit:
Denne værdi er ikke et land.
Danish translation in the first commit and mine version:
Værdien er ikke et land
So this commit is simply to make the danish translation the same, and
not two different expressions..
Commits
-------
e344609 [DependencyInjection] Fixed composer.json
1aa0786 [FrameworkBundle] Fixed composer.json
3601f61 [DoctrineBridge] Fixed composer.json
Discussion
----------
Fix composer json
---------------------------------------------------------------------------
by jalliot at 2012-04-22T14:22:24Z
`suggest` no longer requires a version constraint. While you're at it, maybe you could change those to more meaningful strings explaining what each optional dependency provides.
---------------------------------------------------------------------------
by willdurand at 2012-04-22T14:24:27Z
I know, but the version is fine. It's more up to @fabpot to add description in each `suggest` entries.
Anyway, this is not the purpose of this PR. If you want to contribute on that, feel free :)
Commits
-------
ffc074b [Profiler] Fixed IE7 JavaScript errors
Discussion
----------
[Profiler] Fixed IE7 JavaScript errors
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Requires merge of another [PR](https://github.com/doctrine/DoctrineBundle/pull/61) available on the `doctrine/DoctrineBundle` repository (compatibility changes to `db.html.twig`).
---------------------------------------------------------------------------
by fabpot at 2012-04-20T14:15:22Z
That does not work for me.
Commits
-------
75c7d3a Fixed the link to the method with onclick event.
ecbabec renamed 'Request handler' to 'Controller' and 'Route ID' to 'Route name'.
3c5ede4 Add a new query to display all information.
f6a866b Merged CSS for the toolbar in both embedded mode (on each page) and profiler.
306533b Updated the responsive design in addition to the scenario with authenticated users and exception notification.
4a3312b Updated the toolbar with the responsive design (normal-to-large scenario).
1eec2a2 Updated the toolbar with the responsive design (normal-to-small scenario).
03c8213 Refactored the CSS code for the toolbar out of the template.
37843b3 Updated with PHP logo (only the text).
d5e0ccc Made the toolbar to show the version, memory usage, the state of security (both a abbreviation and an associate description) and number of DB requests and request time.
37ad8a6 Removed the check for verbose and adjusted the style when the toolbar is on the top of the page.
67b0532 Redesigned the WDT.
Discussion
----------
Re-design the debugging toolbar
The toolbar is very useful and containing lots of information. However, as there are too much information, it is very distracting and the toolbar area somehow ends up taking too much space and then becomes something like a panel.
The main purpose of this pull request is to hide any information and show only whenever the user wants to see, except the status code and response time.
This is based on [the pull request #3833](https://github.com/symfony/symfony/pull/3833) with the feedbacks and for 2.1 (master).
The testing app is available at http://home.shiroyuki.com.
---------------------------------------------------------------------------
by stof at 2012-04-10T06:24:36Z
@shiroyuki your testing app denies the access because of the restriction in app_dev.php
---------------------------------------------------------------------------
by shiroyuki at 2012-04-10T06:27:27Z
@stof: I'm sorry. It should be working now.
---------------------------------------------------------------------------
by stof at 2012-04-10T06:45:39Z
Moving the toolbar to the top of the page means it will hide some content of the page. You should keep it at the bottom
---------------------------------------------------------------------------
by shiroyuki at 2012-04-10T06:48:28Z
Just a moment ago, I changed the position of the toolbar via `config_dev` so I could check when WDT is on the top.
I just reverted the config file. :D
---------------------------------------------------------------------------
by fabpot at 2012-04-10T06:55:16Z
Some comments:
* I would have kept the number of database request as this number is probably the one everybody should have a look at on every page.
* I would have used the original PHP logo (in black and white) instead of a non-standard one
But overall, this is a very nice improvement.
---------------------------------------------------------------------------
by stloyd at 2012-04-10T06:55:43Z
There is an issue with "bubbling" at Firefox 11 (at least), when you hover `<a>` element, the hover event seems to be "launched" twice.
---------------------------------------------------------------------------
by fabpot at 2012-04-10T06:56:13Z
As the verbose mode has been removed from the template, it should also be removed from the configuration (I can do that after merging if you don't know how to do that).
---------------------------------------------------------------------------
by shiroyuki at 2012-04-10T07:05:31Z
@stloyd I noticed that too. As I couldn't find the same issue on Webkit-based browsers and all effects on this toolbar heavily relies on CSS, it could have been a glitch on Firefox.
@fabpot I'll see what I can do with the number of DB request and the logo.
---------------------------------------------------------------------------
by asm89 at 2012-04-10T07:26:28Z
Will there be options to somehow keep the debug toolbar 'expanded' or something? I guess the folding of the sf and php information makes sense, but I personally look at the request/time/memory/security and query parts of the toolbar a lot. As my browser window is big enough to show all information at once, this would be a huge step backwards imo.
---------------------------------------------------------------------------
by XWB at 2012-04-10T07:28:38Z
Agreed with @asm89, I also want the option to show all the information on my screen.
---------------------------------------------------------------------------
by fabpot at 2012-04-10T08:28:00Z
I tend to agree too with @asm89. What about reusing the `verbose` option for that. This was already its purpose anyway.
---------------------------------------------------------------------------
by shiroyuki at 2012-04-10T14:56:45Z
How about using media query?
---------------------------------------------------------------------------
by shiroyuki at 2012-04-11T02:20:32Z
Please note that the latest commit still doesn't have the new logo for PHP.
As DoctrineBundle now has its own repository, the change to show the number of DB requests is already done via DoctrineBundle's [PR 57](https://github.com/doctrine/DoctrineBundle/pull/57).
---------------------------------------------------------------------------
by guilhermeblanco at 2012-04-11T02:50:47Z
@fabpot @shiroyuki as soon as this patch is merged I will do the same on DoctrineBundle.
All you need to do is look at me over our desks' separator. =D
---------------------------------------------------------------------------
by shiroyuki at 2012-04-11T03:17:41Z
The last commit has the updated PHP logo. Unfortunately as @stloyd and @guilhermeblanco pointed out, the flicking on the toolbar when the mouse is over might have been due to the CSS issue on Firefox.
---------------------------------------------------------------------------
by Tobion at 2012-04-11T04:46:36Z
Nice work shiroyuki. I always had the feeling the toolbar can be improved. Good that you got this one going.
I would remove the verbose option (rarely nobody changes it) and use media queries to accomplish a responsive design that shows as much information as possible. And only shows the most important facts when there is not enough space.
E.g. the symfony version could be removed if it doesn't fit on the screen because it's mostly static from request to request.
---------------------------------------------------------------------------
by Tobion at 2012-04-11T04:48:45Z
Another idea: Add a panel "PHP Info" to the profiler that shows the output of `phpinfo()`. This panel is linked from the PHP logo in the WDT which currently has no link on it.
---------------------------------------------------------------------------
by shiroyuki at 2012-04-11T15:47:51Z
@Tobion: It would be an overkill if `phpinfo()` was visible in the toolbar. Additionally, the toolbar doesn't fit to show that amount of information. Plus, the information released by `phpinfo()` is also static and easily obtained by a simple PHP script. I don't think that WDT should be showing this information.
Please note that the media query is not yet implement. The followings are still unknown to me:
* should we support the toolbar for mobile device?
* what is the minimum screen size?
---------------------------------------------------------------------------
by Tobion at 2012-04-11T15:52:43Z
@shiroyuki you misunderstood me. phpinfo() should be a new panel in the PROFILER, not the WDT. It is reachable from the WDT by clicking on the PHP logo. But that can be implemented in a seperate PR. It's just an idea and before I would implement it, I'd like to receive feedback if it would be accepted at all.
---------------------------------------------------------------------------
by fabpot at 2012-04-11T16:38:44Z
Displaying `phpinfo()` data is not in the scope of this PR.
---------------------------------------------------------------------------
by Tobion at 2012-04-11T16:48:50Z
@fabpot yeah. But would you accept such a PR or do you think it's not useful?
---------------------------------------------------------------------------
by fabpot at 2012-04-11T16:57:49Z
@Tobion The web profiler is mainly about information for the current request; so I'm not sure it would be useful to have such a tab in the profiler.
---------------------------------------------------------------------------
by vicb at 2012-04-11T17:06:15Z
@fabpot @Tobion what about adding it in the config panel ? Not sure if it is very useful but I have seen to many `phpinfo.php` in the web root folder. (It could be an expandable panel loaded via ajax like what is used for the Doctrine explain panel).
---------------------------------------------------------------------------
by shiroyuki at 2012-04-12T03:11:40Z
@tobian @vicb: what kind of information are you looking from `phpinfo()`?
---------------------------------------------------------------------------
by Felds at 2012-04-12T03:30:02Z
The equivalent for `phpinfo()` was extremely convenient and helped a lot in Symfony 1. It's out of scope but an optional panel could be nice.
Ini flags are of great help when debugging on a hurry.
👍 for that!
---------------------------------------------------------------------------
by Tobion at 2012-04-12T03:37:52Z
@shiroyuki I don't understand your question. Everything of it should be displayed. But don't worry about phpinfo(), I'll work on that in a seperate PR. You can focus on the responsive design. ;)
---------------------------------------------------------------------------
by vicb at 2012-04-12T06:54:35Z
@shiroyuki I am not looking for anything specific. Just saying I have seen many times customer code using a publicly accessible file to return the info and it would help to get ride of this file.
---------------------------------------------------------------------------
by sstok at 2012-04-12T07:59:18Z
```
should we support the toolbar for mobile device?
```
Good question, I don't think so because the screen-size is to small to show anything useful.
Maybe a small icon to display the information as overlay, including the token so you can refer to that on a bigger screen?.
---------------------------------------------------------------------------
by johnnypeck at 2012-04-13T06:45:43Z
If your interested in a useful but not so intrusive way of providing the toolbar on mobile devices perhaps take a look at what the guys at Twitter have done with the topbar navigation converting to a semi-accordion style menu on mobile in Bootstrap. I can see the usefulness. Checkout the responsive.less which makes it easy enough to include/exclude depending on screen size. I found it quite useful in a recent project.
Regarding adding a tab for phpinfo, sure it would be useful BUT if the reasoning is that some people leave a publicly available phpinfo script therefore just include it then I would not include it. There are many more useful requirements of the toolbar rather than to insulate intro to web issues. That's like saying don't include the toolbar because someone may build an application that makes the toolbar available publicly (which will happen). I've seen too many projects in my years having no clue of versioning tools that must have been built on the server, live, with filenames like indexv1.php, indexv2.php, indexTryAgain.php, db credentials in the clear, and just hoping to find a point where it works enough. And yes, I've found those scripts were publicly available and still around years after they were created; security holes and all! I'm preaching to the choir here. You'll never stop stupid. All we can do is educate by any means we have and share our knowledge with one another. Aside from that devils advocate reasoning, I would include the phpinfo tab, it does make sense in those random "did I/they compile that in" circumstances. ;-) Sorry for the rant.
+1 for mobile
sorta+1 for phpinfo
+10 for better educating on how to include anything you need so phpinfo could be a "my first foray into adding a tool to my toolbar for Symfony" tutorial in the cookbook.
Again, sorry for the long winded rant. Cheers everyone. Goodnight.
---------------------------------------------------------------------------
by shiroyuki at 2012-04-13T23:33:21Z
@stof I think we can remove the CSS.
Commits
-------
6e4ed9e [Form] Fixed regression: bind(null) was not converted to an empty string anymore
fcb2227 [Form] Deprecated FieldType, which has been merged into FormType
bfa7ef2 [Form] Removed obsolete exceptions
2a49449 [Form] Simplified CSRF mechanism and removed "csrf" type
Discussion
----------
[Form] Merged FieldType into FormType
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3878
Todo: update the documentation on theming
This PR is a preparatory PR for #3879. See also #3878.
---------------------------------------------------------------------------
by juliendidier at 2012-04-13T14:25:19Z
What's the benefit ?
---------------------------------------------------------------------------
by henrikbjorn at 2012-04-13T14:26:40Z
why `input_widget` ? and not just `widget`
---------------------------------------------------------------------------
by Burgov at 2012-04-13T14:27:49Z
@juliendidier dynamic inheritance is now obsolete which fixes some other issues
---------------------------------------------------------------------------
by stloyd at 2012-04-13T14:37:26Z
What about __not__ breaking API so *badly* and leaving `FieldType` which will be simple like (with marking as deprecated):
```php
<?php
class FieldType extends AbstractType
{
public function getParent(array $options)
{
return 'form';
}
public function getName()
{
return 'field';
}
}
---------------------------------------------------------------------------
by bschussek at 2012-04-13T14:43:41Z
@stloyd That's a very good idea.
---------------------------------------------------------------------------
by mvrhov at 2012-04-13T17:41:21Z
IMHO what @stloyd proposed sounds like a good idea, but removing FieldType class, if #3903 will come into life might ensure that more forms will broke and people will check them thoroughly.
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-04-13T18:46:08Z
@bschussek looks great, but I'm concerned about how quickly will the third-party bundles adapt to this BC break. I hope really quick, because if they don't the whole stuff will be useless :S of course it's not your problem to solve.
---------------------------------------------------------------------------
by stof at 2012-04-13T18:50:32Z
@r1pp3rj4ck there is already another BC break requiring to update custom types for Symfony master. So third party bundles already have to do some work.
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-04-13T18:59:37Z
@stof which one? I've looked into @bschussek 's RFC about these [foo].bar stuff, but it's not yet implemented. Are you refering to this or another one I've missed?
---------------------------------------------------------------------------
by stof at 2012-04-13T19:04:06Z
@r1pp3rj4ck the change regarding default options
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-04-13T19:06:10Z
@stof oh, I forgot that one. Weird thing is that I've already changed my default options today and still forgetting these stuff :D
---------------------------------------------------------------------------
by bschussek at 2012-04-14T08:58:29Z
I restored and deprecated FieldType now. I'd appreciate further reviews.
---------------------------------------------------------------------------
by stloyd at 2012-04-14T09:02:32Z
Maybe we should try to avoid this BC in templates ? What do you think about similar move like with `FieldType` ? (hold old, but inside just render new)
---------------------------------------------------------------------------
by bschussek at 2012-04-14T09:07:22Z
@stloyd You mean for those cases where people explicitely render the block "field_*"? We can do that.
---------------------------------------------------------------------------
by stloyd at 2012-04-14T09:09:45Z
@bschussek Yes I mean this case =) Sorry for not being explicit, I need some coffee I think =)
---------------------------------------------------------------------------
by bschussek at 2012-04-17T14:45:35Z
I added the field_* blocks again for BC. Could someone please review again? Otherwise this can be merged.
---------------------------------------------------------------------------
by Burgov at 2012-04-17T15:11:16Z
@bschussek I'm not sure what has changed to cause this, but if I try out your branch on our forms, if I leave the value of an input empty, eventually the reverseTransform method receives a null value, rather than a '' (empty string) value, as on the current symfony master.
DateTimeToLocalizedStringTransformer, for example, will throw an Exception if the value is not a string
```php
if (!is_string($value)) {
throw new UnexpectedTypeException($value, 'string');
}
```
Other than that, all forms render just the same as they do on symfony master
---------------------------------------------------------------------------
by bschussek at 2012-04-17T15:30:29Z
@Burgov Fixed.
Commits
-------
24bd8f4 Added missing dot to translation messages.
4bff221 Added missing dot to translation messages.
7454894 Added missing dot to translation messages.
6e90c50 Updated upgrade instructions.
7e21dd1 Added missing dot to translation messages.
Discussion
----------
Issue 3379
This should fix [issues 3379](https://github.com/symfony/symfony/issues/3379)
---------------------------------------------------------------------------
by stof at 2012-04-13T15:06:32Z
Your branch conflicts with master. Please rebase it
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T19:11:54Z
@stof I tried to rebase, I'm not sure if I did everything right. Is it ok now?
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T19:12:06Z
@stof I tried to rebase, I'm not sure if I did everything right. Is it ok now?
---------------------------------------------------------------------------
by mvrhov at 2012-04-13T19:19:34Z
IMHO no, because there are commits from other people. Did you follow the [instructions](http://symfony.com/doc/current/contributing/code/patches.html#id1)?
---------------------------------------------------------------------------
by stof at 2012-04-13T19:36:53Z
@mvrhov commits from others ?
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T19:41:53Z
@stof There were some, so I reverted. Now I'm trying again following instructions from Symfony doc.
I come to this:
```
$ git push origin issue-3379
To git@github.com:umpirsky/symfony.git
! [rejected] issue-3379 -> issue-3379 (non-fast-forward)
error: failed to push some refs to 'git@github.com:umpirsky/symfony.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
```
And I don't know how to fix this. Any idea?
---------------------------------------------------------------------------
by stof at 2012-04-13T19:43:45Z
@umpirsky when you rebase, it is logical to need to force the push
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T19:44:38Z
@stof I did `git push -f origin issue-3379`. I hope it's fixed now.
---------------------------------------------------------------------------
by maoueh at 2012-04-13T20:39:34Z
@umpirsky seems better than last time I checked :)
---------------------------------------------------------------------------
by umpirsky at 2012-04-13T20:43:04Z
@maoueh Is it good enough? :)
---------------------------------------------------------------------------
by maoueh at 2012-04-13T20:51:27Z
@umpirsky At least, the rebase seems good enough :D As for the subject of the PR, I don't pronounce myself ;)
---------------------------------------------------------------------------
by vicb at 2012-04-13T20:53:23Z
you should probably squash the commits
Commits
-------
aa055df [Composer] Stwitch to composer vendors management
Discussion
----------
[Composer] Stwitch to composer vendors management
Bug fix: no
Feature addition: yes
Backwards compatibility break: No?
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
[](http://travis-ci.org/canni/symfony)
This speeds up Travis CI builds to `~2 min` also makes vendor management
a lot easier.
---------------------------------------------------------------------------
by fabpot at 2012-02-09T06:24:24Z
I'm -1 on this change. The `vendors.php` script is *only* for people working on the core so that we can run the unit tests. So, we need the flexibility to test on many different versions of the code and having the repository here is kind of mandatory.
---------------------------------------------------------------------------
by Seldaek at 2012-02-09T08:15:28Z
You can `composer install --dev` to get proper clones. I'm not really pro or against, just saying it's an option.
---------------------------------------------------------------------------
by canni at 2012-02-09T08:28:54Z
@fabpot I understand yours point, but from my view transferring the whole git structure of *vendors* is little pointless IMO (especially in Travis env)
but I think I can make this change optional, so Travis and anyone that prefer to, can use `composer` an with old functionality available.
(There will be almost no duplication, as anyway we're updating `composer.json`)
---------------------------------------------------------------------------
by canni at 2012-02-09T09:20:17Z
@fabpot I've enabled both behaviors, everything will work regardless of using `composer` or `vendors.php` this lets the developer decide what to use
---------------------------------------------------------------------------
by drak at 2012-02-16T12:05:28Z
Since there is a `--dev` option in Composer then I think this is a good idea. You could also add composer.phar to the repo bin directory.
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-16T12:06:55Z
`--dev` have been renamed to `--prefer-source`
---------------------------------------------------------------------------
by canni at 2012-02-16T12:22:01Z
@fabpot any chance to consider this merge? If not, this PR can be closed.
---------------------------------------------------------------------------
by henrikbjorn at 2012-02-16T12:25:51Z
@canni This is the goal eventually. But i think we need composer to be a bit more stable in its solver.
---------------------------------------------------------------------------
by francoispluchino at 2012-02-16T12:39:24Z
👍
---------------------------------------------------------------------------
by jmikola at 2012-04-06T18:19:27Z
@fabpot: Is this PR still off the table, or are you reconsidering it with the `--prefer-source` option? I was just running symfony unit tests, and attempted to install deps with composer as I thought this PR or another like it had recently been merged to core. It wasn't :)
Admittedly, it's a downside that vendor libs, even if git repositories, will be nestled within the `.composer/` directory.
---------------------------------------------------------------------------
by drak at 2012-04-07T00:20:33Z
@canni This PR needs to be rebased and reviewed because of the changed tests directory (there is no longer a central `tests/` folder).
---------------------------------------------------------------------------
by canni at 2012-04-07T06:34:28Z
Hey,
will do after a weekend.
canni
Użytkownik Drak <reply@reply.github.com> napisał:
>@canni This PR needs to be rebased and reviewed because of the changed tests directory (there is no longer a central `tests/` folder).
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/symfony/symfony/pull/3291#issuecomment-5004750
---------------------------------------------------------------------------
by canni at 2012-04-08T19:02:03Z
@drak done.
Commits
-------
98a0052 improved readability
b06537e refactored code to use get() when outputting a single route
Discussion
----------
Router debug refactoring
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/lsmith77/symfony)
Fixes the following tickets: -
refactored code to use get() when outputting a single route
this is useful for a CMS, where in most cases there will be too many routes to make it feasible to load all of them. here a router implementation will be used that will return an empty collection for ->all(). with this refactoring the given routes will not be listed via router:debug, but would still be shown when using router:debug [name]
CSRF fields are now only added when the view is built. For this reason we already know if
the form is the root form and avoid to create unnecessary CSRF fields for nested fields.
this is useful for a CMS, where in most cases there will be too many routes to make it feasible to load all of them. here a router implementation will be used that will return an empty collection for ->all(). with this refactoring the given routes will not be listed via router:debug, but would still be shown when using router:debug [name]
Commits
-------
b611db8 [Profiler] Sub requests are not Main requests
2551270 [Profiler] Minimize the number of Profile writes
Discussion
----------
[HttpKernel] Profiler Listener tweaks
* `setParent()` is called in [`Profile::addChild()`](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Profiler/Profile.php#L180) in 2.1
* The profiles are now only saved once only in the listener (either at the end of the main request or on an exception)
* The profiles are now only saved once only in the TraceableEventDispatcher (twice for the root profile when there is a kernel.terminate' event
[](http://travis-ci.org/vicb/symfony)
---------------------------------------------------------------------------
by vicb at 2012-04-13T11:15:25Z
Not so sure for the save part... I'll double check
Commits
-------
8329087 [Form] Moved calculation of ChoiceType options to closures
5adec19 [Form] Fixed typos
cb87ccb [Form] Failing test for empty_data option BC break
b733045 [Form] Fixed option support in Form component
Discussion
----------
[Form] Fixed option support in Form component
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3354, #3512, #3685, #3694
Todo: -
This PR also introduces a new helper `DefaultOptions` for solving option graphs. It accepts default options to be defined on various layers of your class hierarchy. These options can then be merged with the options passed by the user. This is called *resolving*.
The important feature of this utility is that it lets you define *lazy options*. Lazy options are specified using closures that are evaluated when resolving and thus have access to the resolved values of other (potentially lazy) options. The class detects cyclic option dependencies and fails with an exception in this case.
For more information, check the inline documentation of the `DefaultOptions` class and the UPGRADE file.
@fabpot: Might this be worth a separate component? (in total the utility consists of five classes with two associated tests)
---------------------------------------------------------------------------
by beberlei at 2012-04-05T08:54:10Z
"The important feature of this utility is that it lets you define lazy options. Lazy options are specified using closures"
What about options that are closures? are those differentiated?
---------------------------------------------------------------------------
by bschussek at 2012-04-05T08:57:35Z
@beberlei Yes. Closures for lazy options receive a Symfony\Component\Form\Options instance as first argument. All other closures are interpreted as normal values.
---------------------------------------------------------------------------
by stof at 2012-04-05T11:09:49Z
I'm wondering if these classes should go in the Config component. My issue with it is that it would add a required dependency to the Config component and that the Config component mixes many different things in it already (the loader part, the resource part, the definition part...)
---------------------------------------------------------------------------
by sstok at 2012-04-06T13:36:36Z
Sharing the Options class would be great, and its more then one class so why not give it its own Component folder?
Filesystem is just one class, and that has its own folder.
Great job on the class bschussek 👏
---------------------------------------------------------------------------
by bschussek at 2012-04-10T12:32:34Z
@fabpot Any input?
---------------------------------------------------------------------------
by bschussek at 2012-04-10T13:54:13Z
@fabpot Apart from the decision about the final location of DefaultOptions et al., could you merge this soon? This would make my work a bit easier since this one is a blocker.
---------------------------------------------------------------------------
by fabpot at 2012-04-10T18:08:18Z
@bschussek: Can you rebase on master? I will merge afterwards. Thanks.
Commits
-------
f9a486e [Validator] Added support for pluralization of the SizeLengthValidator
c0715f1 [FrameworkBundle], [TwigBundle] added support for form error message pluralization
7a6376e [Form] added support for error message pluralization
345981f [Validator] added support for plural messages
Discussion
----------
[Validator] Added support for plural error messages
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Todo: create translations for en and update others (FrameworkBundle)
[](http://travis-ci.org/hason/symfony)
---------------------------------------------------------------------------
by fabpot at 2011-05-14T20:41:01Z
@bschussek: What's your opinion?
---------------------------------------------------------------------------
by stof at 2011-09-04T13:14:29Z
@hason could you rebase your branch on top of master and update the PR ?
You also need to change the messages in the constraint that uses the pluralization to a pluralized format.
---------------------------------------------------------------------------
by stof at 2011-10-16T18:06:22Z
@hason ping
---------------------------------------------------------------------------
by stof at 2011-11-11T14:58:19Z
@hason ping again
---------------------------------------------------------------------------
by stof at 2011-12-12T20:39:10Z
@hason ping again. Can you update your PR ?
---------------------------------------------------------------------------
by hason at 2011-12-12T21:29:14Z
@stof I hope that I will update PR this week.
---------------------------------------------------------------------------
by bschussek at 2012-01-15T19:07:32Z
Looks good to me.
---------------------------------------------------------------------------
by canni at 2012-02-02T17:28:54Z
@hason can you update this PR and squash commits, it conflicts with current master
---------------------------------------------------------------------------
by hason at 2012-02-09T07:21:41Z
@stof, @canni Rebased.
What is the best solution for the translation of messages?
1. Change messages in the classes and all xliff files?
2. Keep messages in the classes and change all xliff files?
---------------------------------------------------------------------------
by stof at 2012-02-09T08:19:41Z
The constraints contain the en message so you will need to modify them to update the message
---------------------------------------------------------------------------
by hason at 2012-02-09T08:55:55Z
I prefer second option. The Validator component should be decoupled from the Translation component. The constraints contain the en message which is also the key for Translation component. We should create validators.en.xlf in the FrameworkBundle for en message. I think that this is better solution. What do you think?
---------------------------------------------------------------------------
by stof at 2012-04-04T02:22:02Z
@hason Please rebase your branch. It conflicts with master because of the move of the tests
@fabpot ping
Commits
-------
0024ddc Fix for using route name as check_path.
Discussion
----------
Security Bundle route as check_path
In the current 2.0 branch you can't use a route as
firewalls:
admin_area:
login_path:
you will get a InvalidConfigurationException.
In the 2.1 version this is fixed. Since 2.1 isn't released i think this fix should be merged into the 2.0 branch too. Many people have this problem (https://github.com/schmittjoh/JMSI18nRoutingBundle/issues/7) for example which effectively blocks internationalisation in combination with the firewall.
---------------------------------------------------------------------------
by stof at 2012-04-10T13:35:13Z
@fabpot ping
Bug fix: no
Feature addition: yes
Backwards compatibility break: ?
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This speeds up Travis CI builds to `~2 min` also makes vendor management
a lot easier.
Commits
-------
8726ade Adds more features to twig:lint command
1d7e9d9 Adds a linter command for templates
Discussion
----------
Adds a linter command for templates
Let's this PR be stoffed. ;)
---------------------------------------------------------------------------
by Tobion at 2012-04-06T15:48:18Z
Checking a single file is very limited. Checking a whole directory would be more useful, wouldn't it?
---------------------------------------------------------------------------
by willdurand at 2012-04-06T17:56:57Z
I think you should provide a way to validate all templates for a given bundle, something like:
php app/console twig:lint @MySuperBundle
---------------------------------------------------------------------------
by henrikbjorn at 2012-04-06T18:03:45Z
Wouldnt it be better to throw some kind of exception if the lint is erroneous?
---------------------------------------------------------------------------
by marcw at 2012-04-07T11:22:34Z
@Tobion @willdurand You can do that by combining unix tools.
@henrikbjorn Why ?
---------------------------------------------------------------------------
by marcw at 2012-04-07T11:27:11Z
Updated.
---------------------------------------------------------------------------
by dlsniper at 2012-04-07T13:15:53Z
@marcw it would be indeed nice to have support for a bundle/directory out of the box as some of the Symfony2 users might not be running unix or know the right commands to make this work.
I could help you with a PR in your repo if you want.
---------------------------------------------------------------------------
by henrikbjorn at 2012-04-07T18:55:34Z
@marcw as the console component will catch them and convert them into the right error code, also will display what went wrong instead of just dieing.
---------------------------------------------------------------------------
by marcw at 2012-04-08T09:15:37Z
Updated with all comments and requested features.
Commits
-------
d04638a [EventDispatcher] More logical positions for classes.
Discussion
----------
[EventDispatcher] More logical positions for classes.
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
---------------------------------------------------------------------------
by stof at 2012-04-04T18:59:02Z
ah sorry, I looked at the patch too fast. Only the interface is moved
This fixes the translation when the fallback is set to another language.
This new file can be used as reference by translators to find missing keys
in their translations as every contributor will be able to update it when
adding new keys.
Commits
-------
dbab7e1 [TwigBridge] Added a TwigEngine in the bridge
Discussion
----------
[TwigBridge] Added a TwigEngine in the bridge
This TwigEngine implements the interface available in the component.
the TwigBridge in TwigBundle now extends this class and provides only
the additional methods for the FrameworkBundle interface.
This will allow people to support the PhpEngine and Twig in their code more easily when using the component as they don't need to reimplement the class.
I originally thought about when I helped @dragoonis to integrate the Templating component in the PPI framework 2.0 as he talked about adding the support for Twig later too.
This TwigEngine implements the interface available in the component.
the TwigBridge in TwigBundle now extends this class and provides only
the additional methods for the FrameworkBundle interface.
Commits
-------
8f11f2dd shortened if/else syntax
2b8c2bc [FrameworkBundle] made http_cache dir extensible
Discussion
----------
[FrameworkBundle] make http_cache dir extensible
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
I have a use case where I don't want the httpcache cleared on `cache:clear`. Currently, it is awkward to change this directory.
[](http://travis-ci.org/kbond/symfony)
Commits
-------
3303155 added kernel shutdown before create client, fixed and stashed
Discussion
----------
[FrameworkBundle] WebTestCase createClient doesn't check if static:kernel was already allocated
with this little fix CreateClient shuts down the kernel before booting again.
If you add an echo after the "if" on the line number 38
and run the test you would see that sometime the kernel is not properly umounted.
Bug fix: [no]
Feature addition: [no]
Backwards compatibility break: [no]
Symfony2 tests pass: [yes]
---------------------------------------------------------------------------
by fabpot at 2012-03-29T09:19:07Z
Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by liuggio at 2012-03-29T10:17:59Z
Done.
Commits
-------
d243097 Run built-in server on dev environment
Discussion
----------
Run built-in server on dev environment
Bug fix: yes?
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Change the router of the built-in server command to run on dev environment.
The symfony standard edition doesn't have any `/` route by default (it's only available to dev), so by default, when ran, it gives a `404`, unless you explicitely add the `app_dev.php` front controller to the route.
Also, this server is meant to be run on dev only, so no need to run it with the prod front controller by default.
Commits
-------
cdba4cf [FrameworkBundle] Change XSD to allow string replacements on session args.
52f7955 [FrameworkBundle] Remove default from gc_* session configuration keys.
749593d [FrameworkBundle] Allow configuration of session garbage collection for session 'keep-alive'.
Discussion
----------
[2.1][FrameworkBundle] Allow configuration of session garbage collection
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2171
Todo: -
---------------------------------------------------------------------------
by drak at 2012-03-21T21:56:20Z
@fabpot - this PR is ready for merge. It basically allows configuration of some session ini values that are necessary in controlling the session behaviour.
---------------------------------------------------------------------------
by dlsniper at 2012-03-21T22:57:18Z
@drak shouldn't all the options here: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php#L266 be available for configuration, or am I just reading the source wrong and they already are?
In this case should I make a separate PR to cover the rest or could you do it in this one?
---------------------------------------------------------------------------
by fabpot at 2012-03-23T14:56:22Z
@drak: the discussion is the ticket is very interesting and I think it should be part of a cookbook in the documentation. Can you take care of that before I merge this PR? Thanks.
---------------------------------------------------------------------------
by drak at 2012-03-25T15:32:59Z
@fabpot - yes - it's on the todo list. Will update this PR when done.
---------------------------------------------------------------------------
by drak at 2012-03-26T19:45:13Z
@fabpot - this is ready for merging, the documentation is done (the PR is in but I'll tweak it, but no need to wait to merge this PR). I will also add something extra to cookbook (I wrote docs for the component).
Commits
-------
5ae76f1 [HttpFoundation] Update documentation.
910b5c7 [HttpFoudation] CS, more tests and some optimization.
b0466e8 [HttpFoundation] Refactored BC Session class methods.
84c2e3c [HttpFoundation] Allow flash messages to have multiple messages per type.
Discussion
----------
[2.1][HttpFoundation] Multiple session flash messages
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes, but this already happened in #2583. BC `Session` methods remain unbroken.
Symfony2 tests pass: yes
Fixes the following tickets: #1863
References the following tickets: #2714, #2753, #2510, #2543, #2853
Todo: -
This PR alters flash messages so that it is possible to store more than one message per flash type using the `add()` method or by passing an array of messages to `set()`.
__NOTES ABOUT BC__
This PR maintains BC behaviour with the `Session` class in that the old Symfony 2.0 methods will continue to work as before.
---------------------------------------------------------------------------
by drak at 2012-02-13T06:28:33Z
I think this is ready for review @fabpot @lsmith77
---------------------------------------------------------------------------
by lsmith77 at 2012-02-14T19:30:39Z
the FlashBag vs. AutoExpireFlashBag behavior and setup difference should probably also be explained in the upgrading log
---------------------------------------------------------------------------
by drak at 2012-02-15T04:43:14Z
@lsmith77 Those differences are explained already in the changelog
* Added `FlashBag`. Flashes expire when retrieved by `get()` or `all()`.
This makes the implementation ESI compatible.
* Added `AutoExpireFlashBag` (default) to replicate Symfony 2.0.x auto expire behaviour of messages auto expiring
after one page page load. Messages must be retrived by `get()` or `all()`.
---------------------------------------------------------------------------
by Crell at 2012-02-19T17:35:34Z
Drak asked me to weigh in here with use cases. Drupal currently has a similar session-stored-messaging system in place that I'd like to be able to replace with Flash messages. We frequently have multiple messages within a single request, however, so this change is critical to our being able to do so.
For instance, when saving an article in Drupal there is, by default, a "yay, you saved an article!" type message that gets displayed. If you also have the site configured to send email when a post is updated, you may see a "email notifications sent" message (depending on your access level). If you have a Solr server setup for search, and you're in debug mode, there will also be a "record ID X added to Solr, it should update in 2 minutes" message. And if there's a bug somewhere, you'll also get, as an error message rather than notice message, a "Oops, E_NOTICE on line 54" message.
Form validation is another case. If you have multiple errors in a single form, we prefer to list all of them. So if you screw up 4 times on a form, you may get 4 different error messages showing what you screwed up so you can fix it in one go instead of several.
Now sure, one could emulate that by building a multi-message layer on top of single-layer messages, but, really, why? "One is a special case of many", and there are many many cases where you'll want to post multiple messages. Like, most of Drupal. :-)
---------------------------------------------------------------------------
by lsmith77 at 2012-03-06T20:55:51Z
@fabpot is there any information you still need before merging this? do you want more discussion in which case you might want to take this to the mailing list ..
---------------------------------------------------------------------------
by drak at 2012-03-08T18:54:13Z
Another plus for this PR is that it requires no extra lines of code in templates etc to display the flashes, see https://github.com/symfony/symfony/pull/3267/files#diff-1
---------------------------------------------------------------------------
by drak at 2012-03-15T06:38:21Z
Rebased against current `master`, should be mergeable again..
---------------------------------------------------------------------------
by evillemez at 2012-03-17T03:08:41Z
+1 to this, I have an extended version of HttpFoundation just for this... would love to get rid of it.
Commits
-------
df11e62 [FrameworkBundle] Used $output->write() instead of echo
c3bf479 [FrameworkBundle] Used Process component
cfa2dff [FrameworkBundle] Changed server:run command description
e7d38c1 [FrameworkBundle] Changed PHP version detection (see: #3529)
4a3f6d5 [FrameworkBundle] Removed global variable from router script
519d431 [FrameworkBundle] Fixed built-in server router script
d9a0a17 [FrameworkBundle] Added server:run command
Discussion
----------
[FrameworkBundle] Added server:run command (PHP 5.4 built-in web server)
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/michal-pipa/symfony)
Fixes the following tickets: -
Todo: -
PHP 5.4 comes with [built-in web server](http://www.php.net/manual/en/features.commandline.webserver.php). I've created command which allows to easily run Symfony2 application using this new feature.
Usage:
server:run [-d|--docroot="..."] [-r|--router="..."] [address]
Arguments:
address Address:port (default: 'localhost:8000')
Options:
--docroot (-d) Document root (default: 'web/')
--router (-r) Path to custom router script
Help:
The server:run runs Symfony2 application using PHP built-in web server:
app/console server:run
To change default bind address and port use the address argument:
app/console server:run 127.0.0.1:8080
To change default docroot directory use the --docroot option:
app/console server:run --docroot=htdocs/
If you have custom docroot directory layout, you can specify your own
router script using --router option:
app/console server:run --router=app/config/router.php
See also: http://www.php.net/manual/en/features.commandline.webserver.php
It requires PHP 5.4, otherwise this command will be disabled.
I think that this is very convenient (especially for new users). All you have to do is download Symfony, install vendors and run this command. You don't have to configure "real" web server, in fact any other server is not required. You don't have cache and logs permission problem, because server runs with your local user permissions.
---------------------------------------------------------------------------
by blogsh at 2012-03-06T17:38:10Z
Great feature! I was about to write something like this when I saw that you have already started implementing this :)
Some issues:
1. Missing newlines at the end of the files
2. If I try this server command with the default Symfony Standard Edition Acme demo the links on the main page do not work. The demo link links to "//demo" and the configurator link to "//_configurator". If I go to `localhost:8000/demo` directly the page is rendered as usual and all sub links are generated correctly. I could solve the problem by adding one line:
$_SERVER['SCRIPT_FILENAME'] = 'ANYTHING';
require 'app_dev.php';
I'm not sure where this problem comes from. Do you experience the same behaviour? Otherwise I'll do some more investigations to find the source of the problem.
3 . I think it would be a nice feature if you would generate a router.php based on the setting of the --env flag if no custom router file has been specified. This way it would be easy to switch between dev and prod.
---------------------------------------------------------------------------
by michal-pipa at 2012-03-06T19:00:24Z
@blogsh
> Missing newlines at the end of the files
I've checked and I can see newlines at the end of files. Are you sure about this?
> If I try this server command with the default Symfony Standard Edition Acme demo the links on the main page do not work. The demo link links to "//demo" and the configurator link to "//_configurator". If I go to localhost:8000/demo directly the page is rendered as usual and all sub links are generated correctly. I could solve the problem by adding one line:
>
> $_SERVER['SCRIPT_FILENAME'] = 'ANYTHING';
> require 'app_dev.php';
>
> I'm not sure where this problem comes from. Do you experience the same behaviour? Otherwise I'll do some more investigations to find the source of the problem.
I can reproduce this by changing front controller name from `app.php` to `app_dev.php`. I'll investigate on this.
> I think it would be a nice feature if you would generate a router.php based on the setting of the --env flag if no custom router file has been specified. This way it would be easy to switch between dev and prod.
You can easily change environment specifying front controller in URL. It works exactly the same way as default Apache configuration. This is intended behavior, as it would be misleading if every server had different rewrite rules.
If you really want to change it, then you can write your own router and pass it as a value to `router` option.
---------------------------------------------------------------------------
by blogsh at 2012-03-06T19:13:55Z
Wasn't aware that github omits the trailing white line, sorry.
Normally I use a rather inflexible nginx configuration, so I also wasn't aware of this (rather obvious) trick of changing the url. Thanks for that.
---------------------------------------------------------------------------
by stof at 2012-03-06T22:12:16Z
@blogsh it does not omit it. It displays it in the Linux way where the newline char is part of the line (and so there is a message ``no newline at end of file`` in the diff when it is missing).
---------------------------------------------------------------------------
by michal-pipa at 2012-03-07T07:18:23Z
@blogsh I've fixed router script. Now you can use both front controllers.
---------------------------------------------------------------------------
by michal-pipa at 2012-03-07T07:34:58Z
I've also hardcoded front controller name in router script and removed global variable, as there was no way to unset it.
---------------------------------------------------------------------------
by michal-pipa at 2012-03-13T07:57:04Z
I've used Process component, but now I don't get any stdout output (only stderr).
---------------------------------------------------------------------------
by michal-pipa at 2012-03-13T18:01:58Z
I've replaced `echo` by `$output->write()` and removed `$process` as it was not used actually.
Commits
-------
1422133 [TwigBundle] Made docblock for findTemplate() more general and accurate
5910ac9 [TwigBundle] Added a use statement to shorten class name in a docblock
3e7eebd [TwigBundle] Improved ExceptionController docblocks
Discussion
----------
[TwigBundle] Improved ExceptionController docblocks
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/lencioni/symfony)
Fixes the following tickets: -
Todo: -
---------------------------------------------------------------------------
by lencioni at 2012-03-21T20:47:16Z
I obviously don't know what I'm doing here. :/
---------------------------------------------------------------------------
by vicb at 2012-03-21T20:47:39Z
no pb just rebase on master and force push
Commits
-------
00ae766 [FrameworkBundle] added new french validators translations for the File constraint.
Discussion
----------
[FrameworkBundle] added new french validators translations for the File ...
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/lencioni/symfony)
Fixes the following tickets: -
Todo: -
Relying on decrementing a counter has two problems. First, and most importantly, if the output buffering nesting level is greater than the counter, the function does not perform the expected task. Secondly, on systems where the counter is needed, a lot of unnecessary extra loops would potentially occur.
This approach checks to see if the level has stayed the same from the previous iteration and if it has it stops looping.
Commits
-------
eee5065 [TwigBundle] Workaround a flaw in the design of the configuration (normalization)
Discussion
----------
[TwigBundle] Workaround a flaw in the design of the configuration (norma...
...lization)
see #2823
@Seldaek please comment.
---------------------------------------------------------------------------
by Seldaek at 2012-03-09T20:52:47Z
It seems fine at first glance. I don't have time to look at it in detail right now sorry.
Commits
-------
0e4f789 changed test config
a98d554 [SecurityBundle] Allow switching to the user that is already impersonated (fix#2554)
Discussion
----------
[Security] Disabled exception when switching to the user that is already impersonated
Bug fix: yes-ish
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2554
Todo: -
---------------------------------------------------------------------------
by vicb at 2012-03-13T14:31:45Z
@meandmymonkey thank you for your work on this issue. Would you have time to add functional tests ?
---------------------------------------------------------------------------
by meandmymonkey at 2012-03-13T14:49:52Z
Probably not today, but during the next few days, yes, of course.
---------------------------------------------------------------------------
by meandmymonkey at 2012-03-14T18:05:19Z
@vicb @schmittjoh Writing the tests I noticed switching to an non-existent user will not raise an exception. While it's not a security issue, it should raise an error for completeness sake, shouldn't it?
---------------------------------------------------------------------------
by vicb at 2012-03-14T20:28:52Z
I think it should (throw an `AuthenticationCredentialsNotFoundException`). _btw there is an extra `sprintf` in the original code that could be remove when attempting to exit_
---------------------------------------------------------------------------
by meandmymonkey at 2012-03-14T21:13:16Z
The problem with throwing an `AuthenticationCredentialsNotFoundException` (or any other security exception for that matter) is that it derives from `AuthenticationException`, which means it gets caught by the framework and redirects to the login form, which is not what we want in this case.
We need to throw something 500-ish at [L89](d40b3376ec/src/Symfony/Component/Security/Http/Firewall/SwitchUserListener.php (L89)), either a generic or a (new) custom Exception.
---------------------------------------------------------------------------
by meandmymonkey at 2012-03-14T21:43:57Z
IMHO a `LogicException`would be fine, like the one used at [L117](d40b3376ec/src/Symfony/Component/Security/Http/Firewall/SwitchUserListener.php (L117)), as the error is not really about a failed authentication.
---------------------------------------------------------------------------
by vicb at 2012-03-14T21:49:04Z
I agree and btw very good job on the tests !
---------------------------------------------------------------------------
by meandmymonkey at 2012-03-14T22:12:43Z
Thanks :)
---------------------------------------------------------------------------
by vicb at 2012-03-15T08:01:13Z
Could you squash the commits, prefix the commit message with `[SecurityBundle]` and add `(fix#2554)` at the end ?
---------------------------------------------------------------------------
by meandmymonkey at 2012-03-15T08:53:12Z
Done.
---------------------------------------------------------------------------
by vicb at 2012-03-15T09:19:09Z
@fabpot this PR looks good to me.
---------------------------------------------------------------------------
by fabpot at 2012-03-15T12:50:50Z
Tests do not pass when you run them all.
---------------------------------------------------------------------------
by meandmymonkey at 2012-03-15T13:41:45Z
@fabpot @vicb With this config change, they pass when run together.
What is weird though is that the reason seems to be that the config for the profiler gets overwritten when running all tests together, while being used correctly when run alone. Any idea what can cause this? They should be isolated from each other.
The new config from 0e4f789 works, but enables the profiler for all SecurityBundle Tests... which is not strictly necessary.
Disabled exception when switching to the user that is already impersonated, exception is now only thrown when trying to switch to a new user.
Added an Excption exception when switching fails because target user does not exist.
Added funtional tests for switching users.
Commits
-------
eb9bf05 [HttpFoundation] Remove hard coded assumptions and replace with API calls.
9a5fc65 [HttpFoundation] Add more tests.
68074a2 Changelog and upgrading changes.
7f33b33 Refactor SessionStorage to NativeSessionStorage.
b12ece0 [HttpFoundation][FrameworkBundle] Separate out mock session storage and stop polluting global namespace.
d687801 [HttpKernel] Mock must invoke constructor.
7b36d0c [DoctrineBridge][HttpFoundation] Refactored tests.
39526df [HttpFoundation] Refactor away options property.
21221f7 [FrameworkBundle] Make use of session API.
cb873b2 [HttpFoundation] Add tests and some CS/docblocks.
a6a9280 [DoctrineBridge] Refactor session storage to handler.
a1c678e [FrameworkBundle] Add session.handler service and handler_id configuration property.
1308312 [HttpFoundation] Add and relocate tests.
88b1170 [HttpFoundation] Refactor tests.
2257a3d [HttpFoundation] Move session handler classes.
0a064d8 [HttpFoundation] Refactor session handlers.
2326707 [HttpFoundation] Split session handler callbacks to separate object.
bb30a44 [HttpFoundation] Prepare to split out session handler callback from session storage.
Discussion
----------
[2.1] Support PHP 5.4 \SessionHandler
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This patch allows us to add services, like an encryption layer into any session handler without having to alter or inherit any code across any session handler, internal or custom.
The `\SessionHandler` class exposes internal PHP's native internal session save handlers like files, memcache, and sqlite by wrapping the internal callbacks through the class giving user-space the chance to intercept, override and filter them by inheriting from `\SessionHandler`. I've written a pretty nice use-case at http://docs.php.net/sessionhandler which really shows the power of it. I never considered how to make proper use of the `\SessionHandler` in Symfony2 until I wrote the code example you see in that documentation and also because of the `AbstractSessionStorage` base class got in the way.
It's really trivial to enable support for this in Symfony2 but requires to separate out the actual handlers because inheritance is not suitable.
Obviously, the feature will only work with internal PHP-extension provided handlers under PHP 5.4 and will already work in PHP 5.3 with any custom handler (since they all implement `\SessionHandlerInterface`). Symfony2 will also be the first framework to support these amazing features :-D
The necessary changes are really small but beautiful:
The basic idea is this: 1d55d1ff14 removed inheritance and separates out the actual session handler callbacks - the part PHP processes internally.
This is supported by an internal proxy mechanism: 10a36c901e
In terms of BC, not much changes net from 2.0:
- We can restore the deprecated service ID: `session.storage.native`
- We add a new service ID `session.handler` (and configuration alias `handler_id`) for the actual session handlers. This defaults to the renamed `session.handler.native_file` session handler (same behaviour just new name and as it's a default there is no BC break).
---------------------------------------------------------------------------
by fabpot at 2012-03-03T12:15:10Z
Looks good to me. Can you update the CHANGELOG and UPGRADE file accordingly and start to update the documentation at symfony/symfony-docs? Thanks for your work, the session handling in Symfony2 is starting to become amazing!
---------------------------------------------------------------------------
by drak at 2012-03-04T11:09:31Z
@fabpot I will start working on documentation this week and get the CHANGELOG/UPGRADING committed shortly. I'll ping when done.
---------------------------------------------------------------------------
by drak at 2012-03-14T16:48:37Z
@fabpot - This PR is ready now.
Revert service back to session.storage.native
Rename session.storage.native_file to session.handler.native_file (which is the default so no BC break from 2.0)
Commits
-------
14a18ae [WebProfilerBundle] Optimized toolbar and profiler icons with optiPNG
Discussion
----------
[WebProfilerBundle] Optimized toolbar and profiler icons with optiPNG
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Optimized web toolbar and profiler icons (pngs) to slightly reduce PNG sizes. Lossless compression.
Commits
-------
afbb8f2 Fixed misleading help for "name" argument as search for services with wildcards is not implemented
Discussion
----------
[FrameworkBundle, Console] Changed help text for container:debug command
Fixed help for "name" argument as search for services with wildcards is not implemented in ContainerDebugCommand
This quickly addresses the problem when the helper is constructed in a console environment without request scope. Ideally, the helper should be able to construct the absolute logout URL using data already available in the UrlGenerator's RequestContext and the $_SERVER environment variable; however, that will require copying some code from the Request class to create a base URI and path.
Fixes#3508
Commits
-------
b73c703 Reverting return type left by mistake
881d290 Updating use of DoctrineBundle Registry to use the proper path to Doctrine\Bundle\DoctrineBundle\Registry
Discussion
----------
Updating use of DoctrineBundle Registry to use the proper path
Pointed to the new class: Doctrine\Bundle\DoctrineBundle\Registry
---------------------------------------------------------------------------
by adrienbrault at 2012-03-01T22:12:42Z
I think the return type should stay ```Registry```
---------------------------------------------------------------------------
by rdohms at 2012-03-01T22:48:35Z
Yes, that was a mistake, reverted.
Commits
-------
49a8654 [Security] Use LogoutException for invalid CSRF token in LogoutListener
a96105e [SecurityBundle] Use assertCount() in tests
4837407 [SecurityBundle] Fix execution of functional tests with different names
66722b3 [SecurityBundle] Templating helpers to generate logout URL's with CSRF tokens
aaaa040 [Security] Allow LogoutListener to validate CSRF tokens
b1f545b [Security] Refactor LogoutListener constructor to take options
c48c775 [SecurityBundle] Add functional test for form login with CSRF token
Discussion
----------
[Security] Implement support for CSRF tokens in logout URL's
```
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
[](http://travis-ci.org/jmikola/symfony)
This derived from #3006 but properly targeting on the master branch.
This exposes new configuration options to the logout listener to enable CSRF protection, as already exists for the form login listener. The individual commits and their extended messages should suffice for explaining the logical changes of the PR.
In addition to changing LogoutListener, I also created a templating helper to generate logout URL's, which includes a CSRF token if necessary. This may or may not using routing, depending on how the listener is configured since both route names or hard-coded paths are valid options.
Additionally, I added unit tests for LogoutListener and functional tests for both CSRF-enabled form logins and the new logout listener work.
Kudo's to @henrikbjorn for taking the time to document CSRF validation for form login listeners (see [here](http://henrik.bjrnskov.dk/symfony2-cross-site-request-forgery/)). The [Logout CSRF Protection](http://www.yiiframework.com/wiki/190/logout-csrf-protection/) article on the Yii Framework wiki was also helpful in drafting this.
---------------------------------------------------------------------------
by jmikola at 2011-12-31T07:50:31Z
Odd that Travis CI reported a build failure for PHP 5.3.2, but both 5.3 and 5.4 passed: http://travis-ci.org/#!/jmikola/symfony/builds/463356
My local machine passes as well.
---------------------------------------------------------------------------
by jmikola at 2012-02-06T20:05:30Z
@schmittjoh: Please let me know your thoughts on the last commit. I think it would be overkill to add support for another handler service and/or error page just for logout exceptions.
Perhaps as an alternative, we might just want to consider an invalid CSRF token on logout imply a false return value for `LogoutListener::requiresLogout()`. That would sacrifice the ability to handle the error separately (which a 403 response allows us), although we could still add logging (currently done in ExceptionListener).
---------------------------------------------------------------------------
by jmikola at 2012-02-13T17:41:33Z
@schmittjoh: ping
---------------------------------------------------------------------------
by fabpot at 2012-02-14T23:36:22Z
@jmikola: Instead of merging symfony/master, can you rebase?
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:00:49Z
Will do.
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:05:48Z
```
[avocado: symfony] logout-csrf (+9/-216) $ git rebase master
First, rewinding head to replay your work on top of it...
Applying: [SecurityBundle] Add functional test for form login with CSRF token
Applying: [Security] Refactor LogoutListener constructor to take options
Applying: [Security] Allow LogoutListener to validate CSRF tokens
Applying: [SecurityBundle] Templating helpers to generate logout URL's with CSRF tokens
Applying: [SecurityBundle] Fix execution of functional tests with different names
Applying: [SecurityBundle] Use assertCount() in tests
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Applying: [Security] Use LogoutException for invalid CSRF token in LogoutListener
[avocado: symfony] logout-csrf (+7) $ git st
# On branch logout-csrf
# Your branch and 'origin/logout-csrf' have diverged,
# and have 223 and 9 different commit(s) each, respectively.
#
nothing to commit (working directory clean)
[avocado: symfony] logout-csrf (+7) $
```
After rebasing, my merge commits disappeared. Is this normal?
---------------------------------------------------------------------------
by stof at 2012-02-15T00:15:07Z
Are you sure they disappeared ? Diverging from the remote branch is logical (you rewrote the history and so changed the commit id) but are you sure it does not have the commits on top of master ? Try ``git log master..logout-scrf``
If your commut are there, you simply need to force the push for the logout-csrf branch (take care to push only this branch during the force push to avoid messing all others as git won't warn you when asking to force)
---------------------------------------------------------------------------
by stof at 2012-02-15T00:17:09Z
ah sorry, you talked only about the merge commit. Yeah it is normal. When reapplying your commits on top of master, the merge commit are not kept as you are reapplying the changes linearly on top of the other branch (and deleting the merge commit was the reason why @fabpot asked you to rebase instead of merging btw)
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:18:00Z
The merge commits are not present in `git log master..logout-csrf`. Perhaps it used those merge commits when rebasing, as there were definitely conflicts resolved when I originally merged in symfony/master (@fabpot had made his own changes to LogoutListener).
I'll force-push the changes to my PR brange. IIRC, GitHub is smart enough to preserve inline diff comments, provided they were made through the PR and not on the original commits.
---------------------------------------------------------------------------
by jmikola at 2012-02-15T00:19:38Z
That worked well. In the future, I think I'll stick to merging upstream in and then rebasing afterwards. Resolving conflicts is much easier during a merge than interactive rebase.
---------------------------------------------------------------------------
by jmikola at 2012-02-23T18:46:13Z
@fabpot @schmittjoh: Is there anything else I can do for this PR? I believe the exception was the only outstanding question (see: [this comment](https://github.com/symfony/symfony/pull/3007#issuecomment-3835716)).
Commits
-------
bafcaaf Removed version field
f9d9dc7 Add branch-alias for composer
Discussion
----------
Add branch-alias for composer
This should restore the 2.1-dev version (as an alias of dev-master) so that `2.*` or `2.1.*` constraints work again. I'll adjust packagist soon to also display those aliases.
Commits
-------
6e75fd1 Resolves issue with spl_autoload_register creating new copies of the container and passing that into the closure.
Discussion
----------
[DoctrineBundle] fixed proxy loader memory leak
[](http://travis-ci.org/kriswallsmith/symfony)
The hack for loading Doctrine proxy classes has an obscure memory leak, fixed here by @jjbohn.
## The Proof
Run this test case before and after this patch:
```php
<?php
namespace Kris\JunkBundle\Tests\Controller;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
class DefaultControllerTest extends WebTestCase
{
/**
* @dataProvider asdf
*/
public function testIndex()
{
$client = static::createClient();
$crawler = $client->request('GET', '/hello/Fabien');
$this->assertTrue($crawler->filter('html:contains("Hello Fabien")')->count() > 0);
}
public function asdf()
{
return array_fill(0, 500, array());
}
}
```
### Before
```
~/Sites/symfony/standard (2.0) $ phpunit -c app/
PHPUnit 3.6.10 by Sebastian Bergmann.
Configuration read from /Users/kriswallsmith/Sites/symfony/standard/app/phpunit.xml.dist
............................................................... 63 / 500 ( 12%)
............................................................... 126 / 500 ( 25%)
............................................................... 189 / 500 ( 37%)
............................................................... 252 / 500 ( 50%)
............................................................... 315 / 500 ( 63%)
............................................................... 378 / 500 ( 75%)
............................................................... 441 / 500 ( 88%)
...........................................................
Time: 31 seconds, Memory: 289.50Mb
OK (500 tests, 500 assertions)
```
### After
```
~/Sites/symfony/standard (2.0) $ phpunit -c app/
PHPUnit 3.6.10 by Sebastian Bergmann.
Configuration read from /Users/kriswallsmith/Sites/symfony/standard/app/phpunit.xml.dist
............................................................... 63 / 500 ( 12%)
............................................................... 126 / 500 ( 25%)
............................................................... 189 / 500 ( 37%)
............................................................... 252 / 500 ( 50%)
............................................................... 315 / 500 ( 63%)
............................................................... 378 / 500 ( 75%)
............................................................... 441 / 500 ( 88%)
...........................................................
Time: 40 seconds, Memory: 51.25Mb
OK (500 tests, 500 assertions)
```
## tl;dr
Your test suite will use much less memory — 82% in this case.
```
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
---------------------------------------------------------------------------
by mvrhov at 2012-02-23T06:25:57Z
IMHO this change warrants a comment inside a source code as somebody might actually try to remove the first by reference assign like stof said.
---------------------------------------------------------------------------
by lsmith77 at 2012-02-23T07:55:48Z
this autoloader sounds like something we also need in the ODM's?
---------------------------------------------------------------------------
by stof at 2012-02-23T08:23:17Z
@lsmith77 if you want to allow unserializing proxies without forcing to generate them before (which would be an issue in debug mode), yeah. But take care that each Doctrine bundle should use a different proxy namespace to allow doing the check (there was some issues for people using both the ORM and the mongo ODM because of this)
---------------------------------------------------------------------------
by lsmith77 at 2012-02-23T08:24:33Z
then maybe this could should be a static method inside the bridge?
---------------------------------------------------------------------------
by beberlei at 2012-02-23T11:50:08Z
I think another side of this problem is that ->boot() ALWAYS adds this method on the autoloading stack. So with N tests you have N more autoloaders on the stack.
---------------------------------------------------------------------------
by pminnieur at 2012-02-23T12:07:00Z
This could be an issue if you use Symfony with Leach as an application server, too. After a while, memory is exhausted in face of `gc_collect_cycles` and `$kernel->boot()` and `$kernel->shutdown()` calls in between each request - which ultimately leads to a segfault after some time. I tried to track down what causes increasing memory usage and I think this could be the error.
---------------------------------------------------------------------------
by beberlei at 2012-02-23T12:28:06Z
its definately the problem, we need to remove the autoloader in shutdown, or move it elsewhere.
---------------------------------------------------------------------------
by lsmith77 at 2012-02-23T14:58:37Z
why isnt this just a setup task for the autoloader just like the annotation registry?
---------------------------------------------------------------------------
by stof at 2012-02-23T16:52:42Z
@lsmith77 because the proxy namespace and the proxy dir are not known in the autoload.php file. They are configured in the config files
---------------------------------------------------------------------------
by fabpot at 2012-02-23T18:05:51Z
The `shutdown()` method is where the autoloader should be removed. Can we include this in this PR as well so that we fix everything once and for all?
---------------------------------------------------------------------------
by kriswallsmith at 2012-02-23T19:12:05Z
The once and for all solution is for the Doctrine O*M projects to provide a ProxyLoader class with register and unregister methods that we call in boot and shutdown. We're not solving anything specific to Symfony here.
Commits
-------
0a176eb [FrameworkBundle] Fix configuration errors
6745b28 [Config] Throw exceptions on invalid definition
fb27de0 [Config] cleanup
Discussion
----------
[Config] Cleanup, error detection, fixes
see #3357
---------------------------------------------------------------------------
by stloyd at 2012-02-15T10:56:00Z
@vicb As you added new exceptions, IMO you should add some tests to cover it.
---------------------------------------------------------------------------
by vicb at 2012-02-15T10:56:50Z
good point, I'll do.
---------------------------------------------------------------------------
by vicb at 2012-02-15T13:49:44Z
@stloyd that was a great idea, I realized I had miss a case. It has been added and should be covered by UT + fixes made.
I am done with the fixes, should be ready to merge.
And time to give the `PrototypedArrayNode` some more usability now.
Commits
-------
ed028d5 [WebProfilerBundle] Made is_ajax available to the view when rendering panels
Discussion
----------
[Profiler] Ajax
The first commit should be merged as `app` is not always accessible in the twig template due to the ways the templating system is used. Then there is currently no way to check if we are dealing with an ajax request in the view.
The second commit use ajax to load the panels. This should make the interface more responsive as you don't have to load the layout each time + the panels are cached. Loading via AJAX would also work if your panel does not extend the ajax layout (legacy support) - this would be less efficient though as you would load the layout and filter it out afterwards.
I am not sure if the second commit is worth merging, maybe it is useless ?
---------------------------------------------------------------------------
by stof at 2012-02-12T20:40:16Z
@vicb please rebase
---------------------------------------------------------------------------
by stof at 2012-02-13T17:48:48Z
@vicb just FYI, this conflicts with master so you will need to rebased it before it can be merged.
Otherwise, what are the remaining points ?
---------------------------------------------------------------------------
by vicb at 2012-02-13T17:57:27Z
I am still wondering if the second commit is a good idea or not ?
---------------------------------------------------------------------------
by vicb at 2012-02-13T18:28:17Z
@stof isn't the branch based on the latest master ?
---------------------------------------------------------------------------
by stof at 2012-02-13T19:32:52Z
Well, github tells me it cannot be merged automatically. so either there is a conflict, either their conflict detection failed last time you pushed.
---------------------------------------------------------------------------
by vicb at 2012-02-13T22:20:06Z
I did fail.
Should be ok now.
---------------------------------------------------------------------------
by fabpot at 2012-02-14T23:27:08Z
I'm -1 on the second commit.
---------------------------------------------------------------------------
by vicb at 2012-02-15T07:44:25Z
Thanks all for the feedback.
@fabpot ready !
---------------------------------------------------------------------------
by stof at 2012-02-15T07:46:53Z
@vicb not ready: you reverted all use of ``is_ajax`` in the templates (and you did not renamed it to the underscored name preferred by @fabpot)
---------------------------------------------------------------------------
by vicb at 2012-02-15T07:54:30Z
Well I did revert the use of "`isajax`" (prefer not to mix CS here, the scope of this PR is not to fix CS) because it is not used (this should be applied to the Doctrine profiler).
_What I mean is that `isajax` in all the Sf templates w/o the associated js is useless, basically all or nothing_
---------------------------------------------------------------------------
by vicb at 2012-02-15T08:26:41Z
btw @fabpot it makes me wonder if underscored variable names is a good idea, this will force us to mix (i.e. `is_ajax` vs `request.isxmlhttprequest`). What do you think ?
---------------------------------------------------------------------------
by fabpot at 2012-02-15T10:09:20Z
I still prefer `is_ajax` as it makes things more readable.
---------------------------------------------------------------------------
by vicb at 2012-02-15T10:16:13Z
At a larger scale how do fix the inconsistency described in my previous message ?
Options are:
* fix twig cs
* create twig cs specific to sf2
* don't fix (= keep & live with some inconsistency)
---------------------------------------------------------------------------
by stof at 2012-02-15T10:22:13Z
@vicb we also use underscores for variables used in the form themes. the official Twig CS are basically the one used by Sf2 in the form theme
---------------------------------------------------------------------------
by fabpot at 2012-02-15T10:24:46Z
I don't see any inconsistencies here. One a variable name and the other is a method call/property name. So, my vote is a don't fix.
---------------------------------------------------------------------------
by vicb at 2012-02-15T10:28:53Z
I agree but then we loose one advertised benefit a twig: _"Easy to learn: The syntax is easy to learn and has been optimized to allow web designers to get their job done fast without getting in their way"_.
The designers should now be aware of the underlying implementation (i.e. Am I dealing with a variable or a function ?)
Edit: race condition here... I agree with @stof
---------------------------------------------------------------------------
by stof at 2012-02-15T10:45:49Z
@vicb they see that ``isXmlHttpRequest`` is not a variable. They are accessing it on the ``request`` variable (well, recurse here to reach the variable)
---------------------------------------------------------------------------
by fabpot at 2012-02-15T10:46:57Z
variables and functions are underscored.
---------------------------------------------------------------------------
by vicb at 2012-02-15T10:51:28Z
I think that the beauty of Twig comes from the fact that designers do not have to wonder if "something" is an array / an object / a variable / a method / a property.
But never mind, I'll update the PR.
---------------------------------------------------------------------------
by vicb at 2012-02-15T10:55:06Z
@fabpot would you mind if I open a PR against twig to check for existence of `collector::getNotCalledListeners()` when a designer writes `collector.not_called_listeners`, then we are all happy ?
---------------------------------------------------------------------------
by vicb at 2012-02-15T11:21:55Z
ready !
---------------------------------------------------------------------------
by fabpot at 2012-02-15T11:31:50Z
The problem is that the `Twig_Template::getAttribute()` is already the bottleneck
Using "securitybundletest" as the default environment for the functional test's kernel causes a PHP fatal error redeclaring the class "appSecuritybundletestDebugProjectContainer" when multiple tests (with unique names) are executed. In lieu of forcing tests to specify their own environment explicitly, we can simply append the test name into the environment.
Note: this bug may be related to PHPUnit executing multiple tests within the same process.
As each firewall is configured, its logout listener (if any) will be registered with the LogoutUrlHelper service. In a template, this helper may be used to generate relative or absolute URL's to a particular firewall's logout path. A CSRF token will be appended to the URL as necessary.
The Twig extension composes the helper service to avoid code duplication (see: #2999).
This adds several new options to the logout listener, modeled after the form_login listener:
* csrf_parameter
* intention
* csrf_provider
The "csrf_parameter" and "intention" have default values if omitted. By default, "csrf_provider" is empty and CSRF validation is disabled in LogoutListener (preserving BC). If a service ID is given for "csrf_provider", CSRF validation will be enabled. Invalid tokens will result in an InvalidCsrfTokenException being thrown before any logout handlers are invoked.
Commits
-------
cea2c7e removed unneeded local variable
924f378 updated changelog
72d5805 changed route name
41cc0d6 [FrameworkBundle] added support for HInclude
Discussion
----------
[FrameworkBundle] added support for HInclude
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: discuss
Example: https://github.com/kbond/symfony-standard/tree/hinclude
**Reopened this as I broke #2903**
References:
- http://groups.google.com/group/symfony-devs/browse_thread/thread/b74e587d6f2f87b0
- http://groups.google.com/group/symfony-devs/browse_thread/thread/8776a9833d4a5f79
- #2903
- #2865
[](http://travis-ci.org/kbond/symfony)
---------------------------------------------------------------------------
by kbond at 2012-02-11T20:27:22Z
unless there is anything else I think this is ready, want me to squash again?
---------------------------------------------------------------------------
by fabpot at 2012-02-11T21:07:33Z
@kbond: Can you add some information about the changes in the CHANGELOG?
---------------------------------------------------------------------------
by Tobion at 2012-02-11T21:33:32Z
Do I see it correctly that we cannot set a default template on a per hinclude tag basis? But only global?
That's not really usefull when javascript is disabled because it should resemble the content to be included as an alternative.
---------------------------------------------------------------------------
by stof at 2012-02-11T21:42:15Z
@Tobion currently it is not possible. But changing the content on a tag basis may require changing the way the render tag look like (as there is no content in the tag currently) so this needs further discussion and @fabpot said he wants to merge a first implementation without it. See the discussion above.
Commits
-------
9d6eb82 [Routing] Fix a bug in the TraceableUrlMatcher
9fc8d28 [FrameworkBundle] Fix a bug in the RedirectableUrlMatcher
4fcf9ef [Routing] Small optimization in the UrlMatcher
abc2141 [Routing] Added a missing property declaration
d86e1eb [Routing] Remove a weird dependency
Discussion
----------
[Routing] Remove a dependency on a derived class, fixes, optim
Subset of #3296 which should be acceptable.
Travis is happy.
The side effect of removing the dependency is that the `UrlMatcher` does not throw an exception any more when the scheme does not match the required scheme. I think it is better because:
* it removes a dependency on a derived class,
* it was an undocumented "feature",
* other thrown excs are component specific while this one was raw SPL.
---------------------------------------------------------------------------
by vicb at 2012-02-09T14:43:02Z
let me know what should go in 2.0 as well.
Commits
-------
b3fd2fa [Propel] Added Propel to Stopwatch
Discussion
----------
[Propel] Added Propel to Stopwatch
I've added the Stopwatch feature, everything is ready on the PropelBundle.
The trick is to log `prepare` queries in Propel, that way we got first the prepared statement, and then the executed query. That's why there is a `$isPrepare` boolean.
I kept BC if people don't update the PropelBundle too.
William
---------------------------------------------------------------------------
by stof at 2012-02-14T12:16:51Z
@willdurand toggling a flag for each call seems a bit hackish to me. Is there no better way to do it ?
---------------------------------------------------------------------------
by willdurand at 2012-02-14T12:21:38Z
Unfortunately no... But it's quite safe as we cannot change logged methods.
There is neighter start/stop methods, nor typed messages.
Le 14 févr. 2012 à 13:16, Christophe Coevoet<reply@reply.github.com> a écrit :
> @willdurand toggling a flag for each call seems a bit hackish to me. Is there no better way to do it ?
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/3352#issuecomment-3959592
---------------------------------------------------------------------------
by stof at 2012-02-14T12:26:04Z
@willdurand then let's use this for propel 1. But please improve the logging interface for Propel 2 :)
---------------------------------------------------------------------------
by willdurand at 2012-02-14T12:34:28Z
Sure! I've added that on my todolist…
2012/2/14 Christophe Coevoet <
reply@reply.github.com
>
> @willdurand then let's use this for propel 1. But please improve the
> logging interface for Propel 2 :)
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/3352#issuecomment-3959729
>
