La signature de messages dans Messenger

La sécurité des transports dans Messenger a toujours été le problème de l’application à résoudre. 7.4 ajoute la signature de messages : un mécanisme basé sur des stamps qui signe les messages dispatchés et valide les signatures à la réception.

Le cas d’usage cible est les scénarios multi-tenant ou de transport externe où on a besoin d’une preuve cryptographique qu’un message n’a pas été altéré ni injecté depuis l’extérieur. La configuration vit au niveau du transport :

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

Configuration en tableaux PHP

Les formats de configuration de Symfony ont toujours été YAML (défaut), XML et PHP. Le format PHP existait mais était maladroit : un DSL builder fluent qui nécessitait du chaînage de méthodes et ne donnait rien d’utile à l’IDE.

7.4 remplace le format fluent par des tableaux PHP standard. Les IDEs peuvent maintenant vraiment l’analyser, config/reference.php est auto-généré comme référence avec annotations de types, et le résultat ressemble à des données plutôt qu’à du code :

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

Le format fluent est déprécié. Les tableaux sont l’avenir, et honnêtement c’est un meilleur format.

Améliorations OIDC

#[IsSignatureValid] valide les URLs signées directement dans les contrôleurs, supprimant le boilerplate de la validation manuelle. OpenID Connect supporte maintenant plusieurs endpoints de découverte, et une nouvelle commande security:oidc-token:generate rend le dev et les tests beaucoup moins pénibles.

La fenêtre de support

7.4 LTS : bugs jusqu’en novembre 2028, correctifs de sécurité jusqu’en novembre 2029. Le chemin vers 8.4 LTS (la prochaine cible long terme) passe par les notices de dépréciation de 7.4 et la mise à jour PHP 8.4. Corriger les dépréciations maintenant et le saut vers 8.x sera beaucoup moins douloureux.

Les attributs deviennent plus précis

#[CurrentUser] accepte maintenant les types union, ce qui compte en pratique quand une route est accessible par plus d’une classe utilisateur :

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

#[Route] accepte un tableau pour l’option env, donc une route de debug active seulement en dev et test n’a plus besoin de deux définitions séparées. #[AsDecorator] est maintenant répétable, ce qui signifie qu’une classe peut décorer plusieurs services à la fois. Les signatures de méthode #[AsEventListener] acceptent les types d’événements union. #[IsGranted] reçoit une option methods pour limiter une vérification d’autorisation à des verbes HTTP spécifiques sans dupliquer la route.

La classe Request arrête d’en faire trop

Request::get() est dépréciée, et franchement bonne débarrassance. La méthode cherchait dans les attributs de route, puis les paramètres de query, puis le corps de la requête, dans cet ordre, retournant silencieusement ce qu’elle trouvait en premier. Cette ambiguïté causait de vrais bugs. Elle est supprimée dans 8.0 ; dans 7.4 elle fonctionne encore mais déclenche une dépréciation. Les remplacements sont explicites : $request->attributes->get(), $request->query->get(), $request->request->get().

Le parsing du corps pour les requêtes PUT, PATCH, DELETE et QUERY arrive en même temps. Auparavant Symfony ne parsait application/x-www-form-urlencoded et multipart/form-data que pour POST. Ces mêmes types de contenu sont maintenant parsés pour les autres méthodes accessibles en écriture aussi, ce qui tue un contournement REST API courant.

La surcharge de méthode HTTP pour GET, HEAD, CONNECT et TRACE est dépréciée. Surcharger une méthode sûre avec un header était de toute façon toujours sémantiquement cassé. On peut maintenant autoriser explicitement seulement les méthodes qui ont du sens pour son application :

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

Les Workflows acceptent les BackedEnums

Les places et transitions de Workflow peuvent maintenant être définies avec des backed enums PHP, à la fois en YAML (via le tag !php/enum) et en config PHP. Le marking store fonctionne avec les valeurs d’enum directement, donc le modèle de domaine et la définition du workflow utilisent enfin les mêmes 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

Étendre la validation et la sérialisation pour les classes tierces

Besoin d’ajouter des métadonnées de validation ou de sérialisation à une classe d’un bundle qu’on ne possède pas ? 7.4 a #[ExtendsValidationFor] et #[ExtendsSerializationFor] pour ça. On écrit une classe compagnon avec ses annotations supplémentaires, on pointe l’attribut vers la classe cible, et Symfony fusionne les métadonnées à la compilation du conteneur :

#[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 vérifie à la compilation que les propriétés déclarées existent réellement sur la classe cible. Un renommage ne cassera pas silencieusement la validation.

DX : ce qui ne fait pas la une mais compte

Le helper Question dans Console accepte un timeout. Demander à l’utilisateur de confirmer quelque chose, et s’il ne répond pas en N secondes, la réponse par défaut s’applique. Très pratique dans les scripts de déploiement qui ne peuvent pas se permettre d’attendre éternellement un humain.

messenger:consume reçoit --exclude-receivers. Combiné avec --all, il permet de consommer depuis tous les transports sauf des spécifiques :

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

Le mode worker FrankenPHP est maintenant auto-détecté. Si le processus tourne dans FrankenPHP, Symfony bascule en mode worker automatiquement. Pas de package supplémentaire nécessaire.

La commande debug:router cache les colonnes Scheme et Host quand toutes les routes utilisent ANY, ce qui supprime beaucoup de bruit de la sortie par défaut. Les méthodes HTTP sont maintenant aussi colorées.

Les tests fonctionnels reçoivent $client->getSession() avant la première requête. Auparavant il fallait faire au moins une requête pour accéder à la session, ce qui était agaçant. Maintenant on peut pré-remplir les tokens CSRF ou les flags A/B en amont :

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

Lock : store DynamoDB

DynamoDbStore arrive comme nouveau backend de Lock. Utile dans les déploiements AWS-natifs où Redis n’est pas dans la stack, et ça fonctionne exactement comme n’importe quel autre store :

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

Bridge Doctrine : types day point et time point

Deux nouveaux types de colonnes Doctrine : day_point stocke une valeur date uniquement (sans composant heure) et time_point stocke une valeur heure uniquement, tous deux mappant vers DatePoint. Bien quand le domaine sépare genuinement la date de l’heure :

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

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

Routing : paramètres de query explicites

La clé _query dans la génération d’URL permet de définir les paramètres de query explicitement, séparément des paramètres de route. Ça compte quand un paramètre de route et un paramètre de query partagent le même nom :

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

WebLink : parsing des en-têtes Link entrants

HttpHeaderParser parse les en-têtes de réponse Link en objets structurés. Avant ça, parser des en-têtes Link depuis des réponses d’API nécessitait soit d’importer une bibliothèque tierce, soit d’écrire des regex. Le cas d’usage : les APIs HTTP qui annoncent des ressources liées ou la pagination via des en-têtes Link, comme le fait l’API GitHub.

Le parsing HTML5 est plus rapide sur PHP 8.4

DomCrawler et HtmlSanitizer basculent vers le parser HTML5 natif de PHP 8.4 quand il est disponible. Pas de changements de code nécessaires de votre côté. Le parser natif est plus rapide et plus conforme à la spec que le fallback précédent. Sur PHP 8.2 ou 8.3, rien ne change.

Translation : StaticMessage

StaticMessage implémente TranslatableInterface mais ne traduit intentionnellement pas. Elle passe la string inchangée quelle que soit la locale. Le cas d’usage : les réponses d’API qui doivent rester dans une langue fixe quelle que soit la locale de l’utilisateur, ou les entrées de log d’audit où on doit préserver le texte original tel quel.

AssetMapper

La gestion frontend moderne dans Symfony, ça voulait dire Webpack Encore. Encore fonctionne : il gère la transpilation, le bundling, le versioning, le hot reload. Il nécessite aussi Node.js, une étape de build séparée, et une quantité non négligeable de configuration pour ce qui est souvent un frontend assez modeste.

AssetMapper prend une position différente. Les navigateurs modernes supportent les modules ES nativement. Au lieu de bundler, livrer les fichiers tels quels, laisser le navigateur résoudre les imports via une importmap, et gérer les dépendances vendor via des fichiers téléchargés plutôt que des packages npm.

composer require symfony/asset-mapper
php bin/console importmap:require lodash

Pas de Node.js. Pas de npm. Pas d’étape de build. Les fichiers JavaScript et CSS sont versionnés et servis directement, avec un digest dans l’URL pour le cache busting. Pour les applications où le frontend n’est pas la principale préoccupation d’ingénierie, ça supprime toute une chaîne d’outils de l’équation.

6.4 ajoute les fichiers CSS à l’importmap, le préchargement CSS automatique via WebLink, et des commandes pour auditer et mettre à jour les dépendances vendor. L’expérience package.json, sans npm.

Scheduler

Le composant Scheduler (planification de tâches périodiques et de style cron sans runner externe) sort d’expérimental et devient stable. L’API utilise des attributs :

#[AsCronTask('0 * * * *')]
class HourlyReport implements ScheduledTaskInterface
{
    public function run(): void { ... }
}

Soutenu par les transports Messenger, les tâches tournent dans tout environnement où un worker est en cours d’exécution. Pour beaucoup de cas d’usage, ça remplace le pattern classique entrée cron + commande console.

Webhook et RemoteEvent

Aussi diplômés d’expérimental : le composant Webhook gère les webhooks entrants depuis des services externes. Au lieu d’écrire des contrôleurs bruts qui parsent les payloads et dispatchent des événements à la main, on configure des parseurs pour des services connus (Stripe, GitHub, Mailgun) et on obtient des événements typés.

DatePoint

Une nouvelle classe DatePoint dans le composant Clock : un wrapper DateTime immutable qui lève des exceptions sur les modificateurs invalides au lieu de retourner silencieusement false. Petite chose, mais significative pour le code qui manipule des dates et veut réellement savoir quand quelque chose va mal.

La fenêtre de support

6.4 LTS reçoit des corrections de bugs jusqu’en novembre 2026 et des correctifs de sécurité jusqu’en novembre 2027. Le chemin de 6.4 vers 7.4 (la prochaine LTS) passe par les notices de dépréciation de 6.4, comme d’habitude.

Routes sans strings magiques

Les alias de routes basés sur le FQCN sont maintenant générés automatiquement. Si une méthode de contrôleur a une seule route, Symfony crée un alias en utilisant son nom de classe complet :

// Auparavant : seul 'blog_index' fonctionnait
// Maintenant : les deux fonctionnent de manière identique
$this->urlGenerator->generate('blog_index');
$this->urlGenerator->generate(BlogController::class.'::index');

Pour les contrôleurs invocables, l’alias est juste le nom de classe. L’avantage pratique : navigation IDE et sécurité au refactoring — on référence une constante de classe, pas une string qui peut silencieusement diverger.

Deux nouveaux attributs DI

#[AutowireLocator] et #[AutowireIterator] rejoignent la famille d’attributs DI. Au lieu de configurer des service locators et des itérables taggués en YAML, on les déclare juste sur les paramètres du constructeur :

public function __construct(
    #[AutowireLocator([FooHandler::class, BarHandler::class])]
    private ContainerInterface $handlers,
) {}

Alias, services optionnels (préfixés avec ?), et injection de paramètres via SubscribedService sont tous supportés. Le locator charge paresseusement, donc seuls les handlers qu’on appelle vraiment sont instanciés.

Messenger reçoit des handlers intégrés

Trois nouvelles classes de message couvrent des tâches courantes qui nécessitaient auparavant des handlers personnalisés.

