TYPO3 Release v13 - Neue Funktionen

Dieser Artikel besteht aus mehreren Unterseiten:

Einführung
Neue Funktionen
Neue Funktionen (für Kunden)
Neue Funktionen (für Entwicklerinnen und Entwickler)
Breaking Changes
Deprecations

• Neue Dateiformate: WebP und AVIF Formate können gelesen/erzeugt werden - [Changelog 1 Changelog 2 Changelog 3]
• SVG-Dateien können ohne Qualitätsverlust beschnitten (crop) werden. Bislang wurden SVGs beim Beschneiden immer in Pixelgrafiken gewandelt, nun werden echte Vektorgrafiken ausgelesen. - [Changelog]
• Mittels Drag and Drop können Inhaltselemente einer Seite auf eine andere Seite direkt verschoben werden - [Changelog]
• Es kann nach mehreren Seiten-IDs gleichzeitig in der Seitenbaum-Suche gesucht werden. - [Changelog]
• Der Download von Datensätzen im Backend kann nun über "Vorlagen" (Presets) verwaltet werden, die von Integratoren/Extensions definiert werden können. So können z.B. Datensätze in gezielten CSV/XML-Formaten exportiert werden, ohne dass die gewünschten Spalten dazu jedes mal neu konfiguriert werden müssen. - [Changelog]

• Konfigurierbarer "/typo3" Backend-Pfad: Wem es bisher ein Dorn im Auge war, man nicht frei einen Einstiegspunkt ins TYPO3-Backend wie "/cms" oder "/redaktionssystem" oder "/totalgeheim" definieren konnte, wird sich freuen: Das ist jetzt konfigurierbar. - [Changelog]
• Die Color-Picker Elemente in TCA-basierten Datensätzen können nun vordefinierte Farb-Paletten erhalten, aus denen konkrete Farben ausgewählt werden können. Auch Transparenz-Informationen können nun spezifiziert werden. - [Changelog 1, Changelog 2]
• EXT:form Eingabefelder können von Redakteuren jetzt mit dem Attribut "autocomplete" definiert werden - [Changelog]
• Nach gezielten Namen von EXT:form Formularen kann nun in der Übersicht gesucht werden. Formulare können sortiert werden. - [Changelog 1, Changelog 2]

• Notifications im Backend können nun gescrollt und alle auf einmal geschlossen werden. Sie erscheinen nun unten rechts, um keine wichtigen Informationen zu überdecken. - [Changelog]
• Geschützte Redirect-Einträge können besser verwaltet/gefiltert/sortiert werden, Prüfergebnisse von Redirects werden besser visualisiert, konfliktierende Redirects können ausgewertet werden (auch via CLI) - [Changelog 1, Changelog 2, Changelog 3]
• Der Link-Checker (Linkvalidator) ermöglicht nun das vollständige Bearbeiten eines Datensatzes mit defekten Links. Zudem ermöglicht der Linkvalidator nun das Prüfen von weiteren Links wie bei Redirects, Dateireferenzen und dem Canonical Link. Eigene Linktypen können mit einem übersetzbaren Label (statt einem einzelnen Identifikator) ausgestattet werden. - [Changelog 1, Changelog 2, Changelog 3]
• Hotkeys/Tastatur-Shortcuts: Durch eine neue Hotkey API ist es möglich, einfach Tastaturkürzel für alle Funktionalitäten zu implementieren (beispielsweise "Speichern und Schließen" und "Speichern"). Für Redakteure können individuelle Hotkeys in einer Extension implementiert werden, z.b. "gehe zur Seite mit Mitgliederdatensätzen" oder "Lösche Cache"). - [Changelog 1, Changelog 2, Changelog 3]
• In der LiveSearch Suche im Backend können nun auch Module (wie z.B. "Seite", "Dateiliste") gefunden und schnell zugegriffen und auch Workspaces gefunden werden. - [Changelog1, Changelog2]

• Mittels UserTSconfig kann die Standardeinstellung der Dateiliste für Redakteure nun auf die Listen- oder Kachelansicht gestellt werden. - [Changelog]
• Neue Backend Dashboard Widgets:
  • Zuletzt geänderte Seiten - [Changelog]
  • Notizen (sys_note) - [Changelog]

