Message signing in Messenger

Transport security in Messenger has always been the application’s problem to solve. 7.4 adds message signing: a stamp-based mechanism that signs dispatched messages and validates signatures on reception.

The target use case is multi-tenant or external transport scenarios where you need cryptographic proof that a message wasn’t tampered with or injected from outside. Configuration lives at the transport level:

framework:
    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    signing_key: '%env(MESSENGER_SIGNING_KEY)%'

PHP array configuration

Symfony’s configuration formats have always been YAML (default), XML, and PHP. The PHP format existed but it was awkward: a fluent builder DSL that required method chaining and gave your IDE nothing useful to work with.

7.4 swaps the fluent format for standard PHP arrays. IDEs can now actually analyze it, config/reference.php is auto-generated as a type-annotated reference, and the result reads like data rather than code:

return static function (FrameworkConfig $framework): void {
    $framework->router()->strictRequirements(null);
    $framework->session()->enabled(true);
};

The fluent format is deprecated. Arrays are the future, and honestly it’s a better format.

OIDC improvements

#[IsSignatureValid] validates signed URLs directly in controllers, cutting out the boilerplate of manual validation. OpenID Connect now supports multiple discovery endpoints, and a new security:oidc-token:generate command makes dev and testing a lot less painful.

The support window

7.4 LTS: bugs until November 2028, security fixes until November 2029. The path to 8.4 LTS (the next long-term target) goes through 7.4’s deprecation notices and the PHP 8.4 upgrade. Fix the deprecations now and the jump to 8.x will be much less painful.

Attributes get more precise

#[CurrentUser] now accepts union types, which matters in practice when a route can be reached by more than one user class:

