Neue CLI-Befehle und bessere Automatisierung für Continuous Integration

Die Datei PackageStates.php ist nun Geschichte, zumindest für Composer-basierte TYPO3-Installationen. TYPO3 selbst wird mit Extensions gebaut und der TYPO3-Core wird ab TYPO3 v11 mit 36 Systemerweiterungen ausgeliefert. Über Composer kannst du also die Extensions anfordern und laden, die du für deine Website wirklich brauchst. Wenn du zum Beispiel die „indexierte Suche“ von TYPO3 nicht brauchst, weil du die Solr-Erweiterung verwendest, ist deine Codebasis viel kleiner. Weniger Code ist immer eine gute Sache für die Wartbarkeit und Sicherheit. 

Bei Erweiterungen, die nicht zum System gehören, hat TYPO3 schon immer den Ordner typo3conf/ext/ auf Erweiterungen von Drittanbietern überprüft. Diejenigen, die „aktiv“ sind (das wird von TYPO3s internem Konfigurationsmanagement erkannt), werden in der Datei PackageStates.php aufgeführt. In der Vergangenheit haben wir die großartige TYPO3 Console-Erweiterung von Helmut Hummel verwendet, um die Datei PackageStates.php bei jedem Composer-Befehl als eigenes Skript zu erstellen.

In TYPO3 v11 sind alle erforderlichen Erweiterungen des TYPO3-Core und die Erweiterungen von Drittanbietern, die in der composer.json definiert sind, immer aktiv. Das ist ein praktischer Weg, um sich den nativen Konzepten von Composer anzunähern: Wenn du ein Paket benötigst, ist es aktiv. Wenn du es nicht brauchst, entfernst du es einfach über Composer. 

Wenn du auf TYPO3 Version 11 aktualisierst, wird die PackageStates-Datei nie wieder im Composer-Mode ausgewertet. Wenn du so bereits mit Composer gearbeitet hast, dass alle benötigten Erweiterungen jederzeit aktiv sind, dann bist du bereits hervorragend auf TYPO3 v11 vorbereitet.

Wenn du eine Extension zum ersten Mal in TYPO3 über den Extension Manager aktivierst, passieren unter der Haube noch ein paar andere Sachen: Erforderliche Datenbanktabellen werden erstellt oder erweitert, die Caches von TYPO3 werden geleert und wenn es entsprechend konfiguriert ist, werden auch einige Datenbankimporte durchgeführt.

Dies kann nun mit dem neuen CLI-Befehl extension:setup ausgeführt werden, der auf dem Zielsystem (z.B. der Produktions- oder Staging-Umgebung) über vendor/bin/typo3 extension:setup ausgeführt werden sollte. Das ist wichtig, um sicherzustellen, dass die tatsächliche Datenbankverbindung verwendet wird und nicht eine Testdatenbank. Das mehrfache Ausführen des Befehls, z.B. bei jedem Deployment, ist für TYPO3 v11 kein Problem.

Helmut Hummels TYPO3 Console-Erweiterung, die in den letzten 7 Jahren Pionierarbeit für die CLI-Funktionalität von TYPO3 geleistet hat, verfügte fast von Anfang an über den wichtigen Befehl cache:flush. Dieser Befehl ist besonders wichtig, wenn ein Deployment in der Produktionsumgebung stattgefunden hat, um sicherzustellen, dass die neue Konfiguration geladen wird. In TYPO3 v11 wird der Befehl cache:flush direkt mitgeliefert, mit der Möglichkeit, auch nur die Caches einer bestimmten Cache-Gruppe zu flushen, z. B. die system-related Caches.

Nachdem die Caches geflusht wurden, dauert der nächste Aufruf im TYPO3-Backend oder -Frontend eine Weile, um die Caches wie den Dependency-Injection-Cache oder den Rootline-Cache neu zu erstellen. In den letzten Versionen wurde das Cache-Handling-System von TYPO3 so weit verbessert, dass TYPO3 v11 jetzt direkt mit einem cache:warmup ausgeliefert wird, das automatisch die Konfiguration aller Erweiterungen lädt und der nächste Zugriff auf den Browser sofort wieder schnell stattfinden kann. Und deine Redakteure werden nicht einmal bemerken, dass ein Deployment stattgefunden hat.

Beide Befehle sind dafür gedacht, auf dem Zielsystem — direkt nach einem Deployment — und nicht auf einem CI-Server verwendet zu werden.