RunProcessMessage dispatche une commande Process via le bus. RunCommandMessage fait de même pour les commandes console. Les deux retournent un objet de contexte avec le code de sortie et la sortie. PingWebhookMessage pingue une URL, ce qui est utile pour surveiller les tâches planifiées sans mettre en place un service de health-check dédié :

$this->bus->dispatch(new RunCommandMessage('cache:clear'));
$this->bus->dispatch(new PingWebhookMessage('GET', 'https://healthchecks.io/ping/abc123'));

Le problème d’héritage des sous-processus a aussi été résolu avec PhpSubprocess. Quand on lance PHP avec une limite mémoire personnalisée (-d memory_limit=-1), les processus enfants lancés avec Process ne l’héritent pas. PhpSubprocess le fait :

$sub = new PhpSubprocess(['bin/console', 'app:heavy-import']);

Sécurité : trois corrections pour des situations réelles

Le profiler montre maintenant comment les badges de sécurité ont été résolus pendant l’authentification : lesquels ont passé, lesquels ont échoué, et pourquoi. Avant, il fallait ajouter de la sortie de debug manuellement quand un authentificateur personnalisé ne se comportait pas bien.

Le throttling de login via RateLimiter hache maintenant automatiquement les PII dans les logs. Les adresses IP et les noms d’utilisateur sont hachés avec le secret du kernel avant d’être écrits. Pas de config nécessaire, pas de regex sur les lignes de log.

Les patterns de firewall acceptent maintenant des tableaux :

firewalls:
    no_security:
        pattern:
            - "^/register$"
            - "^/api/webhooks/"

Fini les acrobaties regex pour les exclusions multi-chemins.

Déconnexion sans contrôleur bidon

La route de déconnexion nécessitait auparavant un contrôleur qui ne faisait rien que lever une exception, avec un commentaire expliquant que oui, c’est intentionnel. 6.4 élimine ça :

# config/routes/security.yaml
_security_logout:
    resource: security.route_loader.logout
    type: service

Le route loader s’en occupe. Le contrôleur bidon est parti. Flex met à jour la recette.

Le sérialiseur en meilleure forme

Trois améliorations du sérialiseur qui résolvent chacune un vrai problème.

Attribut #[Groups] au niveau de la classe : appliquer un groupe à la classe entière, puis surcharger par propriété. Utile quand une ressource a un groupe de sérialisation par défaut et quelques champs qui nécessitent un contrôle plus fin.

Les objets translatable ont maintenant un normaliseur dédié. Les strings translatable (enveloppant TranslatableInterface de Doctrine) sont traduites vers la locale passée via NORMALIZATION_LOCALE_KEY pendant la normalisation. Avant ça, il fallait écrire un normaliseur personnalisé.

En mode debug, les erreurs de décodage JSON utilisent maintenant seld/jsonlint pour de meilleurs messages. Au lieu de “Syntax error”, on obtient la ligne et ce qui s’est vraiment passé :

Parse error on line 1: {'foo': 'bar'}
           ^ Invalid string, used single quotes instead of double quotes

Profilers pour les choses qui n’étaient pas des requêtes HTTP

Le profiler de commande étend le profiler existant aux commandes console. Ajouter --profile à n’importe quelle commande et obtenir une entrée complète dans le profiler : entrée/sortie, temps d’exécution, mémoire, requêtes en base, messages de log. Les commandes qui nécessitaient --verbose plus du timing manuel ont maintenant la même expérience de debug que les requêtes HTTP.

Le profiler de workflow fait de même pour les machines à états. Un nouveau panneau montre une représentation graphique des workflows et les transitions déclenchées pendant la requête. Zéro configuration.

L’accumulation de DX

Plusieurs additions plus petites qui se combinent.

renderBlock() et renderBlockView() sur AbstractController permettent de rendre un bloc Twig nommé et de le retourner comme Response ou string. Pratique pour les réponses Turbo Stream où on veut mettre à jour un fragment sans une action de contrôleur complète.

Le processeur d’env defined retourne un booléen plutôt que la valeur : true si la variable existe et n’est pas vide, false sinon. Utile pour les feature flags pilotés par des variables d’environnement :

parameters:
    is_feature_enabled: '%env(defined:FEATURE_FLAG_KEY)%'

HttpClient accepte maintenant max_retries par requête, surchargeant la stratégie globale de retry. La méthode filter() du composant Finder accepte un second argument pour élaguer des répertoires entiers tôt, ce qui compte quand on cherche dans de grands arbres.

La méthode click() de BrowserKit accepte maintenant des paramètres serveur comme en-têtes supplémentaires, utile dans les tests fonctionnels qui doivent simuler des appels API authentifiés en suivant des liens.

L’impersonation devient utilisable dans les templates

Deux nouveaux helpers Twig : impersonation_path() et impersonation_url(). Ils génèrent les URLs correctes incluant le paramètre de query switch-user, qui est configurable et n’a aucune raison d’être codé en dur dans les templates. Les associer avec l’existant impersonation_exit_path() pour le flux complet d’impersonation admin.

Contrôle des locales, partout où ça manquait

Trois lacunes comblées. TemplatedEmail a maintenant une méthode locale() pour rendre les emails dans la langue du destinataire. runWithLocale() du locale switcher passe maintenant la locale comme argument au callback, donc on n’a pas à la capturer depuis la portée extérieure. Et app.enabledLocales est disponible dans Twig, donc on peut construire des sélecteurs de langue sans coder en dur les listes de locales.

Déployer sur des filesystems en lecture seule

APP_BUILD_DIR est maintenant une variable d’environnement reconnue par le kernel. La définir pour rediriger les artefacts compilés (cache du router, proxies Doctrine, traductions préchargées) vers un répertoire qui existe, même quand le répertoire cache par défaut n’existe pas. MicroKernelTrait l’utilise automatiquement. WarmableInterface a reçu un paramètre $buildDir pour supporter cette séparation : les warmers de cache personnalisés qui écrivent des artefacts en lecture seule doivent se mettre à jour en conséquence.