public function index(#[CurrentUser] AdminUser|Customer $user): Response

#[Route] accepts an array for the env option, so a debug route active only in dev and test no longer needs two separate definitions. #[AsDecorator] is now repeatable, meaning one class can decorate multiple services at once. #[AsEventListener] method signatures accept union event types. #[IsGranted] gets a methods option to scope an authorization check to specific HTTP verbs without duplicating the route.

Request class stops doing too much

Request::get() is deprecated, and honestly good riddance. The method searched route attributes, then query parameters, then request body, in that order, silently returning whatever it found first. That ambiguity caused real bugs. It’s gone in 8.0; in 7.4 it still works but triggers a deprecation. The replacements are explicit: $request->attributes->get(), $request->query->get(), $request->request->get().

Body parsing for PUT, PATCH, DELETE, and QUERY requests arrives at the same time. Previously Symfony only parsed application/x-www-form-urlencoded and multipart/form-data for POST. Those same content types now get parsed for the other writable methods too, which kills a common REST API workaround.

HTTP method override for GET, HEAD, CONNECT, and TRACE is deprecated. Overriding a safe method with a header was always semantically broken anyway. You can now explicitly allow only the methods that make sense for your app:

Request::setAllowedHttpMethodOverride(['PUT', 'PATCH', 'DELETE']);

Workflows accept BackedEnums

Workflow places and transitions can now be defined with PHP backed enums, both in YAML (via the !php/enum tag) and in PHP config. The marking store works with enum values directly, so your domain model and your workflow definition finally use the same types:

framework:
    workflows:
        blog_publishing:
            initial_marking: !php/enum App\Status\PostStatus::Draft
            places: !php/enum App\Status\PostStatus
            transitions:
                publish:
                    from: !php/enum App\Status\PostStatus::Review
                    to: !php/enum App\Status\PostStatus::Published

Extending validation and serialization for third-party classes

Ever needed to add validation or serialization metadata to a class from a bundle you don’t own? 7.4 has #[ExtendsValidationFor] and #[ExtendsSerializationFor] for that. You write a companion class with your extra annotations, point the attribute at the target class, and Symfony merges the metadata at container compilation time:

#[ExtendsValidationFor(UserRegistration::class)]
abstract class UserRegistrationValidation
{
    #[Assert\NotBlank(groups: ['my_app'])]
    #[Assert\Length(min: 3, groups: ['my_app'])]
    public string $name = '';

    #[Assert\Email(groups: ['my_app'])]
    public string $email = '';
}

Symfony verifies at compile time that the declared properties actually exist on the target class. A rename won’t silently break your validation.

DX: the things that don’t headline but matter

The Question helper in Console accepts a timeout. Ask the user to confirm something, and if they don’t respond in N seconds, the default answer kicks in. Very handy in deployment scripts that can’t afford to wait forever for a human.

messenger:consume gets --exclude-receivers. Combined with --all, it lets you consume from every transport except specific ones:

bin/console messenger:consume --all --exclude-receivers=low_priority

FrankenPHP worker mode is now auto-detected. If the process is running inside FrankenPHP, Symfony switches to worker mode automatically. No extra package needed.

The debug:router command hides the Scheme and Host columns when all routes use ANY, which removes a lot of noise from the default output. HTTP methods are now color-coded too.

Functional tests get $client->getSession() before the first request. Previously you had to make at least one request to access the session, which was annoying. Now you can pre-seed CSRF tokens or A/B testing flags up front:

$session = $client->getSession();
$session->set('_csrf/checkout', 'test-token');
$session->save();

Lock: DynamoDB store

DynamoDbStore lands as a new Lock backend. Useful in AWS-native deployments where Redis isn’t in the stack, and it works exactly like any other store:

$store = new DynamoDbStore('dynamodb://default/locks');
$factory = new LockFactory($store);

Doctrine bridge: day and time point types

Two new Doctrine column types: day_point stores a date-only value (no time component) and time_point stores a time-only value, both mapping to DatePoint. Good when your domain genuinely separates date from time:

#[ORM\Column(type: 'day_point')]
public DatePoint $birthDate;

#[ORM\Column(type: 'time_point')]
public DatePoint $openingTime;

Routing: explicit query parameters

The _query key in URL generation lets you set query parameters explicitly, separate from route parameters. This matters when a route parameter and a query parameter share the same name:

$url = $urlGenerator->generate('report', [
    'site' => 'fr',
    '_query' => ['site' => 'us'],
]);
// /report/fr?site=us

WebLink: parsing incoming Link headers

HttpHeaderParser parses Link response headers into structured objects. Before this, parsing Link headers from API responses meant either pulling in a third-party library or writing regex. The use case is HTTP APIs that advertise related resources or pagination via Link headers, like GitHub’s API does.

HTML5 parsing gets faster on PHP 8.4

DomCrawler and HtmlSanitizer switch to PHP 8.4’s native HTML5 parser when available. No code changes needed on your end. The native parser is faster and more spec-compliant than the previous fallback. On PHP 8.2 or 8.3 nothing changes.

Translation: StaticMessage

StaticMessage implements TranslatableInterface but intentionally doesn’t translate. It passes the string through unchanged regardless of locale. The use case is API responses that must stay in a fixed language regardless of the user’s locale, or audit log entries where you need to preserve the original text as-is.

It ships with the framework. It has retry logic, native AMQP support, first-party documentation. Our setup looked artisanal by comparison.

Fair question. We took it seriously. Here’s what we found.

Wiring the topology by hand

Swarrot is a consumer library that wraps the PECL AMQP extension. It reads bytes from a queue, runs them through a chain of processors (their term for middleware), and lets your code decide what to do with the payload. That’s really it.

The middleware chain is the interesting part. Processors are nested decorators, each wrapping the next. The outer layers handle infrastructure concerns before the message even reaches your business logic:

middleware_stack:
    - configurator: 'swarrot.processor.signal_handler'
    - configurator: 'swarrot.processor.max_execution_time'
    - configurator: 'swarrot.processor.exception_catcher'
    - configurator: 'swarrot.processor.doctrine_object_manager'
    - configurator: 'swarrot.processor.ack'
    - configurator: 'app.processor.retry'

signal_handler sits at the top because it needs to catch SIGTERM before any other processor sees it. ack sits near the bottom because you only acknowledge the message after processing succeeds. The order is not arbitrary, and it’s entirely visible in configuration.

The topology is equally explicit. You declare everything yourself: exchanges, routing keys, retry queues, dead-letter queues:

messages_types:
    content.ingest:
        exchange: e.app.content
        routing_key: q.app.content.ingest
    content.ingest_retry:
        exchange: e.app.content
        routing_key: q.app.content.ingest.retry
    content.ingest_dead:
        exchange: e.app.content
        routing_key: q.app.content.ingest.dead

Three entries per logical message type: main queue, retry queue, dead-letter queue. Everything that exists on the broker is named right here. The config is verbose but honest: no inference, no convention over configuration. If a queue exists in RabbitMQ, you can trace it to a single line of YAML.

When the class name becomes the route

Symfony Messenger operates one level higher. You define a message class, a handler, and a transport. The library handles serialization, routing, retry, and failure queues automatically.

class IngestContent
{
    public function __construct(
        public readonly string $contentId,
        public readonly string $source,
    ) {}
}

framework:
    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                retry_strategy:
                    max_retries: 3
                    delay: 1000
        routing:
            'App\Message\IngestContent': async

Messenger serializes the object, puts it on the transport, and deserializes it on the other end into the correct class. No manual topology, no explicit exchange names. The class name is the routing primitive.

That last sentence is exactly where things got complicated for us.

Where typing becomes coupling

Messenger assumes that the producer and the consumer share a PHP class definition. That’s fine for a single app, or for services that share a dedicated contracts package. In a monorepo of independent Symfony applications, it creates coupling that simply doesn’t exist today.

Take a content ingestion message that twelve services consume. With Swarrot, each service reads the raw JSON payload and picks the fields it cares about. Adding a new field means updating the producer. Consumers that don’t need the field keep working without any modification.

With Messenger, IngestContent must be defined somewhere that all twelve services can reference. That means either:

• A shared PHP package, versioned, deployed, and maintained across services. Every schema change becomes a cross-service coordination exercise.
• Duplicated classes in each service, which drift silently apart under pressure.

Neither is free. The shared package approach inverts the ownership model: the message schema becomes a dependency rather than a contract defined at the boundary. The duplication approach is just the original problem deferred.

The root difference is what a message represents. Messenger is designed for typed commands: an object that carries meaning and dispatches to a specific handler. Swarrot treats messages as opaque data: bytes that flow through a topology, processed by whatever consumer happens to be listening. If your messages are data, the extra abstraction Messenger adds doesn’t help you. It creates friction.

The blocker

The serialization problem was the decisive one. In a monorepo where services are autonomous, sharing PHP classes between them isn’t architecturally neutral: it’s a coupling decision that makes future changes harder. We would have been trading a nominally “legacy” library for a more modern one while introducing exactly the kind of tight coupling we’d spent years avoiding.

There were secondary concerns too. The PECL AMQP extension gives direct access to broker features (message priorities, per-queue TTL, headers exchange routing) that Messenger abstracts away. And migrating fifteen consumers without a flag day means running both libraries in parallel, which is a real operational constraint.

But the serialization issue alone would have been enough.

Data or commands: that’s the question

The choice isn’t about library quality. Messenger is well-maintained, well-documented, and integrates cleanly into the Symfony ecosystem.

The question to ask first is: what are your messages?

If they are typed commands with a known schema and a single authoritative consumer, Messenger is a natural fit. You write a class, a handler, configure a transport, and the infrastructure handles the rest.

If they are data payloads consumed by multiple independent services, each of which owns its own deserialization, the abstraction Messenger adds works against you. Swarrot’s explicit topology and raw payload model give you more control where you actually need it.

One real limitation to keep in mind: Swarrot is tied to the PECL AMQP extension, which only implements AMQP 0-9-1. That means RabbitMQ (or a compatible broker) is a hard dependency. If your infrastructure ever moves toward an AMQP 1.0 broker (Azure Service Bus, ActiveMQ Artemis), Swarrot can’t follow. Messenger’s transport layer abstracts this cleanly: changing brokers means changing a DSN, not rewriting consumers.

If broker portability is a requirement, or likely to become one, that changes the calculus significantly.

Swarrot isn’t legacy to migrate away from. For now, it’s the right fit: AMQP routing as the primitive, messages as data, RabbitMQ as a long-term infrastructure choice.

That could change. A shared contracts package, a new broker requirement, a greenfield service that doesn’t carry the existing topology weight: any of these could tip the balance toward Messenger. The library isn’t wrong for this platform. It may just be the right answer for a future version of it.

5.4 is the LTS, and its job is to carry as much of 6.0’s feature set as possible while keeping 5.x compatibility intact. It’s also the first Symfony release that actually understands PHP 8.1 features.

Enum support

PHP 8.1 introduced native enums. Symfony 5.4 embraces them immediately:

enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
}

