Extbase, das neue System für die Entwicklung von Extensions, das die einfache Migration zu FLOW3 und TYPO3 Version 5 ermöglichen soll, sowie die Template-Engine Fluid wurden auf den neuesten Stand gebracht. Sie nähern sich damit dem Status, den diese Technologien in FLOW3 haben, an. FLOW3 wurde bereits am 20. Oktober als Version 1.0 veröffentlich.

So wurde etwa der Property Mapper aus FLOW3 nach Extbase rück-portiert. Ebenso das Signal-Slot-System, das die sogenannten Hooks ersetzen soll, mit denen Entwickler in den Programmablauf eingreifen können, ohne dabei den Quellcode an sich zu verändern. Diese Anpassungen machen es entsprechend möglich, die Technologien für kommende Versionen auszuprobieren und die eigenen Extensions bereits auf einen Umzug zu TYPO3 5 vorzubereiten.

Sowohl das Backend, also der Administrations-Bereich, als auch das Frontend – die ausgelieferte Website – wurden zum Teil erheblich beschleunigt. So wurden im Backend alle benötigten JavaScript-Dateien zu einer Datei zusammengefasst, was die Anzahl der Requests auf bis zu ein Drittel verringert. Auf die Nutzung der JSmin-Bibliothek wurde hingegen aus Gründen der Performance verzichtet; das führt zwar zu minimal größeren JavaScript-Dateien, erhöht jedoch die Reaktionsgeschwindigkeit im Backend deutlich. Im Frontend ist nun sowohl eine „Minifizierung“ (entfernte Leerzeichen, verkürzte Variablen-Namen etc.) als auch ein Zusammenfassen aller Dateien zu einer möglich. Auch die Auslieferung gzip-komprimierter JavaScript- und CSS-Dateien ist nun möglich.

Eine der umfangreichsten Änderungen betrifft die Einführung des „XML Localization Interchange File Format“ (XLIFF), das fortan in TYPO3 und FLOW3 als standardisierte Form für Übersetzungen verwendet wird. Damit einher ging auch die Einführung eines neuen Translation-Servers [1], der nicht nur Übersetzungsteams mehr Komfort bietet, sondern auch Verbesserungsvorschläge annimmt.

Der neue Translation-Server ist komfortabler als sein Vorgänger und offen für Verbesserungsvorschläge.

Wurden bis dato lediglich Funktionen des alten, TYPO3-eigenen LLXML-Formats in das neue XLIFF-Konzept übernommen, so werden mit zukünftigen Versionen weitere Vorteile des Formats ausgeschöpft – Plural-Formen etwa. Bereits jetzt ist es möglich, sogenannte Fallback-Sprachen zu definieren, etwa Standarddeutsch (de_DE) für Schweizerdeutsch (de_CH). Diese greifen, sofern Teile nicht direkt übersetzt wurden.

Mit der Extension „extdeveval“ können Entwickler ihre Übersetzungen nach XLIFF konvertieren, die Nutzung von LLXML ist jedoch auch weiterhin möglich. Tiefere Einblicke in das Thema gibt Release-Manager Xavier Perseguers in einem Blogartikel [2].

Während mit TYPO3 4.5 als Long-Term-Support-Release (LTS) nicht nur mindestens drei Jahre Wartungszeitraum geboten, sondern auch großer Wert auf Abwärts-Kompatibilität gelegt wurde, bot sich Version 4.6 nun für größere Aufräumarbeiten an. Bestandteil der TYPO3-Philosophie ist es seit jeher, eine stabile API zu gewährleisten; Funktionen werden zunächst also mindestens zwei Versionen als „deprecated“ (veraltet) gekennzeichnet und mitgeführt, bis sie endgültig aus der API verschwinden. Dieses Entfernen fand nun tatsächlich zum ersten Mal statt.

Entsprechend ist es ratsam, nach einem Update die Liste der veralteten Funktionen zu kontrollieren, um nicht Gefahr zu laufen, Fehler des Typs „Call to undefined function“ zu erhalten. Das „deprecation log“ findet sich im Verzeichnis „typo3conf“, sofern dem man es im Install-Tool aktiviert hat.

Schließlich wurden auch die Anforderungen an die Systemumgebung angehoben. Zu den neuen Voraussetzungen zählen unter anderem:

• PHP 5.3
• PHP-Option „safe_mode“ wird nicht mehr unterstützt
• Bildbearbeitung ist nur noch mit GraphicsMagick sowie ImageMagick 6 möglich
• Unterstützung für den Internet Explorer 6 im Backend wurde eingestellt