5.4 est la version LTS, et son rôle est de porter autant que possible le jeu de fonctionnalités de 6.0 tout en conservant la compatibilité 5.x. C’est aussi la première version de Symfony qui comprend réellement les fonctionnalités de PHP 8.1.

Support des enums

PHP 8.1 a introduit les enums natifs. Symfony 5.4 les embrasse immédiatement :

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

Le type de formulaire EnumType rend les enums sous forme de listes déroulantes, sans transformateurs personnalisés. Le validateur comprend les backed enums. Le sérialiseur mappe les valeurs d’enum sur leur type de backing et inversement. Trois composants mis à jour d’un coup, ce qui a rendu la migration des bases de code des pseudo-constantes enum vers les vrais enums PHP 8.1 étonnamment fluide.

Cache des voters de sécurité

La CacheableVoterInterface permet aux voters qui s’abstiennent toujours sur un attribut donné de le signaler au système de sécurité, qui peut alors les ignorer lors des vérifications suivantes. Pour les applications avec de nombreux voters, le gain sur les vérifications de permissions s’accumule vite. Petit changement, perceptible en pratique.

Messenger continue de mûrir

Le traitement par batch de Messenger (gérer plusieurs messages en une seule transaction au lieu d’un par un) est maintenant stable. Rate limiting par transport. Les dead letter queues bénéficient de meilleurs outils. Après des années en mode « expérimental », Messenger en 5.4 est enfin la fondation async sur laquelle on peut s’appuyer pour des charges sérieuses.

La Console a eu sa touche Tab

Symfony 5.4 embarque l’autocomplétion shell pour toutes les commandes. Appuyez sur Tab et le shell suggère les noms de commandes, les valeurs d’arguments et les valeurs d’options. Pour les commandes intégrées, ça fonctionne sans configuration. Pour les commandes personnalisées, ajoutez une méthode complete() :

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']);
    }
}

Pas d’interface requise, juste la méthode et Symfony s’en charge. La communauté a aussi passé en revue toutes les commandes intégrées (debug:router, cache:pool:clear, secrets:remove, lint:twig, et une dizaine d’autres) pour ajouter les compléments avant la sortie.

Les routes peuvent être des alias maintenant

Le composant de routing supporte désormais les alias : une route peut pointer vers une autre. Le cas d’usage évident, c’est renommer une route sans casser tout ce qui génère encore des URLs avec l’ancien nom.

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

# ancien nom conservé pendant la transition
dashboard:
    alias: admin_dashboard
    deprecated:
        package: 'acme/my-bundle'
        version: '2.3'

Générer une URL avec dashboard fonctionne toujours, mais déclenche un avertissement de dépréciation. Des chemins de renommage propres pour les bundles qui doivent maintenir des noms de routes publics tout en avançant.

Les exceptions sont mappées aux codes HTTP dans la config

Avant 5.4, mapper une classe d’exception à un code HTTP signifiait implémenter HttpExceptionInterface ou écrire un listener. Maintenant c’est juste une entrée YAML :

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

L’exception n’a rien à implémenter. Le framework lit la map, définit le code de statut, loggue au niveau configuré. Pratique pour les exceptions métier qui n’ont aucune raison de connaître HTTP.

Deux nouvelles contraintes de validation

5.4 ajoute Cidr et CssColor au composant Validator.

Cidr valide la notation réseau (adresse IP plus masque de sous-réseau) avec un contrôle sur la version IP acceptée et les bornes de la valeur du masque :

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

CssColor valide qu’une chaîne est une couleur CSS valide. Utile pour les éditeurs de thème, la config CMS, ou toute interface qui laisse les utilisateurs choisir des couleurs :

#[Assert\CssColor(
    formats: Assert\CssColor::HEX_LONG,
    message: "La couleur d'accentuation doit être une valeur hex à 6 chiffres.",
)]
private string $accentColor;

Attributs PHP imbriqués pour les contraintes de validation

Symfony 5.2 avait ajouté les contraintes de validation en attributs PHP, mais PHP 8.0 avait une limitation sur les attributs imbriqués. Les contraintes complexes comme All, Collection, ou AtLeastOneOf étaient impossibles à exprimer avec la syntaxe d’attribut seule. PHP 8.1 a levé cette restriction, et 5.4 en tire le meilleur parti :

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: 'Doit être un email ou une URL valide.',
    )]
    private string $contact;
}

Pas de docblocks d’annotations, pas de mapping XML. Des attributs PHP 8.1 purs, de bout en bout.

Injection de dépendances : trois choses à savoir

Les itérateurs taggués peuvent maintenant être injectés dans des service locators, qui n’acceptaient auparavant que des listes de services explicites. L’autowiring des types union fonctionne quand les deux côtés de l’union résolvent vers le même service, ce qui est courant avec les interfaces du serializer :

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

#[SubscribedService] remplace l’introspection automatique que ServiceSubscriberTrait faisait implicitement. C’est maintenant un attribut explicite sur les méthodes, ce qui rend la dépendance visible sans aucune magie :

use Symfony\Contracts\Service\Attribute\SubscribedService;

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

Messenger : attributs, état des workers et reset de services

Les handlers Messenger peuvent abandonner MessageHandlerInterface en faveur de #[AsMessageHandler], qui permet aussi de lier un handler à un transport spécifique et de définir sa priorité, sans toucher au YAML :

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

L’état des workers est maintenant inspectable via WorkerMetadata dans les event listeners, utile quand vous avez des workers sur plusieurs transports et avez besoin de savoir lequel a déclenché un événement donné.

Les workers longue durée accumulent de l’état entre les messages : buffers de l’entity manager, caches en mémoire, connexions ouvertes. La nouvelle option reset_on_message prend en charge la réinitialisation de tous les services réinitialisables entre les messages :