The EnumType form type renders enums as select fields, no custom transformers needed. The validator understands backed enums. The serializer maps enum values to their backing type and back. Three components updated in one shot, which meant migrating codebases from pseudo-enum constants to real PHP 8.1 enums was actually pretty smooth.

Security voter cache

The CacheableVoterInterface lets voters that always abstain on a given attribute signal that to the security system, which can then skip them on subsequent checks. For apps with many voters, the gain on permission checks adds up fast. Small change, noticeable in practice.

Messenger matures further

Messenger batch processing (handling multiple messages in a single transaction instead of one by one) is now stable. Rate limiting per transport. Dead letter queues get better tooling. After years as “experimental”, Messenger in 5.4 is finally the async foundation you can bet on for serious workloads.

Console grew a tab key

Symfony 5.4 ships shell autocompletion for all commands. Press Tab and the shell suggests command names, argument values, and option values. For built-in commands this works out of the box. For custom commands, add a complete() method:

use Symfony\Component\Console\Completion\CompletionInput;
use Symfony\Component\Console\Completion\CompletionSuggestions;

public function complete(CompletionInput $input, CompletionSuggestions $suggestions): void
{
    if ($input->mustSuggestOptionValuesFor('format')) {
        $suggestions->suggestValues(['json', 'xml', 'csv']);
    }
}

