Symfony 6.1 has just been released. During the past weeks we've published lots of articles about the most important Symfony 6.1 features. In this article, the last one in the Symfony 6.1 series, we showcase some minor but interesting features introduced by Symfony 6.1.

Configure the Deprecation Messages to Ignore

Mondrake
Contributed by Mondrake in #45226

If your application has some deprecations that you can't fix yet for some reasons, you can tell Symfony to ignore them. First, create a text file where each line is a deprecation to ignore defined as a regular expression:

1
2
# tests/baseline-ignore.txt
%The "PHPUnit\\Framework\\TestCase::addWarning\(\)" method is considered internal%

Then, you can run the following command to use that file and ignore those deprecations:

1
$ SYMFONY_DEPRECATIONS_HELPER='ignoreFile=./tests/baseline-ignore.txt' ./vendor/bin/simple-phpunit

Allow to Exclude Services from Tagged Iterators and Locators

Ruud Kamphuis
Contributed by Ruud Kamphuis in #44774

When working with the Delegation pattern or the Chain-of-responsibility pattern it's common that the service that gets a list of services implementing a certain interface, to also implement that interface itself.

For example, in Symfony, the ChainCacheClearer class implements CacheClearerInterface and calls a list of services implementing CacheClearerInterface. In those cases you cannot use autowiring because the main service would receive it itself in the list of services implementing the interface.

In Symfony 6.1 we've improved TaggedIterator and TaggedLocator to allow you exclude some services via the new exclude option:

1
2
3
4
5
6
7
8
9
10
11
12
final class DelegatingErrorTracker implements ErrorTracker
{
    public function __construct(
        #[TaggedIterator(ErrorTracker::class, exclude: self::class)]
        private iterable $trackers
    ) {}

    public function trackError(string $error): void
    {
        // ...
    }
}

Use Route Parameters in Route Conditions

HypeMC
Contributed by HypeMC in #46042

Symfony provides a powerful feature to define route conditions as expressions. In Symfony 6.1 we've improved it so you can use the matched route parameters in the expression that is evaluated to decide if the route matches or not.

Use the new params variable and pass the name of the route parameter that you want to get:

1
2
3
4
5
6
7
8
class FooController
{
    #[Route('/foo/{id}', requirements: ['id' => '\d+'], condition: "params['id'] < 100")]
    public function index(int $id): Response
    {
        // ...
    }
}

Support Canners in Object Normalizer

Rokas Mikalkėnas
Contributed by Rokas Mikalkėnas in #45282

Currently, the Serializer component can normalize properties with methods that start with get, set, has, is, add or remove (e.g. getUser(), isPublished(), addCategory(), etc.)

In Symfony 6.1, the Serializer will also be able to normalize "canner methods", which are those that start with the can prefix (e.g. canPublish(), canApprove(), etc.)

Detailed Checks for Collection Items Uniqueness

Wojciech Kania
Contributed by Wojciech Kania in #42403

When combining the Unique constraint with the Collection constraint, all the properties of the collection elements are checked to be unique. In Symfony 6.1 we've improved the Unique constraint to allow defining which collection fields should be checked for uniqueness.

The following example validates that each translation of the same resource must be in a different language:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
use Symfony\Component\Validator\Constraints as Assert;

#[Assert\Count(min: 1)]
#[Assert\Unique(fields: ['language'])]
#[Assert\Collection(fields: [
    'language' => [
        new Assert\NotBlank,
        new Assert\Length(min: 2, max: 2),
        new Assert\Language,
    ],
    'title' => [
        new Assert\NotBlank,
        new Assert\Length(max; 255),
    ],
    'description' => [
        new Assert\NotBlank,
        new Assert\Length(max: 255),
    ],
])]
public array $translations = [];

A Command to Invalidate Cache Tags

Kevin Bond
Contributed by Kevin Bond in #44692

Using cache tags is a way to group different cache items based on arbitrary criteria so you can later invalidate those items more efficiently. In Symfony 6.1 we've added a new cache:pool:invalidate-tags command so you can invalidate those cache tags directly in the command line:

1
2
3
4
5
# invalidate `tag1` and `tag2` from all pools
$ php bin/console cache:pool:invalidate-tags tag1 tag2

# invalidate `tag1` and `tag2` only from a specific pool
$ php bin/console cache:pool:invalidate-tags tag1 tag2 --pool=cache.app
Published in #Living on the edge