VHS Development für TYPO3

Warum die VHS Development-Version für TYPO3-Agenturen ein zweischneidiges Schwert ist

VHS (ViewHelpers Supplementary) ist mit über 300 ViewHelpers die umfangreichste Fluid-Erweiterung für TYPO3. Die Development-Version liefert neue ViewHelper und Bugfixes, bevor sie in einen stabilen Release fliessen. Für Entwickler, die an aktuellen Projekten arbeiten und auf eine bestimmte Bugfix oder ein neues Feature warten, ist das ein Vorteil. Für Produktiv-Websites ist es ein Risiko: Development-Versionen sind nicht vollständig getestet und können sich zwischen Commits inkompatibel ändern.

Die Entscheidung, ob VHS Development im Projekt eingesetzt wird, ist deshalb keine technische, sondern eine organisatorische: Hat das Team die Kapazität, Änderungen an der Library zeitnah zu testen und zu reagieren, wenn etwas bricht? Und ist die organisatorische Disziplin vorhanden, die Development-Version vor dem Go-Live wieder durch einen Stable-Release zu ersetzen?

Typische Einsatzszenarien

Bugfix-Zugriff vor dem nächsten Stable-Release. Ein Projekt nutzt den VHS ViewHelper v:format.trim, der in der stabilen Version einen Bug hat - Whitespace in Multiline-Strings wird nicht korrekt behandelt. Der Fix existiert bereits im Development-Branch, aber der nächste Stable-Release ist erst in 4 Wochen geplant. Das Team wechselt temporär auf VHS Development, um den Bugfix sofort zu nutzen, und kehrt nach dem Stable-Release zurück.

Evaluierung neuer ViewHelper für ein Relaunch-Projekt. Ein TYPO3-Relaunch beginnt in 3 Monaten. Das Entwicklerteam evaluiert, ob neue VHS-ViewHelper (z.B. für responsive Image-Handling oder JSON-LD-Ausgabe) den Template-Code vereinfachen können. Die Development-Version wird in einer lokalen Entwicklungsumgebung installiert, getestet und die Ergebnisse fliessen in die Architekturentscheidung ein. Falls ein neuer ViewHelper im Stable-Release noch fehlt, kann das Team rechtzeitig eine eigene Implementierung als Fallback planen.

Beitrag zur VHS-Entwicklung. Agenturen, die eigene ViewHelper zu VHS beitragen oder Bugs melden, arbeiten mit der Development-Version, um ihre Patches gegen den aktuellen Codestand zu testen. Ohne Development-Version ist kein sinnvolles Contributing möglich. Pull Requests werden gegen den Development-Branch geöffnet, und nur dort kann der Contributor verifizieren, dass sein Fix keine Seiteneffekte hat.

Technische Architektur

VHS Development ist keine separate Extension, sondern der aktuelle Entwicklungsstand des VHS-Repositories auf GitHub (FluidTYPO3/vhs). Die Installation erfolgt über Composer mit dem dev-main oder einem spezifischen Branch:

• composer require fluidtypo3/vhs:dev-main installiert den aktuellen Entwicklungsstand
• composer require fluidtypo3/vhs:dev-feature-xyz installiert einen spezifischen Feature-Branch
• Die minimum-stability-Einstellung in composer.json muss auf dev gesetzt werden, was sich auf alle Pakete auswirkt

VHS selbst hat als einzige harte Abhängigkeit den TYPO3 Core (Fluid Template Engine). Die über 300 ViewHelper decken Bereiche ab wie:

• Content: Rendering von Content-Elementen, FAL-Zugriff, Media-Handling
• Format: String-Manipulation, Datum, Zahlen, JSON, Markdown
• Iterator: Array-Operationen, Sortierung, Filterung, Paginierung
• Page: Seitenbaum-Navigation, Breadcrumb, Sitemap
• Media: Bild-Manipulation, Video-Embedding, Audio
• Security: Zugriffsprüfungen, Login-Status, FE-User-Gruppen

Die Development-Version kann ViewHelper enthalten, deren API sich noch ändert. Parameter können umbenannt, Rückgabewerte geändert oder ViewHelper komplett entfernt werden. Im Stable-Release ist die API eingefroren. Zwischen zwei Stable-Releases ändert sich im Development-Branch erfahrungsgemäss die Signatur von 5 bis 15 ViewHelpers. Wer diese in Produktiv-Templates nutzt, riskiert Fehler nach einem Composer-Update.

Häufige Probleme und Lösungen

Problem: Composer-Update bricht bestehende Templates. Ein composer update holt die neueste Development-Version, in der ein ViewHelper-Parameter umbenannt wurde. Alle Templates, die diesen Parameter nutzen, werfen Fehler. Die Lösung: Composer-Lock-File konsequent committen und VHS Development mit einer festen Commit-Referenz installieren: composer require fluidtypo3/vhs:dev-main#abc1234. So wird nicht automatisch die neueste Version gezogen.

Problem: minimum-stability dev beeinflusst andere Pakete. Wenn minimum-stability in composer.json auf dev gesetzt ist, können auch andere Pakete instabile Versionen installieren. Die Lösung: "minimum-stability": "stable" beibehalten und VHS Development explizit als Ausnahme definieren: "fluidtypo3/vhs": "dev-main as 6.99.0". Das Alias-Pattern erlaubt die Installation ohne globale Stabilitätsänderung.

Problem: CI/CD-Pipeline schlägt mit Development-Version fehl. Automatische Tests und Deployments, die auf Composer-Installationen basieren, können bei der Development-Version fehlschlagen, wenn GitHub temporär nicht erreichbar ist oder der Branch Force-Pushed wurde. Die Lösung: Für CI/CD-Pipelines einen lokalen Composer-Mirror (Satis) verwenden oder auf den Stable-Release wechseln.

Migration und Versions-Kompatibilität

Die VHS Stable-Releases folgen den TYPO3 LTS-Zyklen: VHS 6.x unterstützt TYPO3 v11, VHS 7.x unterstützt TYPO3 v12. Der Development-Branch zielt jeweils auf die nächste Major-Version ab.

Der Wechsel von VHS Development zurück auf Stable ist in der Regel unkompliziert, solange keine ViewHelper genutzt werden, die nur in der Development-Version existieren. Gosign empfiehlt folgendes Vorgehen: Vor dem Wechsel auf Stable alle verwendeten VHS-ViewHelper gegen die Stable-Dokumentation abgleichen. Der VHS-Changelog auf GitHub listet alle Änderungen zwischen Development und Release.

Für TYPO3 v13 ist ein VHS 8.x-Release geplant. Teams, die heute mit der Development-Version arbeiten, sollten ihre Templates auf deprecated ViewHelper prüfen. Claus Due und das FluidTYPO3-Team kündigen Breaking Changes in der Regel im GitHub-Milestone an.

Gosign empfiehlt folgende Strategie für den Umgang mit VHS Development: Auf Entwicklungsumgebungen und in Feature-Branches die Development-Version nutzen, um neue ViewHelper zu evaluieren. Auf Staging und Produktion ausschliesslich Stable-Releases einsetzen. Wenn ein kritischer Bugfix nur in Development verfügbar ist, den spezifischen Commit als Composer-Referenz pinnen und im Code einen TODO-Kommentar hinterlassen, der bei der nächsten Stable-Release-Prüfung auffällt. Dieses Pattern verhindert, dass Development-Abhängigkeiten unbemerkt in die Produktion gelangen.