No interface required, just the method and Symfony picks it up. The community also went through all built-in commands (debug:router, cache:pool:clear, secrets:remove, lint:twig, and a dozen more) to add completions before the release.

Routes can be aliases now

The routing component now supports aliasing: one route can point to another. The obvious use case is renaming a route without breaking anything that still generates URLs with the old name.

# config/routes.yaml
admin_dashboard:
    path: /admin

# legacy name kept during transition
dashboard:
    alias: admin_dashboard
    deprecated:
        package: 'acme/my-bundle'
        version: '2.3'

Generating a URL with dashboard still works, but fires a deprecation notice. Clean rename paths for bundles that need to maintain public route names while moving on.

Exceptions map to HTTP status codes in config

Before 5.4, mapping an exception class to an HTTP status code meant implementing HttpExceptionInterface or writing a listener. Now it’s just a YAML entry:

# config/packages/framework.yaml
framework:
    exceptions:
        App\Exception\PaymentRequiredException:
            status_code: 402
            log_level: warning
        App\Exception\MaintenanceException:
            status_code: 503
            log_level: info

The exception doesn’t need to implement anything. The framework reads the map, sets the status code, logs at the configured level. Handy for domain exceptions that have no business knowing about HTTP.

Two new validator constraints

5.4 adds Cidr and CssColor to the Validator component.

Cidr validates network notation — IP address plus subnet mask — with control over which IP version to accept and bounds on the mask value:

#[Assert\Cidr(version: 4, netmaskMin: 16, netmaskMax: 28)]
private string $allowedSubnet;

CssColor validates that a string is a valid CSS color. Useful for theme editors, CMS config, or any UI that lets users pick colors:

#[Assert\CssColor(
    formats: Assert\CssColor::HEX_LONG,
    message: 'The accent color must be a 6-digit hex value.',
)]
private string $accentColor;

Nested PHP attributes for validation constraints

Symfony 5.2 added validator constraints as PHP attributes, but PHP 8.0 had a hard limit on nested attributes. Complex constraints like All, Collection, or AtLeastOneOf were impossible to express in attribute syntax alone. PHP 8.1 lifted that restriction, and 5.4 makes the most of it:

use Symfony\Component\Validator\Constraints as Assert;

class CartItem
{
    #[Assert\All([
        new Assert\NotNull(),
        new Assert\Range(min: 1),
    ])]
    private array $quantities;

    #[Assert\AtLeastOneOf(
        constraints: [new Assert\Email(), new Assert\Url()],
        message: 'Must be a valid email or URL.',
    )]
    private string $contact;
}

No annotation doc-blocks, no XML mapping. Pure PHP 8.1 attributes all the way down.

Dependency injection: three things worth knowing

Tagged iterators can now be injected into service locators, which previously only accepted explicit service lists. Union type autowiring works when both sides of the union resolve to the same service, which is common with serializer interfaces:

public function __construct(
    private NormalizerInterface & DenormalizerInterface $serializer
) {}

#[SubscribedService] replaces the automatic introspection that ServiceSubscriberTrait did implicitly. It’s now an explicit attribute on methods, which makes the dependency visible without any magic:

use Symfony\Contracts\Service\Attribute\SubscribedService;

class SomeService implements ServiceSubscriberInterface
{
    #[SubscribedService]
    private function router(): RouterInterface
    {
        return $this->container->get(__METHOD__);
    }
}

