* kriswallsmith/assetic/explicit-filter-config:
[AsseticBundle] added lessphp filter
[AsseticBundle] added config for image filters
[AsseticBundle] moved filters into individual config files which must be explicitly loaded
[AsseticBundle] removed configuration of default output strings
You must now explicitly load those filters you want to use in your app. Some filters have additional configuration options:
assetic:
filters:
cssrewrite: ~
yui_css: { jar: "/path/to/yuicompressor.jar" }
You can also register your own filters now by referencing a configuration file:
assetic:
filters:
my_filter:
resource: "%kernel.root_dir%/config/my_filter.xml"
foo: bar
This configuration would load the referenced configuration file and set the "assetic.filter.my_filter.foo" parameter to "bar"
* kriswallsmith/kernel/shorter-bundle-names:
updated codebase to use shorter bundle names
[HttpKernel] updated component to work with shorter bundle names
[HttpKernel] updated Bundle::getName() to validate bundle class name and rtrim "Bundle"
If PHP_PATH is not defined (default)
PHP_BINDIR is used to guess exe, but on windows this constant seems to be hardcoded and doesn't point to the good folder
So before to throw an error we check if PEAR is installed, most of the case it is, and it will have good php bin path for sure.
The rationale is that this is a very common task and we can't expect non-advanced users to have to remember what the fully-qualified
class name of the Exception is in order to use it.
* weaverryan/kernel_controller_exception_message:
[HttpKernel] Making the "no response returned from controller" more explanatory when it's possible that the user forgot a return statement in his/her controller
Controllers:
"BlogBundle:Post:show" is now "Blog:Post:show"
Templates:
"BlogBundle:Post:show.html.twig" is now "Blog:Post:show.html.twig"
Resources:
"@BlogBundle/Resources/config/blog.xml" is now "@Blog/Resources/config/blog.xml"
Doctrine:
"$em->find('BlogBundle:Post', $id)" is now "$em->find('Blog:Post', $id)"
The problem was that "data_class" was used in two places: FormBuilder::build() and PropertyPathMapper.
PropertyPathMapper was already constructed during FormType::buildForm(), so any data class changes made to the FormBuilder wouldn't affect the data class of the PropertyPathMapper anymore and so lead to an inconsistent state.