• Auch wenn es langweilig klingt: "Fehlerbehebungen und Geschwindigkeitsoptimierungen". Mehrere hundert Bugfixes wurden durchgeführt und an vielen Ecken und Enden die Performance weiter optimiert. Reine Bugfixes tauchen im Changelog nicht auf, sondern tauchen nur in den GIT commit logs und den späteren Release Notes mit auf, daher sind sie in den folgenden Listen auch nicht speziell erwähnt.

Die 🎇Highlights kurz und knapp:

1. Site Sets / Site Set Settings
2. TCA Schema API
3. ViewFactory und Fluid v4
4. EXT:contentblocks Funktionalitäten
5. Extbase File Uploads
6. Rechteverwaltungs-GUI
7. DBAL v4
8. weitere automatisch vom TCA erzeugte Datenbankfelder
9. Extbase Validator-Übersetzungen
10. Statische Routen zu Assets
11. 403 Fehlerhandler mit Redirection
12. Cache-Busting/Handling
13. Viele neue PSR-14 Events
14. EXT:styleguide Integration

• Ermöglichen eine wesentlich einfachere und strukturiertere Zuordnung von TypoScript-Konfiguration von Extensions für mehrere Sites. - [Changelog1, Changelog2, Changelog3]
• Mehrere Sets können genutzt werden, um eigenständige Vorlagen/Zielsetzungen zu ermöglichen, z.B. könnte es ein EXT:felogin Set geben für "Login mit fe_user" und eines für "Login mit OAuth". Innerhalb der Sites kann man dann wählen, welche Set für welche Site gelten soll (oder auch mehrere gleichzeitig, so dass Sets als kombinierbare Einheiten erstellt werden)
• So können jetzt in Multi-Site-Instanzen noch besser Extensions pro Site unterschiedlich konfiguriert werden, und Wiederverwendbarkeit von Extensions mittels Einstellungen wird deutlich übersichtlicher.
• Extension-spezifische Einstellungen wie TypoScript-Konstanten können jetzt über Site Set Settings in einer komfortablen GUI (ähnlich wie Site Settings) verwaltet werden. - [Changelog]
• Abhängigkeiten und Werte von TypoScript-Konfigurationen innerhalb unterschiedlicher Extensions können nun mit Fallback-Defaults und Validierung definiert werden. 
• Die Site Set Settings YAML-Datei kann zudem auch automatisiert in der Dokumentation ausgewertet und dargestellt werden. So werden die Core TYPO3-Extensions nun in deren Dokumentation immer garantiert vollständig mit allen Einstellungen dokumentiert.
• Site Set Settings können nicht nur in TypoScript ausgewertet werden, sondern auch einfach im PHP-Scope (und damit auch einfacher in Backend/CLI-Context!) oder auch innerhalb von Fluid Templates.
• Site Sets sind vollständig versionierbar und deploybar und haben keine Abhängigkeit zu Datenbankeinträgen (keine sys_template Einträge mehr notwendig)
• Site Sets sind nicht verpflichtend, sondern können parallel zur "normalen" TypoScript-Konfiguration eingesetzt werden.
• Site Sets können mittels der GUI nicht nur von Integrator/Developer aktiviert werden, sondern auch von berechtigten Redakteurinnen und Redakteuren.
• Video: 04 Benjamin Franzke - "Settings and Configuration Management", Day 1

• Eine wegweisende Änderung in TYPO3 v13 ist die TCA Schema API. Das TCA in TYPO3 ist die "Source of Truth" für alle datensatzbasierten Operationen. Zugrunde lag dem bisher ein riesiges PHP Array $GLOBALS['TCA'], in dem sehr lose strukturierte Daten vorliegen. Die TCA Schema API setzt darauf nun einen objektorientierten Oberbau auf, der mittelfristig diese große Array ablösen wird. Vorerst ist es ein zusätzlicher Layer, über den TCA-Informationen abgerufen werden können (Lesezugriff). An sehr vielen zentralen Stellen im TYPO3-Kern wird diese API nun benutzt. Auch das Handling von Relationen innerhalb von TCA-Definitionen wird über diese API abgebildet und vereinfacht. Die API ist derzeit noch als intern definiert, Experimente und Feedback beim Einsatz in eigenen Extensions ist jedoch durchaus gewünscht. - [Changelog]