Messenger: attributes, worker state, and service reset

Messenger handlers can drop the MessageHandlerInterface in favor of #[AsMessageHandler], which also lets you bind a handler to a specific transport and set its priority, all without touching YAML:

#[AsMessageHandler(fromTransport: 'async', priority: 10)]
class ProcessOrderHandler
{
    public function __invoke(ProcessOrder $message): void { /* ... */ }
}

Worker state is now inspectable via WorkerMetadata inside event listeners, useful when you have workers on multiple transports and need to know which one fired a given event.

Long-running workers accumulate state across messages: entity manager buffers, in-memory caches, open connections. The new reset_on_message option takes care of resetting all resettable services between messages:

framework:
    messenger:
        reset_on_message: true

Serializer: collect errors instead of throwing

Deserializing external JSON into a typed DTO used to throw on the very first type mismatch. The COLLECT_DENORMALIZATION_ERRORS option changes that: all type errors get collected into a PartialDenormalizationException, so you can return a proper 400 with a full list of field-level problems:

try {
    $dto = $serializer->deserialize($request->getContent(), OrderDto::class, 'json', [
        DenormalizerInterface::COLLECT_DENORMALIZATION_ERRORS => true,
    ]);
} catch (PartialDenormalizationException $e) {
    return $this->json(
        array_map(fn($err) => ['path' => $err->getPath(), 'expected' => $err->getExpectedTypes()], $e->getErrors()),
        400
    );
}

The serializer’s default context can also be set globally in YAML, so you stop passing the same options on every call.

Language negotiation out of the box

Two new framework options handle the Accept-Language header without custom listeners:

framework:
    enabled_locales: ['en', 'fr', 'de']
    set_locale_from_accept_language: true
    set_content_language_from_locale: true

With this in place, Symfony reads the browser’s preferred language, picks the best match from enabled_locales, sets the request locale, and adds a Content-Language header to the response. The {_locale} route attribute still takes precedence when present.

Translation: extraction, not update

The translation:update command is renamed to translation:extract. The old name sticks around as deprecated. The distinction matters: the command never writes to a database, it extracts translatable strings from source files. The new name finally says what it does.

lint:xliff also gains a --format=github option that outputs errors as GitHub Actions annotations, so translation lint failures show up as PR review comments instead of getting buried in log output.

Controller shortcuts pruned

Three AbstractController shortcuts are deprecated: getDoctrine(), dispatchMessage(), and the generic get() method for pulling arbitrary services from the container. The direction is explicit constructor injection. For getDoctrine() specifically:

// before
$em = $this->getDoctrine()->getManager();

// after — inject it directly
public function __construct(private EntityManagerInterface $em) {}

Request::get() is also deprecated. It searched route attributes, query string, and POST body in an undocumented order, which was a great way to get surprising results. Use $request->query->get(), $request->request->get(), or $request->attributes->get() and be explicit about where the value comes from.

The Path utility class

The Filesystem component gets a Path class ported from webmozart/path-util. It handles the awkward cases that dirname() and realpath() fumble:

use Symfony\Component\Filesystem\Path;

Path::canonicalize('../config/../config/services.yaml'); // '../config/services.yaml'
Path::getDirectory('C:/');                               // 'C:/' (dirname() returns '.')
Path::getLongestCommonBasePath([
    '/var/www/project/src/Controller/FooController.php',
    '/var/www/project/src/Controller/BarController.php',
    '/var/www/project/src/Entity/User.php',
]);
// '/var/www/project/src'

Useful whenever your code deals with paths that cross OS boundaries or involve relative segments.

Smaller things that add up

debug:dotenv shows which .env files were loaded and what value each variable resolves to. The first thing you reach for when environment-specific behavior is acting up.

The String component adds trimPrefix() and trimSuffix() for removing known prefixes or suffixes without writing a substr calculation:

u('file-image-0001.png')->trimPrefix('file-');    // 'image-0001.png'
u('template.html.twig')->trimSuffix('.twig');      // 'template.html'

DomCrawler gets innerText(), which returns only the direct text of a node, excluding child elements. text() returns everything including nested text; innerText() returns just the node’s own content. Small difference, but it matters when scraping.

The RateLimiter component extends its interval support to perMonth() and perYear(), for apps that need to limit events over longer windows: newsletter sends, API quota resets, annual plan limits.

The Finder component now respects .gitignore files in all subdirectories when you call ignoreVCSIgnored(true), not just the root. Child directory rules override parent rules, exactly like git itself.

