merged branch franmomu/move_security_digest_data_test (PR #6183)

This PR was merged into the 2.1 branch.

Commits
-------

d03281b [Security] Move DigestDataTest.php inside the Security component

Discussion
----------

[Security] Move DigestDataTest.php inside the Security component

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Todo: -
License of the code: MIT
[TwigBundle] Fixed tests
merged branch hason/twigbundle_test (PR #6187)

This PR was merged into the 2.0 branch.

Commits
-------

acf1f86 [TwigBundle] Fixed tests

Discussion
----------

[2.0][2.1][TwigBundle] Fixed tests
Merge remote-tracking branch 'upstream/master'
Fix my code and also fix the test suite.
I found the error in my latest commit. This pass the test suite.
removed the TODO mention. Will keep the Propel code here so it can work with older version of Propel
Removed the PropelColumnTypes.php copy

Using the Propel class instead, like in Column class
merged branch Koc/critical-errors-logging (PR #5863)

This PR was merged into the master branch.

Commits
-------

acfc750 #2042 initial implementation of fatal error handler

Discussion
----------

Display traces for fatal errors

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: looks like yes
Fixes the following tickets: #2042 (partly)
License of the code: MIT

Output looks like on screen http://easycaptures.com/fs/uploaded/737/1191436899.png . I've added one line to css to prevent displaying standard xdebug trace http://easycaptures.com/fs/uploaded/737/5939488074.png

---------------------------------------------------------------------------

by Koc at 2012-11-08T21:55:41Z

So, community please advice me, how can I trigger `KernelEvents::EXCEPTION` event in `ErrorHandler` or `ExceptionHandler`? Or should I provide other event for this?

---------------------------------------------------------------------------

by stof at 2012-11-08T22:03:23Z

@Koc Don't. the exception handler is there to be the safe guard when developing, and does not depend on the kernel (which would be required to trigger the event). If you were triggering the listener again, it would mean that any exception thrown in a listener would lead to a loop.
And if it is for the fatal error handling, you simply cannot be sure the kernel is still available (and even less in a wokring state) at this point.

---------------------------------------------------------------------------

by Koc at 2012-11-08T22:06:31Z

But how can I notify logger (which will send me mail or just log this situation)?

---------------------------------------------------------------------------

by fabpot at 2012-11-09T07:33:41Z

The error handler is only registered when in debug mode in the Kernel and can be triggered very early in the handling of a request (even before we have access to the dispatcher or anything else). So, the current PR looks fine to me (apart from the typo and the lack of unit tests).

---------------------------------------------------------------------------

by Koc at 2012-11-09T09:13:03Z

> The error handler is only registered when in debug mode

Ooh! I haven't see that before. But the goal - be notified about errors by email or log-file. Like now exceptions with traces from site emails to me.

---------------------------------------------------------------------------

by fabpot at 2012-11-09T09:20:54Z

I think there are two goals. The first one being to have nice pages in the development environment when a fatal error occurs. And this PR addresses that feature quite nicely. The second can be addressed in another PR.

---------------------------------------------------------------------------

by henrikbjorn at 2012-11-14T11:50:22Z

I have some questions about the ErrorHandler. Is there a reason for it only to be registered in an debug environment (which prod is not). Would assume that if i enable the ErrorHandler in productions aswell Monolog would log thoose instead of them just vanishing?

---------------------------------------------------------------------------

by Koc at 2012-11-14T12:01:50Z

I am thinking about it too. But as Fabien says it will another PR

---------------------------------------------------------------------------

by GromNaN at 2012-11-18T10:38:09Z

You should add a memory reserve to be able to handle "Out of memory" errors.
An example is here :
https://github.com/LExpress/raven-php/blob/513d628966ffc356d827ecc48ec557675bd116b8/lib/Raven/ErrorHandler.php#L91
https://github.com/LExpress/raven-php/blob/513d628966ffc356d827ecc48ec557675bd116b8/lib/Raven/ErrorHandler.php#L62

---------------------------------------------------------------------------

by fabpot at 2012-11-28T11:35:21Z

@Koc can you finish this PR (probably by integrating the memory reserve as explained by @GromNaN)?

---------------------------------------------------------------------------

by Koc at 2012-11-28T11:46:12Z

of course, on this weekend

---------------------------------------------------------------------------

by Koc at 2012-12-02T17:44:44Z

@fabpot done
[Config] Fixed tests on Windows
[Locale] fixed tests
fix indentation problem
oups. It seems that here, we need \PDO
fix indentation problem
Implemented possibility to skip key normalization in config processing
merged branch lolautruche/configNormalizeKeysFlag (PR #6086)

This PR was submitted for the 2.1 branch but it was merged into the master branch instead (closes #6086).

Commits
-------

d4a70e8 Implemented possibility to skip key normalization in config processing

Discussion
----------

Implemented possibility to skip key normalization in config processing

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -

## Description

This PR implements the possibility to deactivate explicitly config keys normalization as it's sometimes annoying and unexpected to have `-` transformed in `_`. The default behavior is kept and deactivation is possible at the DI extension level (not possible to do it at the node level since the config processor does key normalization globally).

---------------------------------------------------------------------------

by lsmith77 at 2012-11-22T09:52:54Z

this is tricky since you might break some app config formats.

Semi related: I assume few people test their Bundles with anything but Yaml, but ATM the chances are quite good that it would also work with XML. then again many people are already not including the fix keys call so maybe we should also enable people to explicitly say which formats they support.

---------------------------------------------------------------------------

by stof at 2012-11-22T10:02:54Z

@lsmith77 you won't break anything as this PR is BC. You would brak it only if an existing bundle starts using it (and you are using XML)

---------------------------------------------------------------------------

by lsmith77 at 2012-11-22T10:14:55Z

I wasn't trying to imply it breaks BC but it would likely mean that Bundles using this would break the assumption that all formats are supported.

---------------------------------------------------------------------------

by stof at 2012-11-22T10:39:24Z

@lsmith77 The only difference is that a bundle using that would have an XML config using underscores instead of dashes (which are the XML convention).
And btw, as long as you don't provide an XSD, people can already use the underscored tags in their XML config...

---------------------------------------------------------------------------

by lsmith77 at 2012-11-22T11:49:50Z

right again. my point is that this feature breaks current assumptions. note I am not saying this should not be done either. just adding something to consider.

---------------------------------------------------------------------------

by lolautruche at 2012-11-22T16:30:20Z

Well, the real issue behind that is we currently don't know which format is used for application configuration, leading sometimes to unexpected issues. The problem is that the current *fix* is a bit brutal and magical, leading to headaches while debugging.
While a real way of dealing with config format should be the best way to fix this, allowing to throw an exception if the user format is inappropriate, this patch at least gives the opportunity to bypass this magical key normalization. A real solution should come with 2.2 or 2.3

---------------------------------------------------------------------------

by stof at 2012-11-22T17:07:17Z

Actually, this renaming of keys from dashes to underscores should probably be refactored to be aware of the tree. Because the only case where it causes some issues is for prototyped array nodes (using an associative array), as this is the only case where a key is defined by the user.

---------------------------------------------------------------------------

by lolautruche at 2012-11-23T07:30:57Z

@stof Exactly, and this is precisely where we have a problem, with prototyped array nodes. Having this key normalization aware of the tree is a nice option as well for a proper fix, but I think with this patch at least you can have *some* control :smiley:

---------------------------------------------------------------------------

by lolautruche at 2012-11-26T11:16:06Z

ping @fabpot

---------------------------------------------------------------------------

by lolautruche at 2012-12-05T09:41:49Z

Hello, any news on this ? Thanks

---------------------------------------------------------------------------

by fabpot at 2012-12-05T13:45:30Z

That can only be merged in master.

---------------------------------------------------------------------------

by lolautruche at 2012-12-05T13:47:01Z

@fabpot OK, should I open a new PR on master then ?

---------------------------------------------------------------------------

by fabpot at 2012-12-05T13:48:07Z

No, I'm going to switch the branch when merging, it was just to warn you about this.

---------------------------------------------------------------------------

by lolautruche at 2012-12-05T13:49:40Z

OK thanks :smiley:
merged branch Tobion/collection-flat (PR #6120)

This PR was merged into the master branch.

Commits
-------

51223c0 added upgrade instructions
50e6259 adjusted tests
98f3ca8 [Routing] removed tree structure from RouteCollection

Discussion
----------

[Routing] removed tree structure from RouteCollection

BC break: yes (see below)
Deprecations: RouteCollection::getParent(); RouteCollection::getRoot()
tests pass: yes

The reason for this is so quite simple. The RouteCollection has been designed as a tree structure, but it cannot at all be used as one. There is no getter for a sub-collection at all. So you cannot access a sub-collection after you added it to the tree with `addCollection(new RouteCollection())`. In contrast to the form component, e.g. `$form->get('child')->get('grandchild')`.
So you can see the RouteCollection cannot be used as a tree and it should not, as the same can be achieved with a flat array!
Using a flat array removes all the need for recursive traversal and makes the code much faster, much lighter, less memory (big problem in CMS with many routes) and less error-prone.

BC break: there is only a BC break if somebody used the PHP API for defining RouteCollection and also added a Route to a collection after it has been added to another collection.
So
```
$rootCollection = new RouteCollection();
$subCollection = new RouteCollection();
$rootCollection->addCollection($subCollection);
$subCollection->add('foo', new Route('/foo'));
```
must be updated to the following (otherwise the 'foo' Route is not imported to the rootCollection)
```
$rootCollection = new RouteCollection();
$subCollection = new RouteCollection();
$subCollection->add('foo', new Route('/foo'));
$rootCollection->addCollection($subCollection);
```

Also one must call addCollection from the bottom to the top. So the correct sequence is the following (and not the reverse)
```
$childCollection->->addCollection($grandchildCollection);
$rootCollection->addCollection($childCollection);
```

Remeber, this is only needed when using PHP for defining routes and calling methods in a special order. There is no change required when using XML or YAML for definitions. Also, I'm pretty sure that neither the CMF, nor Drupal routing, nor Silex is relying on the tree stuff. So they should also still work.

cc @fabpot @crell @dbu

One more thing: RouteCollection wasn't an appropriate name for a tree anyway as a collection of routes (that it now is) is definitely not a tree.
Yet another point: The XML declaration of routes uses the `<import>` element, which is excatly what the new implementation of addCollection without the need of a tree does. So this is now also more analogous.

---------------------------------------------------------------------------

by Koc at 2012-11-26T17:34:15Z

What benefit of this?

---------------------------------------------------------------------------

by Tobion at 2012-11-26T17:56:53Z

@Koc Why did you not simply wait for the description? ^^

---------------------------------------------------------------------------

by dbu at 2012-11-26T18:33:09Z

i love PR that remove more code than they add whithout removing functionality.

---------------------------------------------------------------------------

by Crell at 2012-11-26T18:49:52Z

There's an issue somewhere in Drupal where we're trying to use addCollection() as a shorthand for iterating over one collection and calling add() on the other for each item.  We can't do that, however, because the subcollections are not flattened properly when reading back and our current dumper can't cope with that.  So this change would not harm Drupal at all, and would mean I don't have fix a bug in our dumper. :-)  I cannot speak for any other projects, of course.

---------------------------------------------------------------------------

by Tobion at 2012-11-27T19:06:34Z

Ok, this is ready.
fix some formatting issue
remove useless ColumnMap
Add typehint to isInteger(), fix tests