Symfony Release Notes

Nicolas Grekas

Contributed by Nicolas Grekas in #66122 , #66129 , #66131 and #66133

Symfony 8.2 includes lots of performance improvements, but we keep looking for new opportunities to make your applications faster.

For example, Symfony creates the event dispatcher at runtime for every request by calling addListener() for each listener and wrapping it in a closure, even for events that the request never dispatches. But Symfony already knows your application's event listeners when it compiles the container, so this work can be done ahead of time.

Compiled Event Dispatcher

In Symfony 8.2, the event_dispatcher service is a CompiledEventDispatcher. It receives an array of listener service IDs and methods, in the order they run, and a service locator to load them when needed. PHP's OPcache stores the array in shared memory, so each request doesn't need its own copy. …

Nicolas Grekas

Contributed by Nicolas Grekas in #66012 , #66022 and #66240

If you've ever needed to run an event listener before one provided by Symfony or a third-party bundle, you had to find its priority, pick a slightly higher number and hope that priority doesn't change in a future update.

In Symfony 8.2, you can solve this in a better way: the new before and after options let you name the event listeners or tagged services that yours should run before or after.

Ordering Event Listeners

Suppose your listener sets the _locale request attribute. It needs to run before Symfony's LocaleListener reads that attribute to set the request's locale. You can now declare that directly on your listener:

// src/EventListener/RequestLocaleListener.php
namespace App\EventListener;

use Symfony\Component\EventDispatcher\Attribute\AsEventListener; …

An HTTP response can pass through several caches before it reaches the user, and you may want different rules for each one. Symfony 8.2 adds support for two HTTP headers: one to set those rules, and another to see what happened to a request.

Targeted Cache-Control Headers

Nicolas Grekas

Contributed by Nicolas Grekas in #65282

You might want your CDN to cache a page for an hour, while keeping a much shorter cache lifetime in the browser. That's because you can purge the CDN cache when the content changes, but you can't purge the copies stored in your visitors' browsers. Targeted cache-control headers, defined in RFC 9213, let you give each cache its own rules.

For example, a CDN that supports CDN-Cache-Control uses it instead of Cache-Control. Browsers continue to use Cache-Control. In Symfony 8.2, call the new cacheControl() method on a Response with the target name (CDN, not CDN-Cache-Control):

// browsers consider the response stale immediately...
$response->setMaxAge(0)->setPrivate();

// ...but the CDN can cache it for one hour
$response->cacheControl('CDN')
    ->setMaxAge(3600) …

At Symfony, we're obsessed with performance, and Symfony 8.2 has plenty of examples. Over the last few weeks, Nicolas Grekas profiled the Symfony Demo application and a custom API project, turning every finding into a pull request.

The result is faster web pages, APIs, console commands and cache builds, in production and development.

Faster APIs

APIs that serialize and deserialize lots of objects see some of the biggest gains. When normalizing objects, the Serializer computes each attribute's context once, avoids copying the normalized array for each attribute and fetches the discriminator mapping once per object instead of once per attribute. On an API application that returns lists of 150 to 900 objects with serialization groups and a name converter, list routes are 14% to 24% faster (PR #66383).

Reading a property with PropertyAccess now takes 40% fewer PHP instructions, so those list routes run another 6% to 8% fewer instructions (PR #66397). The snake_case name converter also memoizes its results instead of running a regular expression for every attribute of every object, which makes list routes 2% to 5% faster (PR #66384). …

Serialization groups let you choose which properties to include when serializing an object. You might use one group for public API responses and another for admin exports. Symfony 8.2 adds new ways to configure these groups, and lets controllers and Messenger use named serializers.

Serialized Names and Paths per Group

Sergey Danilchenko

Contributed by Sergey Danilchenko in #58236

Until now, the #[SerializedName] and #[SerializedPath] attributes defined a single name or path for a property, regardless of the serialization group. Using different keys for the same property required a workaround, such as creating separate DTOs.

In Symfony 8.2, both attributes are repeatable and accept a groups argument. For example, if version 2 of your API renames a field, version 1 can keep the old name:

use Symfony\Component\Serializer\Attribute\Groups;
use Symfony\Component\Serializer\Attribute\SerializedName;

class Product
{
    #[Groups(['api_v1', 'api_v2'])]
    #[SerializedName('product_name', groups: 'api_v1')]
    public string $name;
}

$serializer->serialize($product, 'json', ['groups' => ['api_v1']]); …

In Symfony, IS_AUTHENTICATED_FULLY is the strongest check about how users logged in. However, it tells you how the session started, not when. A user who logged in with their password eight hours ago and left the laptop unlocked is still fully authenticated, so anyone can make a payment or delete their account. Services like GitHub solve this with a sudo mode which asks for your credentials again before sensitive actions. Symfony 8.2 adds this feature natively.

Requiring Recent Authentication

Nicolas Grekas

Contributed by Nicolas Grekas in #66014 and #66066

Symfony 8.2 adds two security attributes that go beyond IS_AUTHENTICATED_FULLY:

• IS_AUTHENTICATED_RECENTLY: the user entered their credentials within the last two hours;
• IS_AUTHENTICATED_VERY_RECENTLY: the user entered their credentials within the last five minutes.

For example, you could require a recent login to change an email address, and a very recent one to delete an account:

// src/Controller/AccountController.php …