framework:
    messenger:
        reset_on_message: true

Serializer : collecter les erreurs plutôt que lever

Désérialiser du JSON externe dans un DTO typé levait une exception dès la première discordance de type. L’option COLLECT_DENORMALIZATION_ERRORS change ça : toutes les erreurs de type sont collectées dans une PartialDenormalizationException, pour que vous puissiez retourner un 400 propre avec la liste complète des problèmes par champ :

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
    );
}

Le contexte par défaut du serializer peut aussi être défini globalement en YAML, pour ne plus passer les mêmes options à chaque appel.

Négociation de langue intégrée

Deux nouvelles options du framework gèrent l’en-tête Accept-Language sans listeners personnalisés :

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

Avec ça en place, Symfony lit la langue préférée du navigateur, choisit la meilleure correspondance parmi enabled_locales, définit la locale de la requête, et ajoute un en-tête Content-Language à la réponse. L’attribut de route {_locale} a toujours la priorité quand il est présent.

Traduction : extraction, pas mise à jour

La commande translation:update est renommée en translation:extract. L’ancien nom reste comme déprécié. La distinction compte : la commande n’écrit jamais dans une base de données, elle extrait les chaînes traduisibles des fichiers source. Le nouveau nom dit enfin ce qu’elle fait.

lint:xliff gagne aussi une option --format=github qui sort les erreurs en annotations GitHub Actions, pour que les échecs de lint de traduction apparaissent en commentaires de revue de PR plutôt que de se noyer dans les logs.

Raccourcis du contrôleur élagués

Trois raccourcis d’AbstractController sont dépréciés : getDoctrine(), dispatchMessage(), et la méthode générique get() pour récupérer des services arbitraires du container. La direction, c’est l’injection par constructeur explicite. Pour getDoctrine() en particulier :

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

// après — injecter directement
public function __construct(private EntityManagerInterface $em) {}

Request::get() est aussi déprécié. Il cherchait dans les attributs de route, la query string et le corps POST dans un ordre non documenté, ce qui était une excellente façon d’obtenir des résultats surprenants. Utilisez $request->query->get(), $request->request->get(), ou $request->attributes->get() et soyez explicite sur la provenance de la valeur.

La classe utilitaire Path

Le composant Filesystem reçoit une classe Path portée depuis webmozart/path-util. Elle gère les cas tordus que dirname() et realpath() ratent :

use Symfony\Component\Filesystem\Path;

Path::canonicalize('../config/../config/services.yaml'); // '../config/services.yaml'
Path::getDirectory('C:/');                               // 'C:/' (dirname() retourne '.')
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'

Utile dès que votre code manipule des chemins qui traversent les frontières des OS ou qui contiennent des segments relatifs.

Les petites choses qui s’accumulent

debug:dotenv montre quels fichiers .env ont été chargés et quelle valeur chaque variable résout. La première chose qu’on cherche quand un comportement spécifique à un environnement déraille.

Le composant String ajoute trimPrefix() et trimSuffix() pour retirer des préfixes ou suffixes connus sans écrire un calcul de substr :

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

DomCrawler reçoit innerText(), qui retourne uniquement le texte direct d’un nœud, à l’exclusion des éléments enfants. text() retourne tout y compris le texte imbriqué ; innerText() retourne uniquement le contenu propre du nœud. Petite différence, mais ça compte quand on fait du scraping.

Le composant RateLimiter étend son support des intervalles avec perMonth() et perYear(), pour les applications qui ont besoin de limiter des événements sur des fenêtres plus longues : envois de newsletters, remises à zéro de quotas API, limites de forfaits annuels.

Le composant Finder respecte maintenant les fichiers .gitignore dans tous les sous-répertoires quand vous appelez ignoreVCSIgnored(true), pas seulement à la racine. Les règles des répertoires enfants supplantent celles des parents, exactement comme git lui-même.

La fenêtre LTS

5.4 reçoit des corrections de bugs jusqu’en novembre 2024 et des correctifs de sécurité jusqu’en novembre 2025. La migration de 5.4 vers 6.4 (la prochaine LTS) est intentionnellement fluide : corrigez les avertissements de dépréciation de 5.4, et le saut vers 6.x devient mécanique.

La couche de dépréciation en 5.4 pointe vers tout ce que 6.0 supprime : les derniers morceaux de l’ancien système de sécurité, ContainerAwareTrait, et quelques patterns legacy de formulaires et de serializer.

La fonctionnalité qui mérite d’être mise en avant est arrivée en 4.2 et a mûri tout au long des 4.3 et 4.4 : HttpClient.

HttpClient

Les options HTTP natives de PHP (file_get_contents avec des contextes de flux, cURL, Guzzle) ont chacune leur propre modèle, leurs propres bizarreries et leur propre coût d’abstraction. Symfony 4.2 a introduit HttpClient, un client HTTP first-party avec une seule API pour plusieurs transports.

L’interface est claire :

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

L’implémentation est asynchrone par défaut. Les réponses sont paresseuses : la requête réseau n’a pas lieu tant qu’on ne lit pas réellement la réponse. Plusieurs requêtes peuvent être initiées et résolues au fil de l’arrivée des données, sans threads ni callbacks.

Le transport mock intégré (MockHttpClient) rend les tests d’appels HTTP indolores sans avoir à démarrer des serveurs ou patcher des fonctions globales.

Mailer

Également stabilisé en 4.4 : le composant Mailer, qui remplace SwiftMailerBundle comme solution d’email recommandée. Le transport se configure via DSN :

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

L’approche DSN signifie que changer de fournisseur (Mailgun, Postmark, SES, SMTP local) est un changement de config, pas un changement de code. Les tests d’emails utilisent un spooler par défaut dans les environnements hors production.

Messenger se mâture

