VHS für TYPO3

EXT:vhs ist der unsichtbare Werkzeugkasten jedes professionellen TYPO3-Templates

Wer in TYPO3 mit Fluid arbeitet und über das reine Ausgeben von Inhalten hinausgeht, landet früher oder später bei EXT:vhs. Die Extension aus dem FluidTYPO3-Ökosystem liefert mehrere hundert zusätzliche ViewHelper für Aufgaben, die der Core bewusst nicht abdeckt: Bild-Manipulation, Iterator-Logik, Math-Operationen, String-Handling, Content-Abfragen, Page-Navigation. Für Frontend-Entwicklerinnen in Agenturen und Inhouse-Teams ist vhs kein optionales Nice-to-have, sondern die Basis, auf der komplexe Template-Strukturen ohne PHP-Umwege entstehen.

Die Zielgruppe sind typischerweise Teams, die aufwendige Site Packages pflegen: Verlage mit heterogenen Content-Typen, Hochschulen mit verschachtelten Navigationen, Konzerne mit mehrsprachigen Portalen. Ohne vhs müsste jede zweite Sonderanforderung in einen eigenen ViewHelper oder in TypoScript ausgelagert werden. Mit vhs bleibt die Logik dort, wo sie hingehört: im Template.

Typische Einsatzszenarien

Ein erstes Szenario ist die Content-Abfrage aus fremden Seitenbäumen. Ein Kundenportal eines Maschinenbauers mit 3.000 Produktseiten benötigt auf jeder Seite einen Teaser-Block mit aktuellen News aus einem separaten News-Rootline-Zweig. Der ViewHelper v:content.get holt Inhalte aus beliebigen Seiten und ermöglicht so modulare Seitenkompositionen, ohne TypoScript-CONTENT-Objekte bauen zu müssen.

Ein zweites Szenario ist die Iterator-Verarbeitung. Ein Verlagshaus pflegt Artikel mit Kategorien, Tags und Autoren als ObjectStorage. In Fluid allein sind Filterungen, Gruppierungen und Sortierungen über verschachtelte Objekte umständlich. Mit v:iterator.filter, v:iterator.sort oder v:iterator.groupBy lassen sich solche Operationen direkt im Template lesen und warten.

Ein drittes Szenario ist die Image-Verarbeitung. Ein E-Commerce-Shop mit 500 Produkten pro Saison braucht responsive Bildvarianten mit picture-Tag, WebP-Fallback und LQIP-Platzhalter. Mit vhs-Media-ViewHelpern wird dieser Block einmal im Partial definiert und anschliessend überall wiederverwendet.

Ein viertes Szenario ist die mathematische Aufbereitung von Kennzahlen in Reporting-Seiten. Wer Preise mit Zwischensummen, Prozentanteilen oder gewichteten Mittelwerten ausgeben will, greift auf v:math.sum, v:math.percentage oder v:math.division zurück, ohne für jede Berechnung einen eigenen Controller bauen zu müssen.

Technische Architektur

EXT:vhs ist eine reine Library-Extension ohne Backend-Module und ohne Datenbank-Tabellen. Sie registriert Namespaces in Fluid ({namespace v=FluidTYPO3\Vhs\ViewHelpers}) und stellt damit die ViewHelper über den Präfix v: zur Verfügung. Die Extension hat keine harten Abhängigkeiten zum restlichen FluidTYPO3-Stack (Flux, Fluidcontent), auch wenn sie oft gemeinsam mit diesen eingesetzt wird.

Die Installation erfolgt über Composer mit fluidtypo3/vhs. In einem Site Package wird vhs üblicherweise als Dependency der eigenen Provider-Extension geführt, sodass die Namespace-Registrierung im Layout-Template oder global über das TypoScript-Konfigurationsarray erfolgt. Wer die Namespaces in jedem Template einzeln deklarieren muss, hat meistens den globalen Registrierungs-Pfad übersehen.

Für die Performance relevant ist, dass vhs keine eigenen Datenbankabfragen cached. Wer v:content.get oder v:page.menu ohne Fluid-Caching einsetzt, erzeugt im schlimmsten Fall dieselbe Abfrage bei jedem Seitenaufruf. Die Lösung liegt in sauber konfiguriertem Fluid-Caching über Page- und Content-Cache sowie der bewussten Nutzung des CacheStatic-Mechanismus im TYPO3-Core.