The LTS window

5.4 gets bug fixes until November 2024 and security fixes until November 2025. The migration from 5.4 to 6.4 (the next LTS) is intentionally smooth: fix the 5.4 deprecation warnings, and the 6.x jump is mechanical.

The deprecation layer in 5.4 points at everything 6.0 removes: the remaining pieces of the old security system, ContainerAwareTrait, and a handful of legacy form and serializer patterns.

The feature worth singling out arrived in 4.2 and matured through 4.3 and 4.4: HttpClient.

HttpClient

PHP’s built-in HTTP options (file_get_contents with stream contexts, cURL, Guzzle) each have their own model, their own quirks, and their own abstraction cost. Symfony 4.2 introduced HttpClient, a first-party HTTP client with one API over multiple transports.

The interface is clean:

$response = $client->request('GET', 'https://api.example.com/users');
$users = $response->toArray();

The implementation is async by default. Responses are lazy: the network request doesn’t happen until you actually read the response. Multiple requests can be initiated and resolved as data arrives, no threads or callbacks needed.

The built-in mock transport (MockHttpClient) makes testing HTTP calls painless without spinning up servers or patching global functions.

Mailer

Also stabilized in 4.4: the Mailer component, replacing SwiftMailerBundle as the recommended email solution. Transport is configured via DSN:

MAILER_DSN=smtp://user:pass@smtp.example.com:587

The DSN approach means switching providers (Mailgun, Postmark, SES, local SMTP) is a config change, not a code change. Email testing uses a spooler by default in non-production environments.

Messenger matures

The Messenger component landed in 3.4 as experimental. By 4.4 it’s stable and battle-tested: async message handling with retry logic, failure transport, and adapters for AMQP, Redis, Doctrine, and in-process transports.

The pattern it enables (handle a request synchronously, dispatch work asynchronously, retry on failure) replaces a class of Gearman/RabbitMQ setups that required separate libraries and significant configuration.

The LTS window

4.4 is supported for bugs until November 2022 and security fixes until November 2023. If you’re on 4.x and want stability, this is a comfortable place to land. The deprecation warnings it introduces point directly at what 5.0 will require.

The Messenger component, from experimental to production

Messenger arrived in 4.1 as an experiment. The concept was simple: dispatch a message object to a bus, handle it immediately or route it to a transport for async processing. By 4.3 and 4.4, the experiment had become infrastructure.

The 4.3 release added a dedicated failure transport. When a message fails after all retry attempts, it goes somewhere recoverable rather than just disappearing:

framework:
    messenger:
        failure_transport: failed
        transports:
            async: '%env(MESSENGER_TRANSPORT_DSN)%'
            failed: 'doctrine://default?queue_name=failed'
        routing:
            App\Message\SendEmail: async

Messages that land in failed can be inspected and retried manually. Before this, failed messages were a log entry and a headache. After this, they’re a queue you can actually work with.

Event dispatching, finally using objects properly

Since the beginning, Symfony’s event system used string event names as the primary identifier. You’d define OrderEvents::NEW_ORDER = 'order.new_order', listen on that string, and pass the event object as a secondary parameter.

4.3 flipped this around. The event object comes first, and the event name becomes optional:

// Before
$dispatcher->dispatch(OrderEvents::NEW_ORDER, $event);

// 4.3+
$dispatcher->dispatch($event);

Omit the name and Symfony uses the class name as the identifier. Listeners and subscribers can now reference the class directly:

public static function getSubscribedEvents(): array
{
    return [
        OrderPlacedEvent::class => 'onOrderPlaced',
    ];
}

The HttpKernel events were renamed accordingly: GetResponseEvent became RequestEvent, FilterResponseEvent became ResponseEvent. The old names stayed as aliases through 4.x.

VarDumper gets a server

dump() in a controller that returns JSON means your debug output gets injected straight into the response body. For API development, that’s annoying enough to make people disable dumping entirely.

4.1 added a VarDumper server that captures dumps separately:

bin/console server:dump

Configure the dump destination in config/packages/dev/debug.yaml:

debug:
    dump_destination: "tcp://%env(VAR_DUMPER_SERVER)%"

Now dump() in your API controller sends data to the server’s console instead of polluting the response. The server shows the dump alongside its source file, the HTTP request that triggered it, and the timestamp.

VarExporter, for when var_export() fails you

