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).
