This article is the last one in the New in Symfony 2.8 series. It explains five minor but useful improvements introduced in several Symfony components.
Added a non-static API for the CssSelector component
In Symfony 2.7, the CssSelector component exposed a static API to convert the CSS selectors into XPath expressions. In Symfony 2.8, we added a new non-static API:
1 2 3 4 5 6 7 8 9 10
// Before
use Symfony\Component\CssSelector\CssSelector;
$expression = CssSelector::toXPath('div.item > h4 > a');
// After
use Symfony\Component\CssSelector\CssSelectorConverter;
$converter = new CssSelectorConverter();
$expression = $converter->toXPath('div.item > h4 > a');
This new API allows to keep a reference to the Converter object and all its internal object graph, which in some situations may be faster than recreating everything whenever you perform a conversion.
Besides, HTML is now selected as the default format. If you are working with XML
contents, pass false
as the argument of the CssSelectorConverter
class:
1 2 3 4 5
// Before
use Symfony\Component\CssSelector\CssSelectorConverter;
$converter = new CssSelectorConverter(false);
$expression = $converter->toXPath('items > item > title');
This component is mostly used by Symfony developers through the DomCrawler component in their tests. In that case, this change doesn't affect you in any way and you don't have to make any additional change.
Added domain exceptions to the Console component
The Console component used generic PHP exceptions such as InvalidArgumentException
and LogicException
. In Symfony 2.8, to make the component consistent with
other parts of the framework, custom exceptions are used.
These "domain exceptions" allow to generate better error messages. For example, when some command wasn't found, in some places we just threw this exception:
1
throw new \InvalidArgumentException($message);
Now, we throw this other custom exception which allows to define a series of alternative commands with similar names to the one not found:
1
throw new CommandNotFoundException($message, $alternatives);
These are the first custom exceptions defined for the Console component:
CommandNotFoundException
ExceptionInterface
InvalidArgumentException
InvalidOptionException
LogicException
RuntimeException
Added a new ClassCache
cache warmer
In order to improve performance and reduce I/O load, Symfony generates a big
classes.php
file in the cache with the contents of the most accessed classes.
Bundles, including yours, can add new classes to this file through the
addClassesToCompile()
method.
In Symfony 2.8, we added a new cache warmer that generates this classes.php
file. This new warmer removes the known slowness of the first hit to a Symfony
application (even when cache has been warmed up). Besides, this feature also
allows to make a Symfony application runnable on a read-only filesystem (such as
in a Docker container for example).
Allowed to warm up Twig templates in non-standard paths
As you may know, Symfony applications can define custom Twig namespaces. Suppose
that you're using some third-party library that includes Twig templates that
live in vendor/acme/foo-bar/templates
. You can refer to those templates as
@foo_bar/<template-name>
if you define the following configuration:
1 2 3 4 5
# app/config/config.yml
twig:
# ...
paths:
"%kernel.root_dir%/../vendor/acme/foo-bar/templates": foo_bar
In Symfony 2.8, the templates defined under those custom namespaces will be automatically compiled during cache warm up. This will result in a (minor) performance improvement.
Allowed to configure a user checker per firewall
During the authentication of a user, additional checks might be required to
verify if the identified user is allowed to log in. Symfony performs these
checks with classes that implement the
Symfony
. This interface defines
two methods called checkPreAuth()
and checkPostAuth()
to perform checks
before and after user authentication.
In Symfony 2.8, these user checkers became more useful because you can use a
custom user checker per firewall thanks to the new user_checker
option:
1 2 3 4 5 6 7 8 9 10 11 12
services:
app.admin_user_checker:
class: App\Security\AdminUserChecker
arguments:
- "@request_stack"
security:
firewalls:
secured_area:
pattern: ^/admin
# ...
user_checker: app.admin_user_checker
Allowed to retrieve the priority of an event listener
One of the most common feature requests for the EventDispatcher component was
to add a method to retrieve the priority of the given event listener. In
Symfony 2.8 we finally included this method, called getListenerPriority()
to the different EventDispatcher
implementations.
This will help you figure out which priority is needed to override another event listener without digging in the sources. The first argument of the new method is the event name and the second argument is the listener:
1 2 3 4 5 6
$eventDispatcher->addListener('post.published', $listener, -10);
$priority = $eventDispatcher->getListenerPriority('post.published', $listener);
// $priority = -10
$priority = $eventDispatcher->getListenerPriority('wrong_event', $listener);
// $priority = null
Thank you for nice overview. Good job guys!