var_export() has two problems: it ignores serialization semantics and its output isn’t PSR-2 compliant. The 4.2 VarExporter component fixes both.

$exported = VarExporter::export([123, ['abc', true]]);
// Returns:
// [
//     123,
//     [
//         'abc',
//         true,
//     ],
// ]

More importantly, it correctly handles objects implementing Serializable, __sleep, and __wakeup. Where var_export() silently drops serialization methods and exports raw properties, VarExporter produces code that calls the same hooks unserialize() would. The practical use case is cache warming: generating PHP files that can be loaded by OPcache without re-executing expensive computations.

Passwords that check against breach databases

The NotCompromisedPassword constraint arrived in 4.3. It checks submitted passwords against haveibeenpwned.com’s breach database without sending the actual password anywhere.

use Symfony\Component\Validator\Constraints as Assert;

class User
{
    #[Assert\NotCompromisedPassword]
    public string $plainPassword;
}

The implementation uses k-anonymity: SHA-1 hash the password, send only the first five characters to the API, get back all matching hashes, check locally. The password never leaves your server. For registration forms, adding this constraint is one line and a genuinely useful security signal.

Workflow gets context

The Workflow component existed before 4.x, but 4.3 added context propagation: the ability to pass arbitrary data through a transition and access it in listeners.

$workflow->apply($article, 'publish', [
    'user' => $user->getUsername(),
    'reason' => $request->request->get('reason'),
]);

The context arrives in TransitionEvent and gets stored alongside the marking. For audit trails, this is the difference between knowing a transition happened and knowing who triggered it and why. You can also inject context from a subscriber without touching every apply() call, which is handy for cross-cutting concerns like timestamps or current user.

The autowiring got smarter

4.2 added binding by type and name together. Before, you could bind by type (LoggerInterface) or by name ($logger), but not both at once. That caused problems when a service needs two different implementations of the same interface:

services:
    _defaults:
        bind:
            Psr\Log\LoggerInterface $orderLogger: '@monolog.logger.orders'
            Psr\Log\LoggerInterface $paymentLogger: '@monolog.logger.payments'

class OrderService
{
    public function __construct(
        private LoggerInterface $orderLogger,   // gets monolog.logger.orders
        private LoggerInterface $paymentLogger, // gets monolog.logger.payments
    ) {}
}

The match requires both type and argument name to align, so there’s no risk of accidentally injecting the wrong logger.

ErrorHandler replaces the Debug component

The Debug component, unchanged since 2013, had an awkward dependency on TwigBundle even for API-only apps. Any uncaught exception in a JSON API would render an HTML error page unless you wrote custom exception listeners.

4.4 extracts this into a dedicated ErrorHandler component. For non-HTML requests, error responses now follow RFC 7807 out of the box:

{
    "title": "Not Found",
    "status": 404,
    "detail": "Sorry, the page you are looking for could not be found"
}

No Twig required. The format follows the Accept header: JSON for JSON requests, XML for XML requests. To customize further, you provide a normalizer via the Serializer component rather than a Twig template.

PHP 7.4 preloading, wired in automatically

PHP 7.4 introduced OPcache preloading: load files into shared memory before any requests arrive, so they’re available as compiled opcodes from the very first request. The practical gain is 30-50% faster response times with no code changes.

The catch is configuration: you need to specify exactly which files to preload in php.ini. Symfony 4.4 generates that file automatically in the cache directory:

; php.ini
opcache.preload=/path/to/project/var/cache/prod/App_KernelProdContainer.preload.php
opcache.preload_user=www-data

Run cache:warmup in production and point OPcache at the generated file. Symfony preloads the container, compiled routes, and Twig templates: the files that are read on every request and never change between deploys.

Console: return codes and NO_COLOR

Two small things in 4.4 that honestly should have existed earlier. Commands that don’t return an integer from execute() now trigger a deprecation warning. In 5.0, the return type becomes mandatory. Returning 0 for success, non-zero for failure: standard Unix behavior, and it makes integration with process supervisors and CI pipelines unambiguous.

protected function execute(InputInterface $input, OutputInterface $output): int
{
    // ...
    return Command::SUCCESS; // = 0
}

The second: NO_COLOR environment variable support, following the convention from no-color.org. Set it and every Symfony console command drops ANSI escape codes regardless of what the terminal claims to support. Useful for CI environments that capture output as text and then choke on color codes embedded in logs.