• 🎇 Modernes Frontend-Rendering - Im Zuge des Einbaus für EXT:contentblocks in den Kern wurden diverse Modernisierungen durchgeführt, die die Arbeit in der Erstellung und Ausgabe von Content-Elementen deutlich erleichtern:
• Neues PAGEVIEW TypoScript Content-Object vereinfacht das rendering einer vollständigen Seite mit einer sehr einfachen, minimalen Konfiguration sowie komfortablen "Automatism-by-convention" Maßnahmen - [Changelog]
• Mit dem neuen RecordTransformation DataProcessor kann in Kombination mit dem PAGEVIEW Content-Objekt ein Seitenrendering von Content-Elementen veranlasst werden, das in einem Fluid-Template ohne viel weiteres aufwändiges TypoScript oder erforderliches FluidStyledContent definiert werden kann. Dies ist unter anderem ein Ergebnis der EXT:contentblock Integration in den TYPO3-Kern. - [Changelog]
• Über die Records API können Datensätze von TCA-Relationen ausgewertet und in den durchgereichten Record-Datensatz im Rendering mit Informationen "hydriert" (angereichert) werden, konkret im Kontext vom RecordTransformation DataProcessor. - [Changelog]
• In Verbindung mit dem PageContentFetchingProcessor können BackendLayout Metadaten auch im Frontend nun gezielter ausgewertet werden und das Frontend-Rendering vereinfachen. - [Changelog]
• "Null Coalescing Operator" für TypoScript-Konstanten ermöglicht einen Zugriff mit Syntax wie {$config.alteKonstante ?? $settings.neueKonstante} - [Changelog]
• Die Standard-Tiefe der Datensatzsuche kann mittels Page TSConfig nun seitenspezifisch vordefiniert werden - [Changelog]
• Die Definition von `parseFunc` kann vereinfacht werden und erhält Standard-Definitionen - [Changelog]

• 🎇 Einfache Datei-Uploads: Endlich können Datei-Uploads in Domain-Models als Attribute für Properties genutzt und persistiert (und validiert) werden. - [Changelog]
• Extbase Validatoren für PSR-7 File Uploads: Im Gegensatz zu den oben genannten Domain-Model File-Upload Properties können PSR-7 basierte FileUploads auch vollständig selbständig validiert und "manuell" verarbeitet/persistiert werden. Dazu stehen FileNameValidator, FileSizeValidator, MimeTypeValidator und ImageDimensionsValidator zur Verfügung. - [Changelog]
• 🎇Übersetzungen von Validatoren können nun bei den #[Extbase\Validate()] Attributen übermittelt werden - [Changelog]
• Extbase-Validatoren wird nun der PSR-7 Request-Kontext übermittelt - [Changelog]
• Beim Mapping von Extbase Argumenten können auftretende Exceptions nun von eigenen Extensions gezielt verarbeitet werden. - [Changelog]

• Benutzerrechte wurden bislang immer in der Datenbank gespeichert und waren somit schwer in größeren Projekten versionierbar und deploybar. Dieses Feature hat es leider nur ganz knapp nicht in v13 geschafft, aber wird eines der ersten v14 Features werden! In YAML-Dateien können dann Rechte dateibasiert vergeben und angewendet werden. Dies erhöht den Überblick und verhindert ungewollte Anpassungen an Zugriffsrechten im laufenden Betrieb. Diese Möglichkeit wird zusätzlich zu der datenbankbasierten Rechtevergabe gelten.

• 🎇 Das GUI zum Verwalten von Redakteurs/Gruppen-Rechten wurde verbessert und ermöglicht nun das Zuweisen von Lese/Schreibrechten in einem deutlich komfortableren Interface. - [Changelog]

• Neue Fluid-Version 4. Einige komfortable, nicht-brechende Änderungen an Fluid Standalone erhalten Einzug in TYPO3: - [Changelog]
  • <f:split> ViewHelper (wie PHP explode())
  • <f:join> ViewHelper (wie PHP implode())
  • <f:replace> ViewHelper (wie PHP str_replace())
  • <f:first> und <f:last> für Zugriff auf das erste oder letzte Element eines Arrays
  • <f:constant> für das Auslesen einer PHP-Konstante
