TYPO3 14.0 - Inkompatible Änderungen

Umstellungen in der Architektur und bei Schnittstellen, auch Breaking Changes genannt. Diese Änderungen sind für die Entwicklung und Integration spannend, da die notwendigen Anpassungen Zeitaufwand (=Geld) bedeuten.

Neben der Entfernung von bisherigen Deprecations (vor allem Entfernung von TSFE und list_type in CType) sind die wichtigsten Änderungen:

  • Die neue System Resource API wird übergreifend für Datei-Auflösung/Einbindung eingesetzt, relevant für Sonderfälle bei absRefPrefix-Nutzung
  • Anpassungen in der Backend Module Button-Komponenten/DocHeader-API; kein "rohes" HTML mehr in den verwandten PSR-14-Events mehr erlaubt
  • Durch Anpassungen im XLIFF-Sprachhandling sind eigene XLIFF-Parser anders zu implementieren. Einige Labels wurden verschoben/angepasst.
  • Bessere Nutzung von Symfony Auto-Configuration/Tagging, macht einige manuelle Registrierungsvorgänge obsolet.
  • Entfernung der Frontend/Background Output-Compression und CSS/JS-Minifizierung
  • Die Nutzung von Fluid v5 hat Auswirkungen auf Typ-Deklaration, CDATA-Parsing und ViewHelper-Entwicklung. Auch "null"-Handling für Tag-Attribute und Namespace-Handling wurden verändert.
  • Die URL-Einstiegspunkte `typo3/index.php` und `typo3/install.php` existieren nicht mehr als Datei
  • Vorbereitungen für die Entfernung von `$GLOBALS['TYPO3_REQUEST']` durch striktere `$request`-Middleware-Nutzung
  • Die `fluid_styled_content->parseFunc` Vorlage ist auf ein Minimum reduziert
  • Alte Extbase "Annotations" sind nicht mehr gültig
  • Speicherung von `EXT:scheduler` Tasks wurde verändert
  • Referenz-Index wird für Extbase-Änderungen standardmäßig nun immer genutzt
  • Einige Änderungen im `EXT:felog` Logout-Handling
  • "Einfrieren" von Workspaces entfällt
  • Die composer.json Datei ist nun für alle Extensions verpflichtend, ext_emconf.php reicht nicht mehr aus.

Inkompatible Änderungen in der Architektur und Schnittstellen ("Breaking Changes")

Implementationen für eigene TypolinkBuilder müssen neues Interface nutzen.

Zielgruppe: Entwicklung

Ein neues TypolinkBuilderInterface ersetzt den alten AbstractTypolinkBuilder, und ermöglicht nun komfortable Dependency Injection und direkten Zugriff auf den Request-Kontext. Eine neue Methode build() ersetzt das alte buildLink(). Eigene TypolinkBuilder müssen dieses neue Interface implementieren oder für die Nutzung des alten Abstracts einige Signaturen anpassen.

WissenswertEntfernung von Environment::getComposerRootPath().

Zielgruppe: Entwicklung

Anstelle dieser Method soll nun Environment::getProjectPath() genutzt werden, da durch Vereinheitlichungen im Composer-Installer dieser nicht mehr abweicht im Inhalt des getComposerRootPath().

Sehr wichtigDer Einstiegspunkt typo3/index.php ist nicht mehr verfügbar.

Zielgruppe: Administration

Im Zuge von Konfigurierbarkeit des Backend ist die Erstellung dieser Datei nicht mehr nötig, und wird durch virtuelles Routing (Apache/Nginx-Konfiguration) hergestellt.

Sehr wichtigDer Einstiegspunkt "/typo3/install.php" wurde entfernt.

Zielgruppe: Administration

Das Install-Tool kann nun über den regulären Haupt-Einstiegspunkt "/index.php" geroutet werden. Notfall-Zugriff kann über eine URL-Variable erfolgen.

Entfernung des SortableCollectionInterface.

Zielgruppe: Entwicklung

Dieses Interface war nie vollständig implementiert und war zur Verwaltung von Array-Kollektionen vorgesehen. Eigene Implementationen sollten ein eigenes Interface nutzen oder die PHP-Standardmethoden wie usort/uasort nutzen.

Der TYPO3\CMS\Core\Charset\CharsetConverter wurde vereinfacht und unterstützt nur noch UTF-8.

Zielgruppe: Administration

Da mittlerweile Webseiten alle im UTF-8 Zeichenraum betrieben werden ist eine Nutzung anderer Zeichensätze nicht mehr direkt notwendig und im Core eingesetzt. Wer diese Funktionen genutzt hat, kann andere Hilfsbibliotheken hierfür einbinden (oder den alten Code reaktivieren im eigenen Scope).

Der TYPO3\CMS\Core\Resource\Security\FileNameValidator nutzt nun ein Core-verwaltetes Dateinamensmuster und kann nicht mehr via Konstrukturmethode angepasst werden.

Zielgruppe: Integration

Hierfür wird nun nur noch $GLOBALS['TYPO3_CONF_VARS']['BE']['fileDenyPattern'] ausgewertet.

