* 2.8: (100 commits)
[DependencyInjection] provide better error message when using deprecated configuration options
[console][TableCell] get cell width without decoration.
Improve the config validation in TwigBundle
[VarDumper] Changed tooltip to expand-all keybinding in OS X
[Bridge\PhpUnit] Fix composer installed phpunit detection
[VarDumper] Fix generic casters calling order
[2.7][SecurityBundle] Remove SecurityContext from Compile
[WebProfilerBundle][logger] added missing deprecation message.
Fix profiler CSS
[Security][Acl] enforce string identifiers
[FrameworkBundle] make `templating.helper.router` service available again for BC reasons
[BrowserKit] Fix bug when uri starts with http.
bumped Symfony version to 2.7.1
updated VERSION for 2.7.0
updated CHANGELOG for 2.7.0
bumped Symfony version to 2.6.10
updated VERSION for 2.6.9
updated CHANGELOG for 2.6.9
fixed tests
bumped Symfony version to 2.3.31
...
Conflicts:
CHANGELOG-2.3.md
CHANGELOG-2.6.md
CHANGELOG-2.7.md
UPGRADE-2.7.md
UPGRADE-3.0.md
src/Symfony/Bridge/Doctrine/Form/Type/DoctrineType.php
src/Symfony/Bridge/Twig/Extension/AssetExtension.php
src/Symfony/Bridge/Twig/Tests/Extension/AssetExtensionTest.php
src/Symfony/Bridge/Twig/composer.json
src/Symfony/Bundle/FrameworkBundle/Command/TranslationDebugCommand.php
src/Symfony/Bundle/FrameworkBundle/Resources/config/templating.xml
src/Symfony/Bundle/FrameworkBundle/Resources/config/templating_php.xml
src/Symfony/Bundle/FrameworkBundle/Templating/Helper/CodeHelper.php
src/Symfony/Bundle/FrameworkBundle/composer.json
src/Symfony/Bundle/SecurityBundle/composer.json
src/Symfony/Component/Debug/ExceptionHandler.php
src/Symfony/Component/DependencyInjection/Container.php
src/Symfony/Component/DependencyInjection/Definition.php
src/Symfony/Component/DependencyInjection/Loader/XmlFileLoader.php
src/Symfony/Component/DependencyInjection/Loader/YamlFileLoader.php
src/Symfony/Component/DependencyInjection/Tests/Fixtures/xml/legacy-services6.xml
src/Symfony/Component/DependencyInjection/Tests/Fixtures/xml/services6.xml
src/Symfony/Component/DependencyInjection/Tests/Fixtures/yaml/legacy-services6.yml
src/Symfony/Component/DependencyInjection/Tests/Fixtures/yaml/services6.yml
src/Symfony/Component/DependencyInjection/Tests/Loader/XmlFileLoaderTest.php
src/Symfony/Component/DependencyInjection/Tests/Loader/YamlFileLoaderTest.php
src/Symfony/Component/Form/CHANGELOG.md
src/Symfony/Component/HttpKernel/DependencyInjection/ContainerAwareHttpKernel.php
src/Symfony/Component/HttpKernel/Tests/DependencyInjection/ContainerAwareHttpKernelTest.php
src/Symfony/Component/Routing/Loader/XmlFileLoader.php
src/Symfony/Component/Routing/Loader/YamlFileLoader.php
set logger in extension , so its only done in debug mode
add psr/log to suggest of templating
add test for setLogger and refactor tests to not depend that much an
deprecated functionality
Here are the new simplified rules:
* Required cache warmers are *always* executed when the Kernel boots for the first time;
* Optional cache warmers are *only* executed from the CLI via cache:warmup
These new rules means that all the configuration settings for the cache
warmers have been removed. So, if you want the best performance, remember to
warmup the cache when going to production.
This also fixed quite a few bugs.
You must now explicitly register the templating engine you want to use:
<app:templating>
<app:engine id="twig" />
</app:templating>
app.templating:
engines: ['twig']
Symfony2 comes with two such engines: 'twig', and 'php'.
Before I explain the changes, let's talk about the current state.
Before this patch, the registerBundleDirs() method returned an ordered (for
resource overloading) list of namespace prefixes and the path to their
location. Here are some problems with this approach:
* The paths set by this method and the paths configured for the autoloader
can be disconnected (leading to unexpected behaviors);
* A bundle outside these paths worked, but unexpected behavior can occur;
* Choosing a bundle namespace was limited to the registered namespace
prefixes, and their number should stay low enough (for performance reasons)
-- moreover the current Bundle\ and Application\ top namespaces does not
respect the standard rules for namespaces (first segment should be the
vendor name);
* Developers must understand the concept of "namespace prefixes" to
understand the overloading mechanism, which is one more thing to learn,
which is Symfony specific;
* Each time you want to get a resource that can be overloaded (a template for
instance), Symfony would have tried all namespace prefixes one after the
other until if finds a matching file. But that can be computed in advance
to reduce the overhead.
Another topic which was not really well addressed is how you can reference a
file/resource from a bundle (and take into account the possibility of
overloading). For instance, in the routing, you can import a file from a
bundle like this:
<import resource="FrameworkBundle/Resources/config/internal.xml" />
Again, this works only because we have a limited number of possible namespace
prefixes.
This patch addresses these problems and some more.
First, the registerBundleDirs() method has been removed. It means that you are
now free to use any namespace for your bundles. No need to have specific
prefixes anymore. You are also free to store them anywhere, in as many
directories as you want. You just need to be sure that they are autoloaded
correctly.
The bundle "name" is now always the short name of the bundle class (like
FrameworkBundle or SensioCasBundle). As the best practice is to prefix the
bundle name with the vendor name, it's up to the vendor to ensure that each
bundle name is unique. I insist that a bundle name must be unique. This was
the opposite before as two bundles with the same name was how Symfony2 found
inheritance.
A new getParent() method has been added to BundleInterface. It returns the
bundle name that the bundle overrides (this is optional of course). That way,
there is no ordering problem anymore as the inheritance tree is explicitely
defined by the bundle themselves.
So, with this system, we can easily have an inheritance tree like the
following:
FooBundle < MyFooBundle < MyCustomFooBundle
MyCustomFooBundle returns MyFooBundle for the getParent() method, and
MyFooBundle returns FooBundle.
If two bundles override the same bundle, an exception is thrown.
Based on the bundle name, you can now reference any resource with this
notation:
@FooBundle/Resources/config/routing.xml
@FooBundle/Controller/FooController.php
This notation is the input of the Kernel::locateResource() method, which
returns the location of the file (and of course it takes into account
overloading).
So, in the routing, you can now use the following:
<import resource="@FrameworkBundle/Resources/config/internal.xml" />
The template loading mechanism also use this method under the hood.
As a bonus, all the code that converts from internal notations to file names
(controller names: ControllerNameParser, template names: TemplateNameParser,
resource paths, ...) is now contained in several well-defined classes. The
same goes for the code that look for templates (TemplateLocator), routing
files (FileLocator), ...
As a side note, it is really easy to also support multiple-inheritance for a
bundle (for instance if a bundle returns an array of bundle names it extends).
However, this is not implemented in this patch as I'm not sure we want to
support that.
How to upgrade:
* Each bundle must now implement two new mandatory methods: getPath() and
getNamespace(), and optionally the getParent() method if the bundle extends
another one. Here is a common implementation for these methods:
/**
* {@inheritdoc}
*/
public function getParent()
{
return 'MyFrameworkBundle';
}
/**
* {@inheritdoc}
*/
public function getNamespace()
{
return __NAMESPACE__;
}
/**
* {@inheritdoc}
*/
public function getPath()
{
return strtr(__DIR__, '\\', '/');
}
* The registerBundleDirs() can be removed from your Kernel class;
* If your code relies on getBundleDirs() or the kernel.bundle_dirs parameter,
it should be upgraded to use the new interface (see Doctrine commands for
many example of such a change);
* When referencing a bundle, you must now always use its name (no more \ or /
in bundle names) -- this transition was already done for most things
before, and now applies to the routing as well;
* Imports in routing files must be changed:
Before: <import resource="Sensio/CasBundle/Resources/config/internal.xml" />
After: <import resource="@SensioCasBundle/Resources/config/internal.xml" />
Let's take some examples to explain the change.
First, if you don't use any vendored bundles, this commit does not change anything.
So, let's say you use a FooBundle from Sensio. The files are stored under Bundle\Sensio\FooBundle.
And the Bundle class is Bundle\Sensio\FooBundle\SensioFooBundle.php.
Before the change, the bundle name ($bundle->getName()) would have returned 'FooBundle'.
Now it returns 'SensioFooBundle'.
Why does it matter? Well, it makes template names and controller names easier to read:
Before:
Template: Sensio\FooBundle:Bar:index.twig.html
Controller: Sensio\FooBundle:Bar:indexAction
After
Template: SensioFooBundle:Bar:index.twig.html
Controller: SensioFooBundle:Bar:indexAction
NB: Even if the change seems simple enough, the implementation is not. As finding
the namespace from the bundle class name is not trivial
NB2: If you don't follow the bundle name best practices, this will probably
leads to unexpected behaviors.
* better separation of concerns
* made TwigBundle independant of the PHP Engine from FrameworkBundle (WIP)
* removed one layer of abstraction in the Templating component (renderers)
* made it easier to create a new Engine for any templating library
* made engines lazy-loaded (PHP engine for instance is not started if you only use Twig)
* reduces memory footprint (if you only use one engine)
* reduces size of compiled classes.php cache file
These helpers have been removed as they do not work as expected.
Among other things, the order is not the right one when using PHP
templates, and adding assets from an included template is not
possible when using Twig templates.
This should be replaced by integrating a third-party library that
manages assets: minification, compilation, packaging, ...
Support for theming in PHP templates has been dropped.
True theming should support theme inheritance, e.g. mytheme <- table <- default.
Currently, the Templating component does not support such inheritance. As the
only purpose of the themes so far was to style field groups with tables or
divs, and because automatic rendering of field groups/forms through the render()
method is discouraged and only recommended for rapid prototyping, themes are
dropped for now.