Le composant Messenger a atterri en 3.4 à titre expérimental. En 4.4, il est stable et éprouvé en production : gestion de messages asynchrones avec logique de retry, transport d’échec, et adaptateurs pour AMQP, Redis, Doctrine, et les transports in-process.

Le pattern qu’il permet (traiter une requête de façon synchrone, dispatcher du travail de façon asynchrone, réessayer en cas d’échec) remplace toute une classe de setups Gearman/RabbitMQ qui nécessitaient des bibliothèques tierces et une configuration conséquente.

La fenêtre LTS

La 4.4 est supportée pour les bugs jusqu’en novembre 2022 et pour les correctifs de sécurité jusqu’en novembre 2023. Si vous êtes sur la 4.x et recherchez la stabilité, c’est un endroit confortable où rester. Les avertissements de dépréciation qu’elle introduit pointent directement vers ce que la 5.0 exigera.

Le composant Messenger, de l’expérimental à la production

Messenger est arrivé en 4.1 comme une expérience. Le concept était simple : dispatcher un objet message vers un bus, le traiter immédiatement ou le router vers un transport pour un traitement asynchrone. En 4.3 et 4.4, l’expérience était devenue de l’infrastructure.

La release 4.3 a ajouté un transport d’échec dédié. Quand un message échoue après toutes les tentatives de retry, il va quelque part de récupérable plutôt que de simplement disparaître :

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

Les messages qui atterrissent dans failed peuvent être inspectés et retentés manuellement. Avant ça, les messages en échec étaient une entrée de log et un mal de tête. Après, c’est une file qu’on peut vraiment travailler.

Le dispatching d’événements, avec les objets en première place

Depuis le début, le système d’événements de Symfony utilisait des noms d’événements en chaîne comme identifiant principal. On définissait OrderEvents::NEW_ORDER = 'order.new_order', on écoutait cette chaîne, et on passait l’objet événement comme paramètre secondaire.

La 4.3 a inversé ça. L’objet événement passe en premier, et le nom de l’événement devient optionnel :

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

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

Omettez le nom et Symfony utilise le nom de classe comme identifiant. Les listeners et subscribers peuvent maintenant référencer la classe directement :

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

Les événements HttpKernel ont été renommés en conséquence : GetResponseEvent est devenu RequestEvent, FilterResponseEvent est devenu ResponseEvent. Les anciens noms sont restés comme alias pendant toute la 4.x.

VarDumper obtient un serveur

Un dump() dans un contrôleur qui retourne du JSON, et votre sortie de debug se retrouve injectée directement dans le corps de la réponse. Pour le développement d’API, c’est suffisamment agaçant pour que les gens désactivent le dumping complètement.

La 4.1 a ajouté un serveur VarDumper qui capture les dumps séparément :

bin/console server:dump

Configurez la destination du dump dans config/packages/dev/debug.yaml :

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

Maintenant, dump() dans votre contrôleur API envoie les données vers la console du serveur au lieu de polluer la réponse. Le serveur affiche le dump avec le fichier source, la requête HTTP qui l’a déclenché, et le timestamp.

VarExporter, pour quand var_export() vous déçoit

var_export() a deux problèmes : il ignore la sémantique de sérialisation et sa sortie n’est pas conforme à PSR-2. Le composant VarExporter de la 4.2 corrige les deux.

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

Plus important encore, il gère correctement les objets implémentant Serializable, __sleep, et __wakeup. Là où var_export() abandonne silencieusement les méthodes de sérialisation et exporte les propriétés brutes, VarExporter produit du code qui appelle les mêmes hooks qu’unserialize() utiliserait. Le cas d’usage pratique est le préchauffage du cache : générer des fichiers PHP que OPcache peut charger sans ré-exécuter des calculs coûteux.

Des mots de passe vérifiés contre les bases de données de violations

La contrainte NotCompromisedPassword est arrivée en 4.3. Elle vérifie les mots de passe soumis contre la base de données de violations d’haveibeenpwned.com sans envoyer le vrai mot de passe nulle part.

use Symfony\Component\Validator\Constraints as Assert;

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

L’implémentation utilise la k-anonymité : on hash le mot de passe en SHA-1, on envoie seulement les cinq premiers caractères à l’API, on récupère tous les hashs correspondants, on vérifie localement. Le mot de passe ne quitte jamais votre serveur. Pour les formulaires d’inscription, ajouter cette contrainte c’est une ligne et un signal de sécurité vraiment utile.

Workflow obtient du contexte

Le composant Workflow existait avant la 4.x, mais la 4.3 a ajouté la propagation de contexte : la possibilité de passer des données arbitraires à travers une transition et d’y accéder dans les listeners.

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

Le contexte arrive dans TransitionEvent et est stocké aux côtés du marquage. Pour les pistes d’audit, c’est la différence entre savoir qu’une transition s’est produite et savoir qui l’a déclenchée et pourquoi. On peut aussi injecter du contexte depuis un subscriber sans toucher à chaque appel apply(), ce qui est pratique pour les préoccupations transversales comme les timestamps ou l’utilisateur courant.

L’autowiring est devenu plus intelligent

La 4.2 a ajouté la liaison par type et par nom simultanément. Avant, on pouvait lier par type (LoggerInterface) ou par nom ($logger), mais pas les deux en même temps. Ça posait problème quand un service a besoin de deux implémentations différentes de la même 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
    ) {}
}

La correspondance exige que le type et le nom de l’argument s’alignent, donc pas de risque d’injecter accidentellement le mauvais logger.

ErrorHandler remplace le composant Debug

Le composant Debug, inchangé depuis 2013, avait une dépendance maladroite sur TwigBundle même pour les apps API-only. Toute exception non attrapée dans une API JSON rendait une page d’erreur HTML à moins d’écrire des listeners d’exception personnalisés.