Nutzung der Record API in DatabaseRecordList.

Zielgruppe: Entwicklung

Der zentrale Controller für die Backend-Verwaltung im Listenmodul (Datensätze) nutzt nun die Record API. Diese ermöglicht ein Auslesen der TCA-Werte anhand von vollständig gebauten Objekten, in denen Relationen und weitere Inhalte bereits aufgelöst wurden. Eigener Code der den DatabaseRecordList-Controller anspricht oder XCLASS-t muss bei den Signaturen oder Aufrufen nun Anpassungen vornehmen.

Sehr wichtigNutzung der Record API im Seitenmodul.

Zielgruppe: Entwicklung

Die Record-API wird intern nun auch zur Auswertung von Datensätzen im Seitenmodul genutzt. Etwaige eigene Implementationen die den StandardContentPreviewRenderer nutzen, oder auf GridColumnItem zugreifen, oder den PageContentPreviewRenderingEvent nutzen, oder das Vorschaurendering über TypoScript via mod.web_layout.tt_content.preview.[recordType] beeinflussen müssen die Record API ebenfalls berücksichtigen.
Beim Einsatz von Content-Blocks ist dies innerhalb der Extension schon bereits früher genutzt worden.

Die Option "zufällige Unterseite" beim Seitentypen "Shortcut" wurde entfernt.

Zielgruppe: Redaktion

Klassen die ModuleInterface implementieren (eher selten, meist wird nur die Module Klasse direkt genutzt, die dieses Interface implementiert) müssen die Methode hasSubmoduleOverview implementieren.

Zielgruppe: Entwicklung

WissenswertAufgrund der Einführung der neuen System-Resource API wird das Datei-Resolving angepasst. .

Zielgruppe: Integration

Die Nutzung des Cache-Bustings nun immer standardmäßig aktiv. Zugriff auf Assets auf FAL-Storages ausser "fileadmin" via direkter URL-Eingabe (statt "FAL-Index"-Syntax) ist nicht mehr möglich. Ausserdem liefert die TypoScript "getData" Methode nun eine absolute anstelle einer relativen URI für aufgelöste Pfade.

Eine interne Middleware in TYPO3, die den gesamten Seiteninhalt auf das Vorkommen von relativen Dateireferenzen durchsucht hat und bei absRefPrefix-Nutzung in absolute Links verwandelt hat ist nun deaktiviert. Bei Nutzung der korrekten APIs, unter anderem der neuen System Resource API und den ViewHelpern und LinkBuildern/UriBuildern/FAL-API-Aufrufen, wird dies keinen Einfluss haben und verbessert die Performance. Die Option additionalAbsRefPrefixDirectories ist hiermit nun auch hinfällig.

WissenswertNutzung des "external" Attributes für Asset-Rendering (z.b. "includeCSS") ist nicht mehr unterstützt und wird durch die neue "URI:" Syntax abgelöst.

Zielgruppe: Integration

Sehr wichtigButton Template Komponenten / Button API.

Zielgruppe: Entwicklung

Durch die Einfügung von Typ-Deklarationen müssen genutzte Methoden der Button API diese Typen einhalten. Eigene Implementationen des ButtonInterface oder DropDownItemInterface müssen entsprechende Deklarationen enthalten. Alle Icon-Deklarationen der Button APIs sind nun nullable. Parameter der MenuItem::isValid und Menu::isValid Methoden dürfen nicht mehr genutzt werden. Eigene Ableitungen der AbstractButton Klasse müssen die entsprechenden Typdeklarationen beachten.

Die neue Button-API hat Änderungen erfordert, die sich in den PSR-14 Events ModifyRecordListRecordActionsEvent und ProcessFileListActionsEvent auswirkt, wie auch DatabaseRecordList::makeControl(). EventListener dieser Events müssen Buttons nun auch via Button API erzeugen, und nicht mehr rohes HTML durchreichen.

WissenswertEntfernung der "OutputCompression"-Option für Frontend und Backend.

Zielgruppe: Administration

Die gzip-Kompression und auch die Option zum "CompressionLevel" wurde entfernt; dies wird bessern von Webservern selbst durchgeführt statt im PHP-Scope. Zugehörige Middlewares wurden entfernt, etwaige eigenen Positionierungen von Middlewares mit diesen Identifizieren müssen geprüft werden.

Bei Nutzung der OutputCompression wurden auch CSS-Dateien "minifiziert", was nun entfällt.

Zielgruppe: Administration

Sehr wichtigEntfernung der Frontend-Asset-Konkatenierung und Kompression.

Zielgruppe: Administration

Assets sollten besser über Build-Routinen oder Webserver-Seitige Funktionen komprimiert werden, als mit der leider fehleranfälligen und problematischen PHP-Implementation.

Sehr wichtigZusammenführung von FlexFormService und FlexFormTools.

Zielgruppe: Entwicklung

Die Funktionalität der beiden Klassen wird nun in FlexFormTools zusammengeführt. Etwaige eigene Nutzung der FlexFormService-Klasse muss angepasst werden.