Wer aufgrund einer oder mehrerer dieser Erfordernisse kein Update auf die neue Version durchführen kann, muss dennoch nicht beunruhigt sein. Der Zeitpunkt des Bruchs mit der Abwärts-Kompatibilität wurde bewusst gewählt, denn Version 4.5 LTS gewährleistet für alle, die nicht aktualisieren können oder wollen, langfristig eine stabile Basis [3].

Bereits mit TYPO3 4.3 wurde eine alternative Cache-Lösung implementiert und parallel zum bisherigen Caching entwickelt. Das neue Caching-Framework hat seine Wurzeln in FLOW3 und konnte durch die frühe Adaption in TYPO3 im Produktiv-Einsatz auf Herz und Nieren getestet werden. Entsprechend gab es seit der Einbindung einen regen Austausch zwischen TYPO3 und FLOW3.

Während zentrale Erweiterungen wie Extbase das Caching-Framework bereits seit längerer Zeit einsetzen, wurden die Caches des TYPO3-Kerns bisher in der Standard-Konfiguration mit der alten Cache-Lösung betrieben. Für die neue Version wurden nun Teile des alten Cachings entfernt und das neue Framework verpflichtend als zentraler Bestandteil aktiviert.

Die Suche im Backend sucht fortan tiefer als vier Ebenen.

Das Framework wird bei einem Zugriff sehr früh hochgefahren und kann so bereits für den Autoloader genutzt werden. Das verringert die Anzahl der benötigten Dateizugriffe, wenn viele Erweiterungen innerhalb einer TYPO3-Instanz geladen werden.

Überhaupt verbessert das neue Caching die Performance, insbesondere bei großen TYPO3-Installationen. So können etwa bei sehr vielen Seiten die Datenbank-Tabellen der Seiten-Caches sehr groß werden. Das Caching-Framework bietet dann die Möglichkeit, Daten vor der Ablage in der Datenbank zu komprimieren. Reicht das normale Caching von Daten nicht mehr aus, unterstützen Katalysatoren wie der PHP-Beschleuniger APC (bei kleinen Datenmengen, die direkt im Speicher des Servers liegen) oder die NoSQL-Datenbanken memcache und redis (für Daten, die sowohl in der großen Masse als auch im Einzelzugriff performant zur Verfügung stehen müssen) das Framework. Alle Caches sind dabei stets granular steuerbar.

Für Programmierer bietet das Caching-Framework mit TYPO3 4.6 eine deutlich vereinfachte API samt guter Dokumentation [4]. Die Definition, Einbindung und Benutzung eigener Caches ist dabei mehr oder weniger trivial. Als gute Studienobjekte für eigene Cache-Implementierungen bieten sich Extbase oder die XLIFF-Lokalisierung an. Weiterführende Erweiterungen wie „enetcache“ dienen zudem als einfache Schnittstelle, um Caching in eigenen Frontend-Erweiterungen zu realisieren.

Einer verstärkten Usability geschuldet sind neue Schieberegler im Backend, die nicht nur numerische Eingaben erleichtern sollen.

Die Ablage und der schnelle Zugriff auf Daten ist bei Caches die eine Sache. Viel komplexer ist jedoch das gezielte Löschen von Caching-Einträgen, wenn sich die darin benutzten Daten ändern; der Klick auf „Clear all Cache“, wenn das Frontend die gerade getätigten Änderungen nicht anzeigt, ist bekannt. Aktuelle Lösungen wie die TypoScript-Option „clearCacheCmd“ sind Krücken und können bei stark belasteten Installationen durch das Löschen zu vieler Einträge im Zweifel einen ganzen Server in die Knie zwingen.

Die gezielte Entwertung von einzelnen Cache-Einträgen, die sogenannte Invalidierung, ist deshalb zentraler Bestandteil des Caching-Frameworks. Sie soll dazu beitragen, dass es künftig unnötig ist, sämtliche Caches auf einmal zu leeren. Praktischer Anwendungsfall ist eine News-Extension, die beim Editieren einzelner Meldungen nur diejenigen Cache-Einträge betroffener Listen- und Detail-Seiten löscht, in denen die jeweilige Nachricht vorkommt. Für TYPO3 4.7 ist damit auch die Grundlage geschaffen, neue Möglichkeiten der Cache-Invalidierung sinnvoll einzusetzen, um Integratoren und Anwendern das Leben zu erleichtern.