La 4.4 extrait ça dans un composant ErrorHandler dédié. Pour les requêtes non-HTML, les réponses d’erreur suivent désormais RFC 7807 nativement :

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

Pas besoin de Twig. Le format suit l’en-tête Accept : JSON pour les requêtes JSON, XML pour les requêtes XML. Pour personnaliser davantage, on fournit un normalizer via le composant Serializer plutôt qu’un template Twig.

Le préchargement PHP 7.4, câblé automatiquement

PHP 7.4 a introduit le préchargement OPcache : charger des fichiers en mémoire partagée avant l’arrivée de toute requête, pour qu’ils soient disponibles sous forme d’opcodes compilés dès la toute première requête. Le gain pratique est de 30 à 50 % de temps de réponse en moins sans changer une ligne de code.

Le bémol c’est la configuration : il faut spécifier exactement quels fichiers précharger dans php.ini. Symfony 4.4 génère ce fichier automatiquement dans le répertoire de cache :

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

Lancez cache:warmup en production et pointez OPcache vers le fichier généré. Symfony précharge le container, les routes compilées et les templates Twig : les fichiers lus à chaque requête et qui ne changent jamais entre les déploiements.

Console : codes de retour et NO_COLOR

Deux petites choses en 4.4 qui auraient honnêtement dû exister plus tôt. Les commandes qui ne retournent pas d’entier depuis execute() déclenchent maintenant un avertissement de dépréciation. En 5.0, le type de retour devient obligatoire. Retourner 0 pour le succès, non-zéro pour l’échec : comportement Unix standard, et ça rend l’intégration avec les superviseurs de processus et les pipelines CI sans ambiguïté.

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

Le deuxième point : le support de la variable d’environnement NO_COLOR, suivant la convention de no-color.org. Activez-la et toutes les commandes console de Symfony abandonnent les codes d’échappement ANSI quelle que soit la capacité déclarée par le terminal. Utile pour les environnements CI qui capturent la sortie en texte et qui s’étranglent sur les codes couleur intégrés dans les logs.

3.4 n’est pas une version de fonctionnalités. Elle livre exactement les mêmes fonctionnalités que 3.3, plus chaque avertissement de dépréciation que 4.0 va rendre obligatoire. Son seul objectif est d’être l’outil de migration : monter de 3.3 à 3.4, corriger ce qui apparaît dans les logs, puis passer à 4.0 proprement.

Pourquoi les versions LTS comptent dans le modèle Symfony

Symfony publie une nouvelle version mineure tous les six mois. Ce rythme serait brutal pour les applications en production, donc le projet désigne chaque quatrième mineure comme LTS : trois ans de corrections de bugs, quatre de correctifs de sécurité. Ce qui signifie que les équipes peuvent cibler 3.4 et arrêter de penser aux mises à jour pendant un moment.

3.4 est la dernière LTS de la ligne 3.x. Si on est encore sur 2.x ou un 3.x ancien, c’est la zone d’atterrissage.

La couche de dépréciations

Chaque fonctionnalité supprimée par 4.0 est dépréciée dans 3.4. Faire tourner son application sur 3.4 avec les notices de dépréciation activées transforme les logs en une liste de tâches. Les plus courantes :

• Les services sans visibilité explicite (public/private) génèrent des warnings — 4.0 rend tous les services privés par défaut
• ControllerTrait est déprécié au profit de AbstractController
• Les anciennes interfaces d’authentificateur de sécurité sont marquées pour suppression
• La configuration de services YAML seule sans annotations d’autowiring déclenche des warnings

Le workflow prévu : monter sur 3.4, faire tourner la suite de tests avec les notices de dépréciation comme erreurs (SYMFONY_DEPRECATIONS_HELPER=max[self]=0 dans PHPUnit), corriger tout ce qui échoue. Après ça, la montée vers 4.0 est essentiellement mécanique.

La fenêtre de support

3.4 LTS reçoit des corrections de bugs jusqu’en novembre 2020 et des correctifs de sécurité jusqu’en novembre 2021. C’est une marge confortable pour les applications qui ne peuvent pas suivre chaque version. Le coût : rester sur l’architecture 3.x, sans Flex, sans structure micro-framework, sans autowiring zéro-config par défaut.

Le pont est là. Savoir si et quand on le traverse est une décision business, pas technique.

Les services passent privés

3.4 a inversé la visibilité par défaut des services de public à privé. Avant, $container->get('app.my_service') était du code parfaitement normal. Après, c’est un anti-pattern qui génère un warning de dépréciation dans 3.4 et casse complètement dans 4.0.

La raison est simple : récupérer des services directement depuis le conteneur masque les dépendances et déjoue l’analyse statique. En injectant via le constructeur, le conteneur peut optimiser le graphe, supprimer les services inutilisés, et détecter les erreurs à la compilation. En les récupérant à l’exécution, il ne peut pas.

Pour les applications qui utilisent déjà l’autowiring, la migration est généralement légère. Le point délicat ce sont les contrôleurs qui étendent Controller et appellent $this->get('quelque-chose'). La correction consiste à passer à AbstractController, qui fournit les mêmes raccourcis mais via des service locators paresseux plutôt que l’accès direct au conteneur.

Pour les services qui ont vraiment besoin d’être publics (accédés depuis du code legacy ou des tests fonctionnels), les marquer explicitement :

services:
    App\Service\LegacyAdapter:
        public: true

Lier les arguments scalaires une seule fois

Un point de friction classique avec l’autowiring : les arguments de constructeur scalaires. Si dix services ont tous besoin de $projectDir, il fallait configurer chacun individuellement. La clé bind sous _defaults règle ça :

services:
    _defaults:
        autowire: true
        autoconfigure: true
        bind:
            $projectDir: '%kernel.project_dir%'
            $mailerDsn: '%env(MAILER_DSN)%'
            Psr\Log\LoggerInterface $auditLogger: '@monolog.logger.audit'