WissenswertEntfernung "TypoScriptFrontendController" (TSFE).

Zielgruppe: Entwicklung

Durch mehrere Vor-Patches bereits angedeutet (und dort kommentiert, wie man damit umzugehen hat): TypoScriptFrontendController (TSFE) existiert nun nicht mehr als Objekt. Die letzten Reste wurden in den zentralen HTTP RequestHandler überführt.

Sehr wichtigEntfernung von $_GET/$_POST/$_REQUEST Fallbacks.

Zielgruppe: Entwicklung

Der Fallback-Layer, der die Synchronisierung der superglobalen GET/POST/REQUEST-Arrays durchgeführt hat, wurde abgeschaltet. Ein Zugriff auf Request-Variablen und Attribute darf nur noch regular per PSR HTTP Middleware geschen (dem $request Objekt). Mittelfristig wird auch die globale $GLOBALS['TYPO3_REQUEST'] Variable abgeschaltet werden. Middlewares die auf diese Variable nach typo3/cms-frontend/prepare-tsfe-rendering zugreifen, können sich auf diesen Variableninhalt NICHT mehr verlassen (und sollten besser die $request Variable entsprechend durchschleifen/weiterreichen).

Entfernung der MailMessage->send Methode (Mailversand über MailerInterface->send() weiterhin möglich).

Zielgruppe: Entwicklung