• 🎇 Mit dem neuen `ViewFactoryInterface` werden die bisherigen `StandaloneViews` von Fluid abgelöst und ermöglichen einfache Integration mittels Dependency-Injection. Instanzen des Interfaces können über die `ViewFactoryInterface->create($viewFactoryData)` Methode erzeugt werden und erlauben eine einfache Definition der Template/Partial/Layout-Pfade sowie des Request-Objekt-Kontexts. Auch Extbase-Views werden nun direkt auf Basis dieses Interfaces erzeugt. Tipp: Unbedingt auch die Commit-Message zu dieser Änderung lesen, hier steckt viel KnowHow drin! - [Changelog]
• 🎇 Beliebige Tag-Attribute können nun in ViewHelper-Aufrufen übermittelt werden, ohne dass sie registriert werden müssen, sondern in der Ausgabe nativ als Argumente durchgereicht werden können (z.B. "inputmode" für <f:form.textfield>) - [Changelog]
• Inhalt innerhalb von <f:comment> muss nun keine gültige Fluid-Syntax mehr sein - [Changelog]
• Boolean Werte true/false und null können nun wie native PHP Typen genutzt werden. - [Changelog]
• ViewHelper basierend auf dem AbstractViewHelper haben nun nativ direkt die Möglichkeit auf `getContentArgumentName()` zuzugreifen und das Rendering von Kind-Elementen direkt einem speziellen ViewHelper-Arguments des Eltern-Elements zuzuweisen. - [Changelog]
• Mit dem CLI-Befehl `bin/typo3 fluid:schema:generate` können von allen (auch eigenen) ViewHelpern XSD-Schema-Dateien erzeugt werden, und von IDEs wie PHPStorm automatisch ausgewertet werden um Auto-completion und Syntax-Highlighting zu ermöglichen. - [Changelog]
• <f:feature> für Feature-Flag Abfragen - [Changelog]

Das Stichwort "PSR-14 Events" gilt für Erweiterbarkeit des TYPO3-Kerns. An vielen Stellen wurden neue EventDispatcher Aufrufe platziert, so dass Extensions eigene "Listener" für diese Event-Aufrufe registrieren können, um Daten vor/auf/nachzubereiten. Damit kann der TYPO3-Kern flexibel und individuell erweitert werden, ohne dass immer spezielle TYPO3-Patches vorgenommen werden müssten. Derartige Events sind eines der besten standardisierten Features der modernen Entwicklung von TYPO3. Beispiele für neue Events:
 

• BeforeTcaOverridesEvent mit der Möglichkeit, TCA zu modifizieren (z.B. von EXT:contentblocks genutzt)
• Before/AfterTypoLinkEncodedEvent und AfterLinkResolvedByStringRepresentationEvent um TypoLinks und LinkService Links zu beeinflussen
• BeforePageCacheIdentifierIsHashedEvent, ModifyTypoScriptConfigEvent und AfterTypoScriptDeterminedEvent ermöglichen einen frühzeitigen Eingriff in das Frontend-Rendering
• ModifyRecordsAfterFetchingContentEvent kann genutzt werden um Datensätze (tt_content, aber auch eigene) für die Ausgabe im "Content" ContentObject beliebig zu beeinflussen, vor allem die "slide" Funktionalitäten.
• RecordCreationEvent ermöglicht die Eigenschaften eines "Record" Datensatzes (Kontext RecordTransformation DataProcessor) zu modifizieren
• AfterFormDefinitionLoadedEvent um EXT:form Definitionen dynamisch zu beeinflussen
• After/BeforeTransformTextForPersistenceEvent und After/BeforeTransformTextForRichTextEditorEvent um RTE-Transformationen vor/nach dem Persistieren dynamisch auszuführen. Anstelle von oftmals schwierigen YAML-Definitionen für allow/denyTags kann man dies mittels PHP individueller definieren (oder erweitern/einschränken).
• BeforeCountriesEvaluatedEvent um die dynamische Länderauswahl in FormEngine bzw. ViewHelpern anzupassen
• ModifyRedirectUrlValidationResultEvent um bei EXT:felogin die Ziel-URLs nach einem Redirect auch auf externe Domains zu erweitern/validieren
• BeforeRecordDownloadIsExecutedEvent und BeforeRecordDownloadPresetsAreDisplayedEvent für Backend-Downloads von Datensätzen
• AfterRawPageRowPreparedEvent um Elemente im Seitenbaum dynamisch zu erweitern (Baumdarstellung reduzieren/erweitern)
• PackageInitializationEvent um automatisch Dinge nach der Installation gewisser Extensions auszuführen (z.B. Datenimport, Notifications oder ähnliches)
• BeforeLoadedPageTsConfigEvent und BeforeLoadedUserTsConfigEvent ermöglicht dynamischen Zugriff auf Page/UserTSConfig (der jedoch als runtime-static, d.h. cachebar angesehen wird, also nicht zu dynamischer Laufzeitmodifikation gedacht ist)
• ModifyDefaultConstraintsForDatabaseQueryEvent um Standard-Einschränkungen ("WHERE-Conditions") für alle TCA-basierten Datenbankabfragen auf Seiten ("PageRepository") zu setzen
• After/BeforeStdWrapFunctionsInitializedEvent, After/BeforeStdWrapFunctionsExecutedEvent zum Erweitern von stdWrap Content-Elementen
• ModifyUrlForCanonicalTagEvent kann nun sinnvoller verwendet werden, um "canonical" Meta-Tags zu beeinflussen.
• ModifyRecordOverlayIconIdentifierEvent für eigene Record-Icons im Backend
• BeforePageIsRetrievedEvent um ein vollständiges Seiten-Objekt austauschen zu können mit eigenen/anderen Daten

