Extension Updates für TYPO3 v12 - TYPO3 Meetup München - 13.03.2023 # Extension Updates für TYPO3 v12 - TYPO3 Meetup München - 13.03.2023 > **Dieses Dokument ist im Rahmen einen User Group Meetings entstanden und darf gerne weiter ergänzt werden! > Dazu auf das Stift Symbol oben rechts klicken. > Es ist lediglich ein my.typo3.org Account erforderlich!** ## TYPO3 Core Changelogs Allgemeine (technische) Changelogs sind hier zu finden: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog-12.html ## What's new Slides Wird es für v12 nicht geben, da sich niemand gefunden hat, der das Thema übernimmt. https://typo3.slack.com/archives/C028JEPJL/p1662681371185159 ## PHP Upgrade - Vor dem Upgrade auf v12 schon PHP Upgraden (mind. PHP 8.1) ## Composer Installer auf v4rc umstellen - typo3conf/ext wird dann nicht mehr gebraucht - kann auch schon in v11 vorbereitend gemacht werden - erhöht die Sicherheit - ab v12 ist der Installer v5 Pflicht - Prüfen, ob man in Templates, etc. harte Pfade zu `typo3conf/ext/ext_key` verwendet - umstellen auf EXT:ext_key Notation - Migrationshilfe: https://brot.krue.ml/migration-typo3-composer-cms-installers-version-4/ ## Extbase PSR-7 Request / Response nutzen ## Rector - Aktuell gibt es noch nicht so viele Regeln für v12. - Alle Regeln, die noch geschrieben werden müssen, sind im Issue Tracker markiert: https://github.com/sabbelasichon/typo3-rector/issues?q=label%3A12.0%2C12.1%2C12.3%2C12 - Rector allgemein: https://github.com/rectorphp/rector ### Konstante `TYPO3_MODE` entfernen [`TYPO3_MODE` ist deprecated seit v11](https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.0/Deprecation-92947-DeprecateTYPO3_MODEAndTYPO3_REQUESTTYPEConstants.html) Das übernimmt an sich Rector, falls man aber Rector nicht nutzt, so muss man manuell folgendes bearbeiten, da sonst nach der Installation der Extension auf v12 gar nichts mehr geht: ```php <?php defined('TYPO3_MODE') || die(); // ← alter Code defined('TYPO3') || die(); // ← neuer Code ``` ## Deprecation Log - Deprecation Log von v11 durchschauen, was mit v12 entfernt werden soll. ## Warnings / Exceptions - SYS Exceptional Errors richtig konfigurieren - Warnungen und Notices sollten keine Exception werfen - https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Configuration/Typo3ConfVars/SYS.html#confval-GLOBALS-TYPO3_CONF_VARS-SYS-exceptionalErrors - Standardwert ist `4096` ## Dependency Injection - Mit v12 kommt man kaum mehr an der DI vorbei (reimt sich absichtlich) - Die Dependency Injection sollte verstanden werden, macht einiges leichter - https://usetypo3.com/dependency-injection.html - https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/DependencyInjection/Index.html - https://www.youtube.com/watch?v=jKFhz7Qv-88 ## Signal / Slot - müssen durch PSR-14 Events ersetzt werden - Quelle: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.0/Feature-88770-PSR-14BasedEventDispatcher.html - Dokumentation: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Events/EventDispatcher/Index.html ## Object Manager - Umstellen auf Symfony Dependency Injection https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/DependencyInjection/Index.html#using-di - `ObjectManager->get(MyClass::class)` umstellen auf `GeneralUtility::makeInstance(MyClass::class)` => sollte in vielen Fällen schon helfen Falls Klasse nicht gefunden werden kann, in Services.yaml die Klasse auf ``"public: true"`` setzen **Ergänzung** Nicht alle Klassen, die früher via `ObjectManager->get(MyClass::class)` erzeugt wurden, sind Services. Services sind in der Regel Klassen, die eine oder mehrere Aufgaben erfüllen und keinen State haben und daher auch nur in Form einer einzigen Instanz existieren (auch hier gibt es Ausnahmen). Man nennt diese auch `Singletons`, das DI-Framework nutzt stattdessen den Begriff `shared`. Klasse A und B, die Service X brauchen bekommen dann dieselbe Instanz. Dem gegenüber stehen Entities, Forms, DTOs etc. Objekte, die nicht injected werden, sondern zur Laufzeit mit einem bestimmten State (Eigenschaften-Werte) existieren. Diese Objekte lassen sich in der Regel an Ort und Stelle im Code auch alternativ mittels `new` erzeugen und haben selbst keine Abhängigkeiten. `makeInstance` wird für diese Objekte genutzt um XClassing zu erlauben, das DI-Framework spielt hier dann keine Rolle. Services KÖNNEN `public` gestellt werden, d.h. sie können dann direkt vom DI-Container erfragt werden. Der sauberere Weg ist allerdigs die tatsächliche Dependency Injection, d.h., dass ich den Service als Constructor-Argument angebe und das Framework sich darum kümmert, die Dependency korrekt aufzulösen und zu erzeugen. In dem Fall bleibt ein Service `private` und `makeInstance` wird nicht länger genutzt. Dies hat u.a. den Vorteil, dass der Code sauberer wird, da an einer zentralen Stelle (constructor) klar ist, welche Abhängigkeiten die Klasse hat. - https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.4/Deprecation-94619-ExtbaseObjectManager.html ## Icon API - Font Awesome Icons wurde entfernt: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-98089-RemovedFontAwesome.html - Falls noch nicht geschehen, sollten nun die eigenen registrierten Icons in die `EXT:my_extension/Configuration/Icons.php` ausgelagert werden. https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Icon/Index.html - Liste verfügbarer Icons mit Suchfunktion: https://typo3.github.io/TYPO3.Icons/ ## Switchable Controller Actions - entfällt mit v12 - Eine automatisierte Migration gibt es nicht. - SwitchableControllerActions kommen nicht nur in FlexForms vor, sondern manchmal auch in Ajax Calls. - Inspiration: EXT:news hat in Version 11.0.0 die Umstellung gemacht, inkl. Migrationsscript - https://www.derhansen.de/2021/03/migrate-switchablecontrolleractions.html - Link zur Deprecation: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.3/Deprecation-89463-SwitchableControllerActions.html - Die Grundidee der Plugins ist eigentlich, dass ein Plugin eine ganz bestimmte Funktion erfüllen sollte. Dem widersprechen die SwitchableControllerActions. Es wird in zukünftigen TYPO3-Versionen wohl so sein, dass ein Plugin nur einer einzigen Funktion dienen soll/darf und der CType “list” verschwinden wird. - Daher sollte idealerweise für jede Controller-Action ein eigenes Plugin / PageType gemacht werden. In der v12 ist es aber noch möglich, ein Plugin mit mehreren verschiedenen Controller Actions zu haben, es kann aber nur die erste über ExtensionUtility::configurePlugin() konfigurierte Action als Einstiegspunkt verwendet werden. ## Extbase Queries: logical And / OR logicalAnd und logicalOr akzeptieren kein Array von Constraints als Parameter, sondern nur noch Constraints, die aber quasi unendlich in der Anzahl (https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-96044-HardenMethodSignatureOfLogicalAndAndLogicalOr.html). Die Constraints kann man aber wie gewohnt in einem Array zusammenfügen und dann mit einem Spread-Operator an die Funktion übergeben: ```php <?php $query = $this->createQuery(); $constraints = [ $query->equals('propertyName1', 'value1'), $query->equals('propertyName2', 'value2'), $query->equals('propertyName3', 'value3'), ]; $query->matching($query->logicalAnd(...$constraints)); ``` ## Extbase Repositories Die magischen Methoden `findBy[Property]()`, `findOneBy[Property]()` und `countBy[Property]()` sind deprecated und KÖNNEN durch folgende Methoden ersetzt werden: ```diff <?php - $repository->findByPropertyName('propertyValue'); + $repository->findBy(['propertyName' => 'propertyValue']); - $repository->findOneByPropertyName('propertyValue'); + $repository->findOneBy(['propertyName' => 'propertyValue']); - $repository->countByPropertyName('propertyValue'); + $repository->count(['propertyName' => 'propertyValue']); ``` Der Vorteil der neuen Methoden ist, dass diese echte Methoden sind und mit type declarations versehen sind. Das bedeutet eine bessere Unterstützung für IDEs und tools wie phpstan. ```php <?php class Repository { public function findBy(array $criteria, array $orderBy = null, int $limit = null, int $offset = null): QueryResultInterface { // ... } public function findOneBy(array $criteria, array $orderBy = null): object|null { // ... } public function count(array $criteria): int { // ... } } ``` ## Extbase Redirect / Forward - Betrifft die Extbase-Methoden ```php <?php namespace TYPO3\CMS\Extbase\Mvc\Controller; abstract class ActionController implements ControllerInterface { public function redirect($actionName, $controllerName = NULL, $extensionName = NULL, array $arguments = NULL, $pageUid = NULL, $delay = 0, $statusCode = 303) { //... } public function redirectToURI($uri, $delay = 0, $statusCode = 303) { //... } public function forward($actionName, $controllerName = NULL, $extensionName = NULL, array $arguments = NULL) { //... } } ``` da Extbase-Actions seit https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.0/Deprecation-92784-ExtbaseControllerActionsMustReturnResponseInterface.html ein ResponseInterface zurückgeben müssen. Ein Redirect, egal ob es zu einer URL oder einer anderen Action geht, muss nun mit einem eigenen Response erstellt werden und zwar in der Form ```php <?php namespace Vendor\Extension\Controller; use Psr\Http\Message\ResponseInterface; use TYPO3\CMS\Extbase\Mvc\Controller\ActionController; class StartController extends ActionController { public function redirectToUriAction(): ResponseInterface { /* ... */ $uri = $this->uriBuilder->uriFor('show', ['parameter' => $value]); return $this->responseFactory->createResponse(307) ->withHeader('Location', $uri); } } ``` Ein Forward wird folgendermaßen erstellt ```php <?php namespace Vendor\Extension\Controller; use Psr\Http\Message\ResponseInterface; use TYPO3\CMS\Extbase\Http\ForwardResponse; use TYPO3\CMS\Extbase\Mvc\Controller\ActionController; class StartController extends ActionController { public function forwardAction(): ResponseInterface { /* ... */ return (new ForwardResponse('list')) ->withExtensionName('anotherextension') ->withControllerName('AnotherController') ->withArguments(['parameter' => $value]); } } ``` ## Default Models in Extbase entfallen Link zur Deprecation: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.4/Deprecation-94654-GenericExtbaseDomainClasses.html z.B. - BackendUser und - Group stehen nicht mehr zur Verfügung - FrontendUser und -Group stehen nicht mehr zur Verfügung - Diese Models und Repositories müssen jetzt selbst zur Verfügung gestellt werden - Lösung: Klassen und Mapping mit den benötigten Eigenschaften aus dem Core in die eigene Extension kopieren. Anpassungen in der DB sind i.d.R. nicht notwendig ## Query Generator Methode “getTreeList” entfällt - getTreeList war eine Funktion, die es erlaubt alle Seiten-UIDs eines Teilseitenbaums als komma-separtierte Liste zu bekommen. - Lösung: Copy und Paste der alten Funktion in eine eigene Funktion kopieren - https://www.in2code.de/aktuelles/liste-aller-unterseiten-in-php-erhalten-oder-alternative-zu-querygenerator-gettreelist/ ## ViewHelper - alle ViewHelper im Core sind final, können somit nicht mehr erweitert werden - stattdessen: kopieren und dann erweitern - Logik zwischen Extbase und nicht-Extbase wurde getrennt - `f:translate`-Viewhelper benötigt im non-Extbase-Kontext nun explizit den "extensionName" als Attribut (falls nicht der komplette Pfad via LLL:EXT:... angegeben ist) - `f:form`-Viewhelper können nun nur noch im Extbase-Kontext verwendet werden, Alternative: `form`-Tag von HTML nutzen ## Extbase Validatoren - sind in v12 auch final - kopieren und dann erweitern ## FrontendUser und FrontendUsergroup - Die Models für den User und die Usergroup (Frontend und Backend) und die zugehörigen Repositories wurden entfernt - Statt überschreiben muss man die Attribute alle selbst setzen (wie E-Mail, Name, etc.) - Vorteil: Man hat nur die Attribute, die man braucht - Nachteil: Man muss einmal anfassen ## Frontend Controller (TSFE) per DI injecten - geht mit v12 nicht mehr - Request Attribut "frontend.controller" verwenden (gibts seit v11): https://docs.typo3.org/m/typo3/reference-coreapi/11.5/en-us/ApiOverview/RequestLifeCycle/RequestAttributes/FrontendController.html - wenn nicht, Fallback auf die Globale Variable ## CKEditor - wurde auf Version 5 umgestellt - Plugins müssen erneuert werden - https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Feature-96874-CKEditor5.html - https://ckeditor.com/docs/ckeditor5/latest/installation/getting-started/migration-from-ckeditor-4.html#plugins ## Backend Module - Breaking: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-96733-RemovedSupportForModuleHandlingBasedOnTBE_MODULES.html - https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Feature-96733-NewBackendModuleRegistrationAPI.html - Module Template API vereinfacht: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Feature-96730-SimplifiedExtbackendModuleTemplateAPI.html ## Backend JavaScript - RequireJS wird in v13 entfernt. Man sollte schon jetzt zu ES6 migrieren - https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Backend/JavaScript/ES6/Index.html#requirejs-migration ## Backend Konfiguration - in v10 wurde eingeführt: Fluid-based replacement for PageLayoutView - https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.3/Feature-90348-NewFluid-basedReplacementForPageLayoutView.html - mit v12 ist das jetzt anders: Override backend templates with TSconfig - https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Feature-96812-OverrideBackendTemplatesWithTSconfig.html - Vorsicht: Backend-Templates aus dem Core sind nicht API und können sich daher auch in Bugfix-Releases ändern ## TCA Typen - es gibt diverse neue TCA Typen, z.B. für Dateien, datetime, color, etc. - werden automatisch migriert - Upgrade Modul => Check TCA Migrations prüfen - wird on the fly in die neue Syntax umgeschrieben - Extension, um TCA leichter zu konfigurieren - https://extensions.typo3.org/extension/tcabuilder ## TypoScript Parser wurde neu geschrieben - ist jetzt schneller, aber dafür strikter - alte Ungenauigkeiten im TypoScript funktionieren damit nicht mehr https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-97816-TypoScriptSyntaxChanges.html https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-97816-NewTypoScriptParserInFrontend.html - Achtung bei Linebreaks mit `\r` ## pibase Extensions - Abstract Plugin ist jetzt internal https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-98281-MakeAbstractPluginInternal.html ## Testing Framework - Nimut Testing Framework gibt es für v12 nicht ⇒ umschreiben auf Core Testing Framework - https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Testing/ExtensionTesting.html ## Livesearch - Extension an die überarbeitete Livesearch anbinden - https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Feature-93494-NewPSR-14ModifyQueryForLiveSearchEvent.html - https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.2/Feature-99220-AddEventToModifySearchResults.html - https://www.ayacoo.de/typo3-backend-livesearch-basics-besipiele.html ## TYPO3 Upgrades im Allgemeinen - Extensions prüfen, ob sie überhaupt noch gebraucht werden oder ob es ggf. Core Funktionen dafür gibt - alles schon tun, was man vor dem TYPO3 Upgrade machen kann - Upgrade scripten: https://github.com/ElementareTeilchen/upgrader - Migration GridElements ⇒ Container: - https://codeblog.at/migration-von-gridelements-zu-container/ - https://extensions.typo3.org/extension/gridtocontainer