Das Extension-Paket ist modular aufgebaut. Einzelne ViewHelper-Gruppen (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) können gezielt eingesetzt werden, ohne dass der gesamte Stack ins Projekt kommt. In der Praxis wird jedoch die ganze Sammlung installiert, weil die Abhängigkeiten zwischen den Gruppen schwer zu kapseln sind und der Footprint der Extension insgesamt vertretbar bleibt.

Häufige Probleme und Lösungen

Das erste Problem ist die berüchtigte Namespace-Kollision. Wer EXT:vhs parallel zu eigenen ViewHelpern unter dem Präfix v: einsetzt, bekommt unvorhersehbare Überlagerungen. Die Lösung ist, eigene ViewHelper konsequent unter einem eigenen Präfix (z.B. my:) zu registrieren und vhs-Aufrufe auf Core-ViewHelper umzustellen, wo der TYPO3-Core inzwischen eine Alternative bietet (f:format.padding ersetzt v:format.padding).

Das zweite Problem ist die Versions-Kompatibilität mit neueren Fluid-Versionen. In TYPO3 v12 und v13 wurde Fluid mehrfach überarbeitet, was bei einigen vhs-ViewHelpern zu Deprecation-Warnings oder Typfehlern führt. Die Lösung ist ein Audit der eingesetzten ViewHelper gegen die Compatibility-Matrix im GitHub-Repository und der selektive Ersatz durch Core-Alternativen oder eigene, schlanke Implementierungen.

Das dritte Problem ist Performance unter Last. v:iterator.filter und v:iterator.sort sind bequem, aber rechenintensiv bei grossen Datenmengen. Wer ein Template mit 10.000 Produkten pro Seite rendert, sollte die Filterlogik in das Repository verschieben und nur das bereits gefilterte Ergebnis an das Template übergeben.

Ein viertes, oft übersehenes Problem sind undokumentierte Verhaltensänderungen zwischen vhs-Versionen. Ein ViewHelper, der in Version 6.x einen String zurückgab, liefert in Version 7.x plötzlich ein Array oder umgekehrt. Die Lösung ist, die vhs-Version im Composer-Lock-File zu fixieren und bei jedem Upgrade das Changelog sorgfältig gegen den eigenen Template-Bestand zu prüfen - idealerweise mit einem Lint-Schritt in der CI-Pipeline, der unbekannte ViewHelper-Signaturen sofort meldet.

Migration und Versions-Kompatibilität

EXT:vhs ist offiziell für TYPO3 v11 und v12 freigegeben. Für v13 existiert ein Entwicklungszweig, der aktiv gepflegt wird, aber noch nicht in allen ViewHelpern produktionsreif ist. Teams, die aktuell ein Upgrade von v11 auf v12 planen, können vhs in der Regel ohne grössere Eingriffe mitnehmen. Der Upgrade-Pfad zu v13 ist für Template-intensive Projekte der kritische Punkt: Hier lohnt ein Kosten-Nutzen-Vergleich zwischen dem Beibehalten von vhs und dem schrittweisen Umbau auf Core-Fluid plus eigene ViewHelper.

Die strategische Antwort hängt vom Ausmass der vhs-Nutzung ab. Projekte, die nur eine Handvoll vhs-ViewHelper einsetzen, sollten diese beim nächsten Upgrade gezielt durch Core-Konstrukte oder projektspezifische ViewHelper ersetzen. Projekte mit hunderten vhs-Aufrufen quer durch alle Templates profitieren hingegen davon, vhs weiterzuführen und bei jedem Upgrade einen gezielten Kompatibilitätstest zu fahren. Der Ersatz lohnt sich nur dort, wo die Altlast die Wartung stärker belastet als ein kontrolliertes Mitführen.

Gosign begleitet TYPO3-Upgrades mit vhs-Altlast und entscheidet gemeinsam mit dem Team, welche vhs-ViewHelper durch Core-Konstrukte ersetzt werden und welche als schlanke Projekt-ViewHelper neu entstehen. Damit bleibt das Template-Erbe wartbar, ohne dass man sich für weitere Jahre an einen externen Library-Stack bindet.