PHP unterstützt mittlerweile komfortable native PHP-Attribute, die phpdoc Annotationen ablösen. Auch Symfony, vor allem Symfony Dependency Injection, macht großen Gebrauch hiervon und kann Attribute zum Tagging nutzen. TYPO3 erweitert die Attribute für:
 

• #[AsEventListener] - Registriert Event-Listener unabhänigg von Services.yaml für PSR-14 Events - [Changelog]
• #[AsController] - Taggt einen Backend(!)-Controller, so dass dieser nicht getrennt in einer Services.yaml registriert werden muss - [Changelog]
• #[AsMessageHandler] - Registriert einen Service unabhängig von Services.yaml als Symfony/Messenger-Handler - [Changelog]

Native PHP-Enum Objekte ermöglichen präziseren Zugriff auf Wert-Konstanten, und werden auch von TYPO3 nun an einigen public API stellen genutzt:
 

• FileType für FAL-Typen - [Changelog]
• IconSize und IconState für Icons - [Changelog]
• InformationStatus für System-Info Hinweise - [Changelog]
• DuplicationBehavior für FAL-Dateioperationen - [Changelog]
• Genereller Enum support in Extbase - [Changelog]

• UriBuilder->buildUriFromRequest ermöglicht einfacher Links für/zu Backend-Extensions anhand des aktuellen Requests (mit weiteren Parametern) zu erzeugen - [Changelog]

Das $request Objekt (auch in $GLOBALS['TYPO3_REQUEST'], was künftig entfernt werden wird) ist für TYPO3 in seiner Middleware-Implementation der zentrale Ort, um Informationen ("State") in der Workflow-Kette zu transportieren. Es kann um Request-Attribute ergänzt und befüllt werden, die an unterschiedlichen Stellen im Code dann ausgelesen werden können. Das ist grundsätzlich nachvollziehbarer und gekapselter, als diesen State in diversen Singleton-Instanzen zu transportieren. Auch Entwickler können sich leichter an ein zentrales Pattern gewöhnen, um an kontext-relevante Informationen zu gelangen. Dieses Konzept wird mit TYPO3 v13 in diversen Stellen erweitert:
 

• frontend.page.information enthält viele Informationen, die früher im TyposcriptFrontendController ($GLOBALS['TSFE']) hinterlegt waren. - [Changelog]
• frontend.cache.instruction ermöglicht Informationen für Caching-Aktivitäten zu hinterlegen und auszulesen - [Changelog]
• frontend.cache.collector ermöglicht cache tags und deren lifetimes zu verwalten. - [Changelog]

Mit dem Upgrade auf Doctrine DBAL 4 gibt es auch neue Features:
 

• (Sortierbare) Driver Middlewares, um gewisse Parameter oder Treiber-Anpassungen der genutzten Datenbank zu konfigurieren (z.b. bei jeder Connection gewisse Werte setzen, Zeichensätze verwalten, Logging, o.ä.) - [Changelog1, Changelog2, Changelog3]
• Datenbankübergreifender SQL UNION Query support - [Changelog]
• ENUMs/SETs können von Doctrine nativ bei MySQL/MariaDB ausgewertet werden. Man sollte jedoch auf den Einsatz diesen Typen versuchen Abstandzu nehmen, da sie diverse Implementationsprobleme mit sich bringen.
• Kleines Easter-Egg: Intern stehen nun "Common Table Expressions" (CTE) im Core zur Verfügung, vorerst experimentell. - [Changelog]
• Neue ExpressionBuilder-Methoden: as (Aliasnamen), concat (Zusammenführung von Strings), castVarchar und castInt (Stringkonvertierung), repeat (Zeichenwiederholung), space (Leerzeichen), left, leftPad und right, rightPad (Stringoperationen), castText (Typwandlung), if (Abfragen) - [Changelog1, Changelog2, Changelog3]

• Mit der "getFormValue" condition können nun auch Array-Werte ausgelesen werden - [Changelog]

• In der "Passwort vergessen"-Mail können im Fluid Template über `userData` auf alle Werte zugegriffen und eingebunden werden (auch für Backend User). - [Changelog1, Changelog2]

• 🎇Statische Routen zu Assets (wie z.B. einem Favicon, Manifest, Fonts oder JavaScript builds) können in den Site Settings definiert werden. Damit können Inhalte aus dem dynamischen '_assets' Verzeichnis gezielt unter einer lesbaren, festen URL aufgerufen werden. - [Changelog]
• 🎇Bei Login-geschützten Seiten kann ein 403 Fehlerhandler konfiguriert werden, der gezielt zu einer definierten Login-Seite führt, und nach erfolgreichem Login wieder genau zu der Ursprungsseite zurückführen kann. - [Changelog]
• Cache-Busting von Assets kann mittels TypoScript oder ViewHelpern forciert werden, oder die Anpassung von Asset-URLS auch vollständig unterbunden werden. - [Changelog1 Changelog2]
• Assets können mit dem ViewHelper <f:image> und dem Parameter base64=true nun inline mit base64-Encoding eingebunden werden (z.B. für E-Mail Templates oder zum Vermeiden separater HTTP Requests für kleine Assets). Weiterhin können auch JavaScript Assets inline eingebunden werden über die <f:asset.css> und <f:asset.script> ViewHelper und dem inline=true Parameter. - [Changelog1, Changelog2]
• Mit der neuen Routing-Option `static` können RouteEnhancers definiert werden, bei denen statische Argumente mit gezielter Validierung versehen werden können. Bislang mussten hierfür eigene RouteEnhancer implementiert werden. - [Changelog]

• Eine Datei Configuration/user.tsconfig in einer Extension kann nun automatisch geladen werden ohne weitere Registrierung. - [Changelog]

• 🎇 Registrierte Content-Elemente (TCA CType) im "New Content Wizard" werden nun automatisch angezeigt, ohne dass man dies separat im TypoScript definieren muss. - [Changelog]
• Die im TCA['ctrl'] hinterlegten Spalten für Systemfelder (starttime, endtime, disabled, fe_group, editlock, descriptionColumn, languageField, transOrigPointerField, transOrigDiffSourceField, translationSource) werden nun automatisch hinterlegt und auch in der Datenbank angelegt - [Changelog]
• Standard System-Felder von Content-Elementen (language, hidden, ...) werden einem CType direkt mitregistriert - [Changelog]
• Items für TCA typ=select/category können nun Gruppierungen der Select-Felder dynamisch durchführen auch für zusätzliche Elemente aus einer foreign table - [Changelog]

• Die ext_tables.sql ist nun größtenteils obsolet, da alle TCA-basierten Datenbankfelder automatisch mit korrekten Definitionen angelegt werden können. Ein neues TCA-Feld 'dbFieldLength' für einige Typen ermöglicht eine genauere Definition. Neu unterstützte TCA Typen für v13: file, email, check, folder, imageManipulation, language, group, flex, text, password, color, radio, link, linline, number, select, input. "default" Zuweisungen von Tabellenfeldern werden nun auch für SQL "text/json/blob" Datentypen ausgewertet. - [Changelog1, Changelog2]

• Mehr stateless services, stringenter Einsatz von Symfony Dependency Injection und starke Typisierung machen den TYPO3-Core zuverlässiger in der Ausführung. Dadurch werden Abhängigkeiten von kleineren Services und "Composition over Extending" bei OOP-Klassen komfortabler und besser verständlich. Der TYPO3-Core-Code wird somit wartbarer und verständlicher, und dadurch auch besser modernisierbar und testbar.

• Mehr native WebComponents mittels lit: Viel Entfernung von jQuery zugunsten von kleineren, dedizierten WebComponents (z.B. dem PageTree, Kontextmenü, Akkordeons, Tabs, etc. pp). Damit einher geht auch der stärkere Einsatz von Javascript ES6 Modules.
• 🎇 Deutlicher Ausbau der 'Styleguide' Extension. Der Name klingt unspektakulär, aber hinter dieser nun im Core eingebundenen Extension versteckt sich ein vollständiger Experimentierkoffer. Hiermit kann man sich alle UI-Elemente von TYPO3 anschauen, für jeden möglichen TCA/FormEngine-Typen gibt es Beispieldatensätze, man kann das Styling von Fehlermeldungen, Akkordeons, Tabs, Backend-Icons etc. pp anschauen, und leicht für den EInsatz in eigenen Extensions übernehmen.

• Der CLI Befehl `bin/typo3 cleanup:localprocessedfiles` unterstützt nun den Parameter `--all` um alle automatisch erzeugten Assets (Zuschnitte, Thumbnails) auf einen Schlag zu löschen und neu erzeugen zu lassen, z.b. wenn man die GFX-Optionen optimiert hat, oder wenn man häufig FAL-Importe durchführt und resetten möchte. - [Changelog]
• Mit `bin/typo3 setup:begroups:default` können vordefinierte Benutzergruppen (Editor, Advanced Editor, Beide) automatisiert angelegt werden - [Changelog]
• Mit `bin/typo3 upgrade:mark:undone` können Upgrade-Wizards ähnlich wie über die GUI zurückgesetzt und daraufhin neu ausgeführt werden. - [Changelog]
• Mit `bin/typo3 lint:yaml` können alle in Standardverzeichnissen hinterlegte YAML Dateien (z.B. Site Config und Site Set Settings) validiert werden, hilfreich für Deployments.

• In Fehlermeldungen im Frontend (auch den "Oops"-Meldungen) ist nun eine Request-ID sichtbar, die eine Fehlerzuordnung ermöglicht - [Changelog]
• Ein "rotierender" LogfileWriter, der automatisch LogFiles ab einer gewissen Größe oder Datum entfernt und neu schreibt - [Changelog]
• Im Environment-Check können Fehlermeldungen aufgrund deaktivierter PHP-Funktionen nun gezielt unterdrückt werden, falls erforderlich - [Changelog]
• 🎇Automatisches Frontend-Cache Tagging mit Feature-Flag frontend.cache.autoTagging (experimentell) - [Changelog]
• Optimierte HTTP-Cache Header für Einsatzszenario von Reverse Proxies - [Changelog]
• Kleine Randnotiz: Durch die neuen RecordProcessors und andere APIs werden in Fluid-Templates immer häufiger "dynamische" getter benutzt, auf deren Vorhandensein man bei einer <f:debug> Ausgabe als Integrator meist nicht stößt. Um diese Dinge gut zu visualisieren und debugbar zu machen empfiehlt sich sehr der Blick auf
  https://extensions.typo3.org/extension/includekrexx - diese Extension ist ein drop-in Replacement für <f:debug> und bietet extrem komfortables Debugging und Introspection an. Ein Blick darauf lohnt sich sehr!

• Der TypoScript FlexFormProcessor ist nun in der Lage, FAL Referenzen auch in Flexforms direkt auszuwerten - [Changelog]
• Backend-Module können nun beim bauen von Links via <be:moduleLink> den Parameter "returnUrl" übergeben, so dass im Modul-Header ein "Schließen"-Button angezeigt werden kann der zu einem definierten Ziel zurückführt. So kann man zu bestehenden Modulen verlinken um z.B. einen Datensatz zu bearbeiten, und beim "Schließen"-Vorgang zurückkehren zu der Stelle, wo man sich bislang befand. - [Changelog]
• Redis backend mit key prefixing - [Changelog]
• Das Backend-Locking kann nun einen konfigurierbaren Speicherort nutzen - [Changelog]
• Die System-Extension EXT:recycler ist nun standardmäßig bei neuen Installationen immer aktiviert - [Changelog]
• Neuer HashService für HMAC/Hash-Erzeugung - [Changelog]

Auf der nächsten Seite schauen wir uns einmal die Breaking Changes an.