Bisher war es unmöglich, Inhalte genauer als auf einen Tag freizuschalten oder offline zu nehmen. Die Start- und Stopp-Zeiten konnten aufgrund von Einschränkungen beim Frontend-Rendering, das die Gültigkeit des zugehörigen Cache-Eintrags bestimmt, nicht genauer definiert werden. Dem Rendering fehlte schlicht die Information darüber, welche der gezeigten Inhalte zuerst ihren Start- oder Stopp-Zeitpunkt erreichen.

Durch umfangreiche Veränderungen werden nun automatisch Gültigkeitszeiten von Seiten und statischen Inhalten (tt_content) einbezogen. Für Plugins (etwa bei News-Artikeln) muss eine TypoScript-Konfiguration erfolgen, die angibt, aus welcher Quelle die auf dieser Seite dargestellten Inhalte stammen. Stellt also eine Seite mit der ID 10 News-Artikel aus der Tabelle „news“ aus einem Ordner mit der ID 33 dar, so lautet das notwendige TypoScript-Setup wiefolgt:

config.cache.10 = news:33

Diese manuelle Konfiguration ist erforderlich, da TYPO3 während des Rendering-Prozesses keine Informationen von Plugins bekommt, wie lange deren Aktualität gewährleistet ist.

Die auffälligste der neuen Komponenten in TYPO3 4.6 ist der neue, Ext-JS-basierte Form-Wizard. Er entstand aus der System-Extension des „Form Projects“ und erlaubt es, Formulare im Backend per Drag & Drop zu erstellen. Eine WYSIWYG-Ansicht vereinfacht die Arbeit für Redakteure dabei zusätzlich. Auch kann man pro Feld Regeln zur Validierung vorgeben, zum Beispiel für E-Mail-Adressen oder alphanumerische Werte.

Redakteure können auf diese Art auch komplexe Formulare erstellen, was in früheren Versionen mehr Arbeit oder ein Ausweichen auf Extensions nötig machte. Der Administrator des Systems kann dabei über User-TSConfig und Page-TSConfig vorgeben, welche Elemente verwendet werden dürfen. Auch ein Standard-Formular, das beim Erstellen erscheint, lässt sich so definieren. Über ein TypoScript-FORM-Objekt, das ein Formular repräsentiert, lassen sich auch dynamische Formulare im Frontend realisieren, die etwa per TypoScript-Bedingung zur Laufzeit angepasst werden.

Der neue Form-Wizard erlaubt das Hinzufügen von Regeln zur Validierung einzelner Eingabefelder per Drag & Drop.

Standardmäßig aktiviert sind die bereits seit Version 4.3 enthaltenen System-Erweiterungen „rsaauth“ und „saltedpasswords“. Während erstere die verschlüsselte Übertragung von Passwörtern sichert, generiert letztere MD5-Hash-Werte aus den Passwörtern und sichert diese zusätzlich ab, bevor sie in der Datenbank landen. Denn anstatt der standardmäßigen MD5-Kodierung bei Backend-Benutzern und der Klartext-Speicherung bei Frontend-Nutzern werden Passwörter durch eine zufällige Komponente (das sogenannte Salt) vor dem Nachschlagen in Rainbow-Tables geschützt. Die Kenntnis eines Hash-Werts reicht dann nicht mehr aus, um auf das Passwort des Benutzers schließen zu können.

Bei der Aktualisierung von TYPO3 wird diese Funktion allerdings nicht automatisch aktiviert. Das sollte aber durch die explizite Installation der beiden Erweiterungen unbedingt manuell erfolgen.

Entgegen eines weit verbreiteten Missverständnisses hat eine Änderung des „Encryption Keys“ im Install-Tool keine negative Auswirkung auf die gespeicherten Passwörter. Der Schlüssel wird bei der Kodierung von Passwörtern nämlich nicht mit einbezogen, vielmehr ist das Salt im Passwort-Hash enthalten [5].

Ein Update auf Version 4.6 lohnt in jedem Fall. Einzig wer aufgrund von diversen Einschränkungen beim Server oder verwendeten Extensions auf 4.5 angewiesen ist, hat mit dem Long-Term-Support noch eine Weile Spielraum.

Für alle anderen und auch für Einsteiger, die das CMS evaluieren wollen, bietet die neue Version viel Komfort, neue Funktionen und ein hübsches Äußeres. Wer sich bisher scheute, TYPO3 auszuprobieren, bekommt mit der 4.6 ein leistungsstarkes System an die Hand.

Die nächste TYPO3-Version (4.7) ist für das Frühjahr 2012 geplant und wird an substanziellen Neuerungen vor allem das Thema Barrierefreiheit (BITV-Kompatibilität) im Frontend angehen. Realisiert wird dies übrigens mit Mitteln der Bundesanstalt für Landwirtschaft und Ernährung.