Die Registrierung von Benutzer-Backend-Avatar-Providern erfolgt nun mittels Auto-Configuration (via Interface und Attribut #[AsAvatarProvider]) anstelle von Registrierung in TYPO3_CONF_VARS.

Zielgruppe: Entwicklung

WissenswertDie TYPO3-Implementation des UriInterface für URI-Normalisierungen enthielt einen Fehler bei der Verarbeitung von Pfaden ohne führenden "/" und ohne Protokollangaben. In diesen Fällen hat TYPO3 selbständig einen "/" vorangestellt. Dieser Fehler wurde behoben, kann aber Auswirkungen auf eigene Implementationen haben, falls das alte Verhalten gewünscht war und die auf den führenden Slash angewiesen waren.

Zielgruppe: Integration

Sehr wichtigDie Datei "composer.json" ist nun für Extensions zwingend erforderlich; "ext_emconf.php" reicht nun auch für den Classic mode nicht mehr aus. Zudem wird nun der Extension-Name aus dem ersten Teil der composer.json "description" bezogen.

Zielgruppe: Entwicklung

Die Option passwordTransmissionStrategy von TYPO3\CMS\Core\Authentication\processLoginData wurde entfernt.

Zielgruppe: Entwicklung

Diese Option stammte noch aus "RSA"-Backend-Loginzeiten. Etwaige Implementationen dieser Authentifizierungsklasse müssen die Methodensignatur von "processLoginData" beachten.

Die BackendLayout Klasse nutzt strikte Typen.

Zielgruppe: Entwicklung

Die Nutzung der BackendLayout-Klasse in eigenen Extensions muss nun strikte Typen an Methoden überreichen.

EXT:reportsReportInterface und RequestAwareReportInterface entfernt.

Zielgruppe: Entwicklung

Anstelle einer eigenständigen SystemReport-Registry werden Reports nun mit der regulären neuen "Sub-Modul"-Ansicht ausgewertet.

WissenswertNutzung von Symfony Autoconfiguration.

Zielgruppe: Entwicklung

Mehrere Registries nutzen nun Symfony Autoconfiguration anstelle von eigenständiger Registrierung (siehe auch zugehöriges Feature):
* Backend Layout DataProviders
* Extractor Services
* BackendAvatar Provider.

Das Caching-Backend FreezableBackend wurde entfernt.

Zielgruppe: Entwicklung

Dieses Backend war nie vollständig implementiert und wurde nun entfernt.

Die Cache Backends und Frontends nutzen nun strenge PHP Typisierung. Wenn diese in eigenem Code angesprochen werden, muss auf korrekte Typübergaben geachtet werden. Wenn die Klassen erweitert wurden, muss auf übereintimmende Typen für Parameter und Return-Types geachtet werden, vor allem wenn der AbstractBackend Konstruktur aufgerufen wurde.

Zielgruppe: Entwicklung

WissenswertZeitzonen-Handling vereinheitlicht.

Zielgruppe: Entwicklung

Die Verarbeitung von Datensätzen mit Zeitangaben wurde vereinheitlicht, so dass Zeitzonen-Informationen immer (auch bei Feldern nur mit Uhrzeitangabe, ohne Datumsangabe) korrekt übermittelt werden. Falls eigene Extensions via DataHandler API Inhalte in Feldern speichern, die als TCA type=datetime definiert sind, muss berücksichtigt werden, dass dort nun Zeitzonen-Konvertierungen angewendet werden. Frühere "Hacks" sind nicht mehr nötig (und sinnvoll) um ein korrektes Datumsobjekt zu übertragen.

Entfernung der Option storeLogMessages im DataHandler.

Zielgruppe: Entwicklung

Einträge in sys_log bei DataHandler-Änderungen werden nun immer forciert und können nicht mehr deaktiviert werden.

Die public properties copyWhichTables, neverHideAtCopy und copyTree im DataHandler wurden entfernt, um direkt aus dem BE_USER Objekt korrekt ausgewertet zu werden.

Zielgruppe: Entwicklung

Entfernung von DataHandler->bypassWorkspaceRestrictions.

Zielgruppe: Entwicklung

Dieses Attribut war nicht mehr notwendig und konnte intern aufgelöst werden. Nutzung der DataHandler API mit diesem Attribut muss entfernt werden.

Sehr wichtigAlte Deprecations wurden entfernt.

Zielgruppe: Entwicklung

Die in TYPO3 v13 als "Deprecated" markierten Änderungen wurden nun als Breaking Change umgesetzt. Die vermutlich relevantesten Änderungen sind die Entfernung von TSFE und tt_content Subtypen ("list_type") zugunsten von CType. Auch für die Finalisierung des Fluid ViewInterface wurde dessen Kompatibilitätslayer nun final entfernt.

Weiteres:

JavaScript Modul-Namen (und Entfernung kleinerer Hilfsmethoden),
ENUM-Ersetzungen,
alte Hook-Interfaces,
addPageTSConfig und addUserTSConfig,
hmac/HashService.

Entfernung von:
alten Upgrade-Wizards vor TYPO3 v12
Komma-Notation columnsOnly,
alten ClassAliasMaps,
alten PageTree-Farboptionen,
legacy-Icon-Konfiguration (z.B. iconRegistry)
getTcaFieldConfiguration als TCA-Helfer

Das Event AfterCachedPageIsPersistentEvent hat nun keinen Zugriff mehr auf den entfernten TypoScriptFrontendController.

Zielgruppe: Integration

Daten die dort vorher gelagert wurden sind nun im regulären Request-Objekt enthalten.

Das Event AfterMailerInitializationEvent wurde entfernt.

Zielgruppe: Entwicklung

Die Maileranpassung kann stattdessen über den Event BeforeMailerSentMessageEvent geschehen, oder über eine eigene Implementation des MailerInterfaces.

Extbase Validatoren müssen nun setRequest/getRequest Methoden implementieren.

Zielgruppe: Entwicklung

Dies erübrigt sich meist, indem anstelle einer Implementation vom ValidatorInterface direkt der AbstractValidator abgeleitet wird, was meistens der Fall sein sollte.

Sehr wichtigDer Referenz-Index bei Extbase-Repositorymethoden wird nun immer aktualisiert.

Zielgruppe: Entwicklung

Was früher optional war (config.tx_extbase.persistence.updateReferenceIndex), ist aufgrund der erhöhten Wichtigkeit eines gültigen Referenz-Indexes nun Pflicht. Alle Extbase-Repositorymethoden passen nun den Referenz-Index an bei Änderungen an Datenstrukturen. Dies kann zu leicht höherem Ressourcenverbrauch führen, gerade bei Persistierung von vielen Extbase-Entitäten.

Die PropertyMappingConfigurationInterface Klasse nutzt strikte Typen.

Zielgruppe: Entwicklung

Code, der das PropertyMappingInterface von Extbase nutzt muss auf strikte Typen achten, Implementationen hiervon müssen die Signaturen entsprechend anpassen.

Die Extbase-Validator Kurznotation wie TYPO3.CMS.Extbase:NotEmpty wurde entfernt.

Zielgruppe: Entwicklung

Für Validatoren soll stets die Fully-Qualified ClassName Notation (FQCN) genutzt werden, und keine Aliase.

WissenswertEinbindung von Extbase-Backendmodulen ohne Seitenbaum wertet TypoScript-Konfiguration anders aus.

Zielgruppe: Entwicklung

Extbase Backend-Module konnten TypoScript (PageTS Config) anhand einer PID-Auto-Erkennung anwenden. Diese entfällt nun, so dass etwaiges gültiges TypoScript gezielt angesprochen werden muss.

WissenswertFAL API erhält PHP Typ-Deklarationen.

Zielgruppe: Entwicklung

In den FAL API Methoden wurden überall Typisierungen eingefügt. Code, der diese Methoden aufruft oder erweitert, muss daher auf übereinstimmende Typisierung achten. Einige Methoden aus AbstractFile wurden in die spezifischen Implementationen verschoben (rename, copyTo, moveTo). Die Methode rename() wurde aus dem FileInterface entfernt. Das FolderInterface wurde erweitert um einige Pfad/Datei-Methoden, die implementiert werden müssen um künftig bessere Verzeichnis-Treiber zu ermöglichen.

Der $charset Parameter von sanitizeFilename wurde entfernt.

Zielgruppe: Entwicklung

Dieser Methodenaufruf, der im DriverInterface vorgegeben ist, erhält eine leicht andere Signatur, da der Parameter nicht mehr genutzt wurde.

Methoden getIdentifier() und setIdentifier() in der Klasse AbstractFile wurden entfernt.

Zielgruppe: Entwicklung

Diese Methoden befinden sich bereits in den vom Abstract abgeleiteten Implementationen, und sollten nicht in dem Abstract selbst auftauchen. Eigene Implementationen (unwahrscheinlich) müssen angepasst werden.

Anpassung von ProcessedFile / Task.

Zielgruppe: Entwicklung

In der FAL API ProcessedFile und ProcessedFileRepository sowie dem AbstractTask (Processing) wurden einige Methoden umgeschoben um eine zirkuläre Referenz zu vermeiden. Methodenaufrufe vor allem zu ProcessedFile->getTask() und ProcessedFile->generateProcessedFileNameWithoutExtension() in eigenen Implementationen müssen verändert werden.

Entfernung der Datenbankspalten sys_file_metadata.visible und fe_groups.

Zielgruppe: Integration

Diese Felder wurden im Core nie richtig genutzt. Etwaige eigene Nutzung kann wieder hergestellt werden, indem diese Spalten in eigenem TCA hinzugefügt werden.

Entfernung der Felder "alternative" und "link" für gewisse FAL Dateitypen.

Zielgruppe: Integration

Die beiden genannten Felder sind nur noch in der Palette für "Bild"-Dateitypen vorhanden, bei anderen Typen (wie text oder application) werden diese beiden Felder standardmäßig nicht mehr angezeigt.

WissenswertDie Klassen LocalPreviewHelper und LocalScropScaleMaskHelper wurden entfernt.

Zielgruppe: Entwicklung

Dank einer Code-Vereinheitlichung sind diese beiden Klassen im LocalImageProcessor aufgegangen. Dieser kann nun einheitlich Operationen durchführen. Etwaige individuelle Nutzung der Klassen muss angepasst werden. Üblicherweise sollte man nur die Prozessoren direkt nutzen, so dass der Impact gering sein dürfte. Die Klassen waren nicht als API vorgesehen (waren aber nicht intern deklariert).

Wechsel der Exception für getSubFolder() Fehler.

Zielgruppe: Entwicklung

Es wird nun eine spezifische Exception anstelle einer generischen InvalidArgumentException geworfen.

WissenswertTypisierung der FAL Klassen.

Zielgruppe: Entwicklung

In mehreren FAL Klassen wurden strikte PHP-Typen eingefügt. Etwaige Aufrufe der FAL API müssen nun typsicher sein.

Das Handling von XLF-Dateien erfolgt nun mittels "symfony/translate".

Zielgruppe: Entwicklung

Die TYPO3-eigene XLF-Parsing-API wurde zugunsten der Symfony/translate Komponente ausgetauscht. Dies ermöglicht besseres Caching/Warmup. Wer eigene Sprachdateien-Parser geschrieben hat muss ggf. bei Methoden-Aufrufen Signaturen anpassen. Selbstdefinierte Parser werden nun in abweichenden TYPO3-Config-Keys gespeichert. LocalizationFactory::getParsedData() hat eine angepasste Signatur.

Sehr wichtigTCA-Labels von locallang_tabs.xlf werden durch Kurzformen ersetzt, die bei Ersetzungen von "showitems"-Positionierungen nun beachtet werden müssen.

Zielgruppe: Integration

Wo bislang "LLL:EXT:core/Resources/Private/Language/Form/locallang_tabs.xlf" Referenzen genutzt worden, sind diese nun im kurzen Namensraum "core.form.tabs" nun genutzt. Etwaige "showitem" Ersetzungen die bisher mit String-Vergleichen in TCA-Overrides durchgeführt wurden müssen dies berücksichtigen. Ggf. sollte hierfür eine TYPO3-Versionsweiche eingebaut werden.

Neue TCA Option searchable ersetzt searchFields.

Zielgruppe: Entwicklung

Früher mussten durchsuchbare Spalten einer per TCA konfigurierten Tabelle in der Option searchFields aufgelistet werden. Nun können standardmäßig immer alle Felder durchsucht werden, die gemäß TCA-Definition Wörter enthalten (Typen wie "input" oder "text"). Über das searchable Attribut (nun auf Feld-Ebene, nicht auf gesamter Tabellen-Ebene) können dann einzelne Felder auch wieder aus der Suche ausgeschlossen werden (oder aufgenommen werden, wenn die Automatik das Feld sonst ignorieren würde).

Die Spalten "imagewidth/imageheight" in tt_content können nun NULL enthalten.

Zielgruppe: Entwicklung

Früher wurden hierfür immer Werte "0" gespeichert, nun ist dieses Datenfeld auch mit dem korrekten NULL Wert belegbar.

Die TCA-Option "is_static" wurde entfernt.

Zielgruppe: Integration

Datensätze wie früher static_info_tables müssen nicht mehr hiermit ausgezeichnet werden; TCA-Einstellungen wie "readOnly" oder "editlock" sind hierfür besser geeignet. Daher ist die Option "is_static" entfernt worden.

Die Optionen search.case, search.pid und search.andWhere für TCA Definitionen wurde entfernt.

Zielgruppe: Integration

Diese Optionen wurden im Backend nicht (mehr) ausgewertet und sind daher nun entfernt worden.

Die Optionen interface.maxSingleDBListItems und interface.maxDBListItems wurden entfernt.

Zielgruppe: Integration

Diese Einstellungen zur individuellen Begrenzung der dargestellten Datensätze einer Tabelle wurden entfernt zugunsten der TSConfig Optionen mod.web_list.itemsLimitSingleTable und mod.web_list.itemsLimitPerTable.

TCA-Option "eval=year" entfernt.

Zielgruppe: Integration

Die Beschränkung eines Eingabefeldes auf eine Jahreszahl ergab wenig Sinn und wurde zugunsten regulärer Datumsfelder (oder Textfelder mit min/max) gestrichen.

WissenswertNutzung von $GLOBALS['TCA'] in den Stamm-TCA-Dateien ist NICHT mehr möglich.

Zielgruppe: Integration

Diese globale Variable wird nicht mehr an dieser Stelle befüllt und zugänglich gemacht. Nur innerhalb von "TCA-Overrides" kann diese Variable noch genutzt werden. Dieser Schritt sorgt vor, dass mittelfristig $GLOBALS['TCA'] komplett entfernt und durch die TCA Schema API ersetzt werden könnte.

Sehr wichtigDie TypoScript-Condition "getTSFE" wurde entfernt.

Zielgruppe: Integration

Aufgrund der TSFE-Entfernung sind Conditions nun mit request-Attributen zu ersetzen.

Sehr wichtigEntfernung von "TSFE->content".

Zielgruppe: Integration

Durch TSFE-Anpassungen ist im Event "AfterCacheableContentIsGeneratedEvent" die Methode "getController" entfernt worden. Der Inhalt ist dafür nun über ein "getContent()" verfügbar und wird aus einem neuen Request-Attribut "frontend.page.parts" verfügbar gemacht. Hierfür wurde auch in EXT:adminpanel eine leichte Methoden-Signatur-Anpassung nötig, falls dort eigene DataProvider erstellt wurden.

Nutzung des neuen Request-Attributs frontend.page.parts zum Speichern des SYS_LASTCHANGED Eintrags, statt in einem TSFE register.

Zielgruppe: Entwicklung

Die Nutzung von register:SYS_LASTCHANGED im Frontend ist weiterhin möglich, intern wird dies jedoch anders hinterlegt und ausgewertet.

Nutzung eigener "Register" anstelle der TSFE-Register.

Zielgruppe: Entwicklung

Das (intern genutzte) Attribut contentType vom TSFE wurde in das neue Request-Attribut "rontend.page.parts verschoben.

Zielgruppe: Entwicklung

Das alte Attribut TSFE->config['config'] wird nun überall aus dem Request-Attribut frontend.typoscript (seit TYPO3 13 verfügbar) bezogen .

Zielgruppe: Integration

Sehr wichtigDer TypoScriptFrontendController wurde zustandslos, was dessen finale Entfernung ermöglicht.

Zielgruppe: Integration

Alle Zugriffe auf $GLOBALS['TSFE'], $request->getAttribute('frontend.controller') und AbstractContentObject->:getTypoScriptFrontendController() werden nun scheitern und müssen durch gezielte andere Variablenzugriffe ersetzt werden. Dieser Patch ermöglicht nun auch den Zugriff auf "additionalHeaderData" und "additionalFooterData" nun durch einen Zugriff im PageRenderer zu ersetzen.

WissenswertDynamische Aufrufe von PHP-Code via TypoScript (z.B. userFunc) müssen nun mit einem Attribut #[AsAllowedCallable] markiert werden, um unsichere bzw. ungewollte Code-Aufrufe zu vermeiden.

Zielgruppe: Integration

Sehr wichtigErsetzung der Bootstrap-"Modal"-Komponente durch native Dialoge.

Zielgruppe: Integration

Die Nutzung von *.bs.modal Events ist nicht mehr möglich, Bootstrap-Markup wird nicht mehr genutzt. Die TYPO3-spezifischen Modal-Events bleiben verfügbar (typo3-modal-shown, typo3-modal-show).

Die Standardsprache ("0") wird nun im Seitenmodul-Sprachvergleich immer als Referenz herangezogen und dargestellt. Die TSConfig-Option mod.web_layout.defLangBinding wird nicht mehr ausgewertet.

Zielgruppe: Redaktion

Die Prüfung des Referenz-Index wurde ins Install-Tool verlagert, um dort zugänglicher zu sein für reguläre System-Administrationsaufgaben, und war vorher zu versteckt. Der Referenz-Index hat für neuere TYPO3-Versionen eine sehr hohe Bedeutung und muss aktuell gehalten werden.

Zielgruppe: Administration

FormEngine CSS wurde von Bootstrap col/row Klassen auf eigenes CSS-Grid umgestellt. Falls eigene Backend-CSS-Anpassungen diese internen (!) Klassen angesprochen haben, müssen Sie angepasst werden.

Zielgruppe: Integration

TCA-SQL-Felddefinitionen, die zwischen CHAR/BINARY und VARCHAR/VARBINARY unterschieden haben werden nun korrekt an die Datenbankschicht übertragen, statt wie früher in VAR... zwangskonvertiert zu werden.

Zielgruppe: Administration

Bei nutzung des GUID Datentypes (type=uuid) für PostgreSQL Instanzen ändert sich der native Datenbanktyp und kann bei bislang ungültig gespeicherten Datensätzen Fehler verursachen.

Sehr wichtigLogout-Handling wurde verändert.

Zielgruppe: Integration

Die Anpassung des Logout-Handlings erfordert Änderungen, falls das "Logout"-Template von EXT:felogin angepasst wurde. Dort müssen URI-Argumente verändert werden. Zudem wurde die Funktion entfernt, nach dem Logout einen URL-basierten Redirect durchzuführen.

Entfernung der Option exposeNonexistentUserInForgotPasswordDialog.

Zielgruppe: Integration

Für eine erhöhte Sicherheit ist diese Option nun nicht mehr aktivierbar, die dafür sorgte dass beim "Passwort vergessen" Login offenbart werden konnte ob es einen Account zu einer E-Mailadresse gibt oder nicht.

Sehr wichtigEntfernung der Standard-parseFunc.

Zielgruppe: Integration

Die standardmäßig ausgelieferte parseFunc (und parseFunc_RTE) TypoScript-Definition ist nun auf ein Minimum eingestellt. HTML-Parsing soll vor der Persistierung geschehen, so dass in der Frontend-Ausgabe nur minimale Modifikationen nötig sein sollten. Eigene Definitionen der parseFunc sind weiterhin möglich, lediglich wenn man sich bisher auf die EXT:fluid_styled_content Definition vorher verlassen hat, ist eine Überprüfung und eigenständige Anpassung nötig.

Mehrere alte Hooks in EXT:form wurden durch neue PSR-14 Events ersetzt.

Zielgruppe: Entwicklung

PSR-14 Events sind flexibler und leichtgewichtiger in der technischen Implementation als Hooks. Mehrere neue Events wurden zudem gezielt für EXT:form eingefügt, so dass individuelle Anpassungen besser möglich sind (siehe Features).

WissenswertMethode AbstractFinisher->getTypoScriptFrontendController entfernt.

Zielgruppe: Entwicklung

Die Methode des Finishers existiert nicht mehr, da das gesamte TSFE Objekt in TYPO3 14 entfernt wurde. Aufrufe in eigenen Finishern müssen entsprechend auf die Request-Attribute zurückgreifen.

WissenswertEntfernung der alten Form-Templates (prä-Bootstrap).

Zielgruppe: Integration

Die "version2" ist nun das einzige ausgelieferte Template.

WissenswertStrukturelle Veränderungen im Task-Planer: Konfiguration als TCA, keine serialisierten Objekte mehr.

Zielgruppe: Entwicklung

Der Scheduler wurde einer deutlichen Modernisierung unterzogen. Die früher problematische Speicherung der Tasks basierte auf serialisierten Objektdaten, die fehleranfällig waren. Nun sind die Tasks alle mit Formengine+TCA statt eigener Daten-Provider umgesetzt, speichern ihre Parameter in leicht auslesbaren JSON-Feldern, und nutzen auch ansonsten native Datenbankfelder für Parameter. Eine Datenbankmigration hierfür ist vorhanden. Alte Tasks können weiter laufen, aber eine Konvertierung zu "nativen Tasks" bringt alle TCA-Vorteile mit sich. Als Ausblick wird auch das Ausführen eines beliebigen Tasks mittels CLI möglich sein, ohne einen Task in ein Symfony Command konvertieren zu müssen. Die Option zur Einstellung von Scheduler-Task-Frequenzen (TYPO3_CONF_VARS.SC_OPTIONS.scheduler.frequencyOptions) wurde als Breaking Change in ein TCA Override überführt.

WissenswertDie Speicherung der Datenbankfelder für Planer-Tasks tx_scheduler_task nutzt nun nicht mehr serialisierte PHP-Objekte, sondern native JSON-Definitionen. Daher haben sich Feldtypen strukturell geändert.

Zielgruppe: Administration

WissenswertDas "Einfrieren" von Workspaces ist nun nicht mehr möglich.

Zielgruppe: Redaktion

Die Implementation hatte mehrere Fehler, so dass diese Funktionalität vorerst ersatzlos entfernt wurde, da die Nutzung in der Community nicht aktiv gewünscht wurde, und die Korrektur viel Zeit gekostet hätte.

Die Nutzung von "Extbase Annotations" (z.b. @Validate) ist nicht mehr möglich und muss durch PHP-Attribute (z.B. #[Validate()]) ersetzt werden.

Zielgruppe: Integration

Die bekannten "phpdoc" Annotationen wie @var und @param bleiben unangerührt, hier geht es um den Austausch durch "Annotationen" durch "PHP-Attribute" wodurch es für die Introspection sinnvoller nutzbar ist. Die alten Namespaces der Annotationen bleiben auch für 1:1 Ersetzung durch PHP-Attribute nutzbar, ansonsten sollte für sauberen Code der Namespace TYPO3\CMS\Extbase\Attribute nun genutzt werden.

Strenge PHP-Typisierung der Extbase Argument-Klasse.

Zielgruppe: Entwicklung

WissenswertVon Extbase-Plugins gesetzte HTTP Header können nun zentral ausgewertet werden (z.B. Set-Cookie Aufrufe) und als eigenständige Header ausgegeben werden (anstelle mit Komma verbunden). Dies kann Auswirkung auf etwaige bisherige Verarbeitung von Extbase-Plugins haben.

Zielgruppe: Entwicklung

Ein als nullable => true definiertes Feld wird in der Datenbank nun auch als DEFAULT NULL gespeichert. Falls Extbase-Models auf derartig definierte Datenbankspalten zugreifen muss darauf geachtet werden, dass die Modelle auch mit NULL Werten nun umgehen können.

Zielgruppe: Administration

Wissenswertds_pointerField für FlexForms entfernt / vereinfacht, FlexFormTools API-Aufruf angepasst.

Zielgruppe: Entwicklung

Die Definition von Flexforms hat sich in der TCA Syntax etwas verändert, so dass die "ds" Einträge nun direkt im pi_flexform TCA-Eintrag definiert werden, und via columnOverrides für andere pointer-Typen Felder definiert. Eine automatische TCA-Migration kann einfache Felddefinitionen dynamisch konvertieren, bei mehrfach-Einträgen muss dies jedoch manuell (oder z.B. via Rector) geschehen.
Eigene Aufrufe der FlexFormTools-Methoden müssen ggf. auch angepasst werden um die Schema-Parameter zu übermitteln.

Sehr wichtigFluid v5.

Zielgruppe: Integration

- Variablennamen dürfen nicht mehr mit einem Unterstrich ("_") beginnen!
- CDATA Sektionen in Templates werden nicht mehr entfernt (sondern interpretiert)
- render() Methoden-Deklarationen in Fluid ViewHelpern müssen nun strikte Typ-Deklarationen nutzen, vor allem für den Return-Type.
- Mehrere Variablen/Methoden im AbstractViewHelper und dem ViewHelperInterface wurden entfernt: $childNodes, setChildNodes.
- Namespaces werden nun nicht mehr vererbt (in Partials), sondern müssen immer einzeln pro Datei deklariert werden.
- Der CompileWithRenderStatic Trait wurde entfernt, alle ViewHelper müssen nun render() nutzen.
- "null" in Argumenten bei ViewHelper-Aufrufen, die den TagBuilder nutzen um HTML-Attribute zu setzen werden nun nicht mehr ausgegeben; leere Attribute müssen mit einem leeren String erzeugt werden, um nicht zu entfallen.
- Namespaces können nur noch mit URIs (die den Pfad zur PHP-Datei enthalten) und nicht mehr reinen PHP-Klassennamen definiert werden.
- Mehrere Änderungen im "TemplatePaths" Objekt (nur für Fluid-Parser-Erweiterungen relevant, unüblich)

WissenswertDer <f:form.password> ViewHelper gibt nun Inhalte von Passwort-Feldern nach Validierung nicht mehr im Klartext zurück.

Zielgruppe: Integration

Grundsätzlich sollten Passwörter nicht im Klartext ausgeliefert werden, und es ist gewohntes Verhalten auf Webseiten bei Fehlern das Passwort erneut eintragen zu müssen.

WissenswertAnpassung Frontend-Middlewares.

Zielgruppe: Entwicklung

Durch den Ausbau von TSFE/TypoScriptFrontendController wurden die Middlewares typo3/cms-frontend/tsfe und typo3/cms-frontend/prepare-tsfe-rendering zusammengeführt. Etwaige eigene Middlewaresortierung muss sicherstellen, dass die gewünschte Reihenfolge vor/nach dem Typoscript-Setup weiterhin besteht!

Mit unserem festangestellten Mitarbeiter Garvin Hicking unterstützen wir aktiv die TYPO3-Entwicklung. Er arbeitet im Core-Merger Team des OpenSource Projekts mit, und ist daher über die neuesten Entwicklungen bestens informiert. In unseren Artikelserien zu TYPO3-Releases beleuchtet er detailiert (und garantiert ohne KI-Automatik) wichtige Änderungen.

Garvin Hicking
Senior Developer

BITV Check - Wir prüfen Ihre Website oder Ihr digitales Produkt.

Wir setzen die Projekte unsere Kunden nicht nur BITV-konform um, wir prüfen auch Websites, Apps und digitale Produkte hinsichtlich der gesetzlichen Anforderungen. Buchen Sie unser 30-Minten-Erstgespräch - unverbindlich, klar und kompetent. Denn digitale Barriefreiheit ist Pflicht.