background preloader

Symfony 2.7

Facebook Twitter

New in Symfony 2.7: Twig Profiler. In Symfony project we believe that all the information relevant to developers should be one click away. That's why in Symfony 2.7 we've added a new panel with Twig information in the web debug toolbar. Currently, the information about the resources used to render each template is displayed in the Timeline panel of the Symfony profiler: Sadly, this panel doesn't provide much detail for templates. Moreover, some templates aren't registered, so their information is missing in that panel. Symfony 2.7 solves these problems thanks to the new profiler introduced by Twig in its 1.18.0 version. First, you'll see a new Twig debug panel in the web debug toolbar that gives you a quick overview of the main Twig stats: If you click on that panel, you'll see the full information collected by the Twig profiler.

Second, you'll see the full list of templates used to render the page, including the templates of third-party bundles and the template fragments: New in Symfony 2.7: the new Asset component. Prior to Symfony 2.7, web asset management was done in the Templating component. The design of that subsystem suffered from some errors (it required the request scope because it relied on the Request instance) and limitations (for example in the management of secure base URLs). In order to solve those issues, Symfony 2.7 introduces a new component called Asset. Management of web assets is now decoupled from the Templating component, which allows to reuse it outside of Symfony (for example in the Silex microframework).

The new Asset component manages URL generation and versioning of web assets such as CSS stylesheets, JavaScript files and image files. This means that your templates become less verbose and your application is more flexible, because you can change the location and version of your assets just with a few minor changes in a configuration file. The only relevant change is introduced by the base_urls option, which no longer separates regular (http) and secure (ssl) URLs. New in Symfony 2.7: Security Improvements. In addition to high impact changes and big features, the new Symfony versions always add tweaks and minor improvements across its codebase. In this article you'll learn about three small security-related changes that will improve your day-to-day productivity as developer. Some developers add a magic __toString() PHP method to their user entities to define their string representation.

This allows to use type casting such as (string) $user in the PHP application and {{ user }} in the Twig templates. However, in functional tests is common to use in-memory users to simplify tests. In Symfony 2.7 we decided to add a new method to the core User class in order to define its string representation. Symfony adds custom Twig extensions on top of Twig to integrate some components into the templates. One of the least known and used extensions are the logout_path and logout_url functions, which generate the appropriate relative or absolute URL to logout from the given firewall: New in Symfony 2.7: Translation Profiler. Internationalizing an application and assuring that all its messages are actually translated is one of the most frustrating, hassling and time-consuming tasks that developers must face. Symfony is decided to drastically simplify this process while boosting your productivity.

That's why in Symfony 2.7, the web debug toolbar will show a new translation panel. This panel provides a quick overview of the status of your application translation: Translation messages are divided into three categories: defined (the messages that have already been translated), missing (the messages left to be translated) and same as fallback (messages which aren't translated but are available in the default locale configured in the application).

If you click on the toolbar panel, you'll see the new Translation profiler: This table shows the detail of the application messages, including their domain, the times each of them have been used and a preview of the translated message. New in Symfony 2.7: Default Date and Number Format Configuration. When you use the date filter to display dates in Twig templates, Symfony applies the default date formatting defined in the Twig Core extension. The same goes for numeric values formatted with the number_format filter. These default formats can be overridden using the arguments of each filter: However, if you use the same custom date or number formatting for all the values rendered in the application templates, this technique is very cumbersome. In Symfony 2.6 you can set the default formatting inside a controller as follows: Setting up the default formatting for the entire application is even more complex, because you usually need to set up a dedicated listener.

Use the date configuration option under the twig key to override any of the default date formatting options: You can also define the timezone option to use it when formatting dates: Similarly, the default formatting of numeric values can now be defined using the new number_format option under the twig key: New in Symfony 2.7: Advanced table layouts for console commands. The Symfony Console component is the second most popular Symfony component, with more than eight million downloads on Packagist.org so far. One of the main factors of its success is the amount of features that it provides to create advanced console commands. In Symfony 2.7 we went a step further and added support for defining advanced table layouts. Similarly to the well-known properties of the HTML tables, the new colspan and rowspan properties allow you to create advanced table layouts.

These properties are supported by the new TableCell class, which must be used to define non-regular table layouts. These two properties can also be combined in the same table, allowing to create any layout that you can imagine. New in Symfony 2.7: Twig as a First-Class Citizen. When I started to work on Symfony2, Twig didn't exist. Anyway, to ease using PHP as a templating engine, I created the Symfony Templating Component. Later on, not very satisfied with using PHP as a templating language, I decided to create a new templating language, Twig, based on the Python Jinja2 language.

And Symfony2 became the first popular framework to adopt a non-PHP templating engine in core. Of course, I had no idea if it would become a popular choice amongst Symfony developers, and so Symfony2 lets you use both PHP and Twig in your applications. Fast forward to 2015; it's clear that Twig won the heart of Symfony2 developers and the heart of many PHP developers; Twig is now also used by many Open-Source CMSes besides Symfony. But what would Twig as a First-Class Citizen mean in Symfony2 then? In Symfony 2.6, you cannot use Twig "directly"; you must instead use the templating sub-system via the templating service.

New in Symfony 2.7: Serialization Groups. The Symfony Serializer component is used to turn PHP objects into a specific format (XML, JSON, YAML, ...) and the other way around. In order to maintain its simplicity, we've limited the scope of the component and that's why it's one of the Symfony components with less new features since its introduction. In Symfony 2.7 we've decided to reverse this trend and we're introducing a new feature to serialize/deserialize different sets of object attributes. Consider the following object that includes properties aimed to administrators, affiliates and regular users: The definition of serialization can be specified using annotations, XML or YAML. In case of using annotations, define serialization groups as follows: Now that serialization groups have been defined, you can serialize only the attributes that belong to the given groups: Similarly, you can define the groups to user when deserializing contents:

New in Symfony 2.7: Inherited security roles in the web profiler. Symfony 2.6 was released less than a month ago, but we are already working hard on new features for Symfony 2.7. The first significant new feature is related to hierarchical security roles. In Symfony applications, you can define a hierarchy of security roles to avoid associating many roles to users. Consider the following simple example: This configuration tells Symfony that whenever a user is granted with the ROLE_ADMIN role, he/she is implicitly granted the ROLE_USER, FEATURE_ALPHA and ROLE_ALLOWED_TO_SWITCH roles too. However, when you browse the Security panel of the Symfony Profiler, you can only see the user's roles but not the inherited roles. Since this last information is very useful, in Symfony 2.7 you'll get the full security role information for the user, including the direct roles and the inherited ones: