New in Symfony 4.4: Misc. improvements (Part 2)

Exclude resources from routing config

Contributed by
Tristan Bessoussa
in #31587.

When configuring services in Symfony, you can exclude patterns of files/directories that shouldn't be turned into services. In Symfony 4.4, we added a similar feature so you can exclude patterns from the routing configuration:

1
2
3
4
5
6
# config/routes/annotations.yaml
controllers:
    resource: ../../src/Controller/*
    type: annotation
    # annotations won't be loaded for the following patterns
    exclude: '../src/Controller/{DebugEmailController}.php'

Normalize whitespace of HTML elements

Contributed by
Kévin Dunglas
in #34151.

In functional tests, it's common to get the value of HTML nodes and compare it with some expected value. When doing this, Symfony returns the exact original content of the node, including all whitespace and new lines. That's why you probably call to trim() before comparing values:

1
2
3
4
$this->assertSame(
    'Hello World',
    trim($crawler->filter('section#content h1.title')->text())
);

Given that the DOM and WebDriver specifications tell browsers to always return the normalized contents without whitespace, we've decided to do the same starting from Symfony 5.0.

Meanwhile, in Symfony 4.4 we've added an optional second argument to the text() method. If true, contents are normalized. Its default value is false to keep backward compatibility, but you'll see a deprecation message if you don't set this argument explicitly and the content includes whitespaces:

1
2
3
4
$this->assertSame(
    'Hello World',
    $crawler->filter('section#content h1.title')->text(null, true)
);

Support scientific number format

Contributed by
Ivan
in #34028.

The ExpressionLanguage component provides a rich syntax to create all kinds of expressions used for services, security, routing or to define your own business rules. In Symfony 4.4 we improved the syntax with the support of exponential or scientific notation for numbers (e.g. 1.99E+3 or 1e-2).

Deprecate multiple permissions in isGranted()

Contributed by
Wouter De Jong
in #33584.

The isGranted() method provided by the AuthorizationChecker allows to check if the current user has the given permission. Although not commonly used, this method also allowed to pass more than one permission. For example, inside a controller extending from Symfony's AbstractController:

1
2
3
if ($this->isGranted(['ROLE_USER', 'ROLE_ADMIN'])) {
    // ...
}

Which roles are required for the user? Both or just on of them? The answer is ... just any of them. However, this is confusing and that's why we've deprecated it in Symfony 4.4. Starting from Symfony 5.0, you can only pass one permission to isGranted(). If you need to check multiple permissions, use any of these alternatives:

1
2
3
4
5
if ($this->isGranted('ROLE_USER') || $this->isGranted('ROLE_ADMIN'))) { ... }
if ($this->isGranted('ROLE_USER') && $this->isGranted('ROLE_ADMIN'))) { ... }

if ($this->isGranted(new Expression("is_granted('ROLE_USER') or is_granted('ROLE_ADMIN')"))) { ... }
if ($this->isGranted(new Expression("is_granted('ROLE_USER') and is_granted('ROLE_ADMIN')"))) { ... }

Improved the lint:twig command

Contributed by
Yonel Ceruto
in #33446 and #33961.

The lint:twig command is one of the linter commands provided by Symfony to check that your application is ready for production. In Symfony 4.4 we've improved it with new options:

1
2
# if you don't pass any arguments, Symfony lints all the application templates
$ php bin/console lint:twig

Pass the --show-deprecations option to output all the deprecated features used by templates:

1
2
3
4
5
6
7
 $ php bin/console lint:twig --show-deprecations

   ERROR  in symfony-demo/templates/base.html.twig (line 22)
       20 |        <body id="{% block body_id %}{% endblock %}">
       21 |
     * 22 |           {% block header %}{% spaceless %}
     The "spaceless" tag at line 22 is deprecated since Twig 2.7, use the spaceless filter instead.

New in Symfony 4.4: Misc. improvements (Part 2) symfony.com/blog/new-in-symfony-4-4-misc-improvements-part-2

Tweet this

Comments

`isGrantedAny` and `isGrantedAll` would be good alternatives to make it clear.
I would also either recommend the idea of Thomas Schulz or recommend to add a third parameter that will receive an integer predefined by two constants like SYMFONY_GRANTED_ALL = 0 or SYMFONY_GRANTED_ANY = 1. Defaulting to SYMFONY_GRANTED_ANY as this is the current behaviour.
I'd stick with isGrantedAny and isGrantedAll if this were to be implemented as proposed, as it's explicit and quite clear what the intent is.
Having another optional parameter will still lead to unintended errors.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.