Tout service avec un paramètre de constructeur nommé $projectDir reçoit la valeur liée automatiquement. On peut aussi lier par type-hint, ce qui gère le cas courant où plusieurs canaux de logger existent et on en a besoin d’un spécifique. Les liaisons dans _defaults s’appliquent à tous les services du fichier ; on peut surcharger par service si nécessaire.

Injecter les services taggués sans compiler pass

Avant 3.4, collecter tous les services avec un tag donné nécessitait d’écrire un compiler pass. Il y a maintenant un raccourci YAML :

services:
    App\Chain\TransformerChain:
        arguments:
            $transformers: !tagged app.transformer

class TransformerChain
{
    public function __construct(private iterable $transformers) {}
}

La notation !tagged crée un IteratorArgument : les services sont instanciés paresseusement au fil de l’itération, donc les transformers non utilisés ne sont jamais construits. Pour l’ordonnancement, ajouter un attribut priority à la définition du tag sur chaque service.

Un logger livré avec le framework

Pas de Monolog ? Pas de problème. Symfony 3.4 inclut un logger PSR-3 qui écrit sur php://stderr par défaut. On l’injecte avec Psr\Log\LoggerInterface :

use Psr\Log\LoggerInterface;

class MyService
{
    public function __construct(private LoggerInterface $logger) {}

    public function doSomething(): void
    {
        $this->logger->warning('Quelque chose de douteux s\'est produit', ['context' => 'ici']);
    }
}

Le niveau minimum par défaut est warning. La cible est les workloads container et Kubernetes où stderr est le puits de logs naturel. C’est délibérément minimal : pas de handlers, pas de processors, pas de channels. Quand on en a besoin, on installe Monolog.

Les Guard authenticators ont reçu une méthode supports()

La méthode getCredentials() du composant Guard jouait un double rôle : décider si l’authentificateur devait gérer la requête, et extraire les credentials. Retourner null était le signal pour passer. Ça rendait le contrat confus.

3.4 a ajouté supports() pour séparer ces responsabilités :

class ApiTokenAuthenticator extends AbstractGuardAuthenticator
{
    public function supports(Request $request): bool
    {
        return $request->headers->has('X-API-TOKEN');
    }

    public function getCredentials(Request $request): array
    {
        // N'est appelé que quand supports() retourne true.
        // Doit toujours retourner des credentials maintenant.
        return ['token' => $request->headers->get('X-API-TOKEN')];
    }
}

L’ancienne GuardAuthenticatorInterface est dépréciée. L’avantage pratique : les classes de base peuvent implémenter la logique partagée getUser() et checkCredentials(), tandis que les sous-classes ne surchargent que supports() et getCredentials(). Une responsabilité chacune.

Deux nouvelles commandes de debug

debug:autowiring remplace l’ancien debug:container --types pour découvrir quels type-hints fonctionnent avec l’autowiring :

$ bin/console debug:autowiring log

Autowirable Services
====================

  Psr\Log\LoggerInterface
      alias to monolog.logger
  Psr\Log\LoggerInterface $auditLogger
      alias to monolog.logger.audit

Passer un mot-clé pour filtrer. Fini de deviner si c’est LoggerInterface ou Logger.

debug:form donne la même capacité d’introspection pour les types de formulaires :

$ bin/console debug:form App\Form\OrderType label_attr

Option: label_attr
  Required: false
  Default: []
  Allowed types: array

Sans arguments, il liste tous les types de formulaires enregistrés, extensions et guessers. Avec un nom de type et un nom d’option, il montre toutes les contraintes sur cette option. Avant ça, on lisait le source ou on tâtonnait.

Les sessions sont devenues plus strictes par défaut

3.4 implémente SessionUpdateTimestampHandlerInterface de PHP 7.0, ce qui apporte deux choses : les écritures de session paresseuses (écrites seulement quand les données ont vraiment changé) et la validation stricte des ID de session (les IDs qui n’existent pas dans le store sont rejetés plutôt que créés silencieusement, ce qui bloque une classe d’attaques de fixation de session).

Les anciennes classes WriteCheckSessionHandler, NativeSessionHandler et NativeProxy sont dépréciées. Le MemcacheSessionHandler (note : pas Memcached) est supprimé, puisque l’extension PECL sous-jacente a arrêté de recevoir des mises à jour pour PHP 7.

Les thèmes de formulaires Twig peuvent maintenant être scopés

Les thèmes de formulaires globaux s’appliquent à tous les formulaires dans l’application. Si un formulaire a besoin d’un look complètement différent, il n’y avait pas de moyen propre de se désinscrire. Le mot-clé only gère ça :

{% raw %}{% form_theme orderForm with ['form/order_layout.html.twig'] only %}{% endraw %}

Le mot-clé only désactive tous les thèmes globaux pour ce formulaire, y compris le form_div_layout.html.twig de base. Le thème personnalisé doit alors soit fournir tous les blocs qu’il utilise, soit les importer explicitement avec {% raw %}{% use 'form_div_layout.html.twig' %}{% endraw %}.

Surcharger les templates de bundle sans boucles infinies

Surcharger un template de bundle qu’on avait aussi besoin d’étendre causait autrefois une erreur de référence circulaire. Surcharger @TwigBundle/Exception/error404.html.twig et essayer aussi d’en hériter ? L’ancienne résolution de namespace suivait la surcharge et bouclait indéfiniment.

3.4 a introduit le préfixe @! pour référencer explicitement le template de bundle original, en contournant toutes les surcharges :

{% raw %}{# templates/bundles/TwigBundle/Exception/error404.html.twig #}
{% extends '@!Twig/Exception/error404.html.twig' %}

{% block title %}Page non trouvée{% endblock %}{% endraw %}

@TwigBundle résout vers la surcharge si elle existe. @!TwigBundle résout toujours vers l’original. Surcharger-et-étendre, sans les acrobaties.