© Yurii Andreichyn/Shutterstock.com
Die wichtigsten Neuerungen in Symfony 4.3 im Überblick

Auf dem Weg zu Symfony 5


Ende Mai erschien die neue Minor-Version von Symfony. Sie läutet den Auftakt für Symfony 5 ein. Neben den großen neuen Features wie dem Mailer und HTTP-Client Component wurden auch bestehende Komponenten erweitert und verbessert sowie weitere Deprecations eingeführt, deren Funktionen dann in Symfony 5 abgeschafft werden. Hier sind die wichtigsten Neuerungen im Überblick.

Version 4.3 ist das vorletzte Minor-Release in Symfonys 4.x-Zweig. Im November erscheinen zeitgleich Version 4.4 und 5.0. Beide haben den gleichen Featureumfang und unterscheiden sich nur darin, dass in Symfony 5 alle als deprecated markierten Funktionen entfernt werden, die sich seit der vorherigen Major-Version angesammelt haben. Außerdem wird Version 4.4 das nächste Long-Term-Support-Release (LTS), das die Version 3.4 ablösen wird. Die bisherigen Neuerungen bilden also eine wesentliche Grundlage für kommende Features in Symfony 5 und für alle, die auf LTS-Releases setzen. Im Folgenden möchte ich die wichtigsten Neuerungen kurz umreißen.

Was wird entfernt?

Symfony hat ein klar ausformuliertes Backwards-Compatibility-Versprechen. Damit wird sichergestellt, dass ein Upgrade innerhalb der aktuellen Major-Version keine bestehenden Features so verändert, dass sich erwartetes Verhalten ändert und zu Fehlern führt. Eine Ausnahme bilden sicherheitsrelevante Anpassungen. Das heißt, ein Upgrade von 4.2 auf 4.3 sollte mit sehr geringen Anpassungen möglich sein, und man erhält nur im Deprecation-Log einen Hinweis, wenn man sich auf veraltetes Verhalten verlässt. Um ein Upgrade auf Version 5 zu vereinfachen, sollte man sich über diese Deprecations informieren und sie im Rahmen der regulären Wartungsarbeit abbauen. Eine Auflistung der Deprecations sowie Beispiele, wie eine notwendige Anpassung aussehen kann, finden sich unter [1], .

Eine der wichtigsten Deprecations in Symfony 4.3 betrifft die Handhabung verschiedener Typen in Umgebungsvariablen. Bisher war es möglich, z. B. Integer oder Float-Werte als Defaults für Umgebungsvariablen zu hinterlegen. In Zukunft müssen alle Umgebungsvariablen als String definiert werden, da das System diese Werte ebenfalls als String übergibt und so Fehler bei der Verarbeitung vermieden werden.

parameters: # vorher: env(NAME): 1.5 # Deprecation-Warnung parameters: # nachher: env(NAME): '1.5' # Der Wert muss explizit als String deklariert werden

Die Signatur der dispatch()-Methode im EventDispatcher wurde ebenfalls drastisch verändert, um sich dem vor Kurzem etablierten PSR-14-Standard anzugleichen. Während vorher zwei Argumente benötigt wurden (der Name des Events und das Event-Objekt, das an die Observer übergeben wird), ist künftig nur noch das Event-Objekt verpflichtend und der Name optional. Das führt dazu, dass die Reihenfolge der Parameter vertauscht wird. Mit Symfony 4.3 können beide Varianten verwendet werden, aber Erstere löst eine Deprecation-Warnung aus und wird mit Symfony 5 abgeschafft. Um die alte Logik weiterverwenden zu können, muss der EventDispatcher mit LegacyEventDispatcherProxy::decorate($dispatcher) dekoriert werden. Eine weitere Änderung im Rahmen der EventDispatcher Component ist die Event-Klasse, die bisher als Grundlage (auch für eigene Events) verwendet werden musste. Statt der Event-Basisklasse aus der Komponente sollte künftig Symfony\Contracts\EventDispatcher\Event verwendet werden. Wesentlicher Unterschied ist, dass die neue Klasse das StoppableEventInterface aus dem PSR-Standard implementiert und es somit erlaubt, die Events mit jedem PSR-14-kompatiblen Dispatcher zu verwenden. Die Anpassungen im EventDispatcher haben auch eine Umbenennung der Symfony-eigenen Events zur Folge (Tabelle 1), was die Arbeit mit Symfonys Event Cycle spürbar vereinfacht, da der Klassenname an die Event-Bezeichnung angepasst wurde.

Event-Bezeichnung

alter Klassenname

neuer Klassenname

kernel.request

GetResponseEvent

RequestEvent

kernel.controller

FilterControllerEvent

ControllerEvent

kernel.view

GetResponseForControllerEvent

ViewEvent

kernel.response

FilterResponseEvent

ResponseEvent

kernel.terminate

PostResponseEvent

TerminateEvent

kernel.exception

GetResponseForExceptionEvent

ExceptionEvent

Tabelle 1: Umbenennung der Event-Klassen in Symfony 4.3

In Symfony 4.2 wurde ein neues CacheInterface eingeführt, das von den PSR-6- und PSR-16-Standards abweicht. Grund ist das Cache-Stampede-Protection-Feature [2], das zu diesen Standards inkompatibel ist. Mit dem aktuellen Release wird der so entstandene Wirrwarr an verschiedenen Cacheadaptern aufgeräumt und SimpleCacheAdapter sowie Psr16Adapter werden als deprecated markiert, ebenso die PSR-16-Adapter. Stattdessen sollten entweder Psr16Cache oder das neue CacheInterface aus den Contracts verwendet werden. Das hat Anpassungen in der Framework-Konfiguration zur Folge. Statt das SimpleCacheInterface bzw. dessen Service-ID cache.app.simple zu referenzieren, sollte nun cache.app bzw. das CacheInterface verwendet werden, wenn Services einen Cache ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang