VHS for TYPO3

EXT:vhs is the invisible toolbox of every professional TYPO3 template

Anyone working in TYPO3 with Fluid and going beyond mere output of content ends up at EXT:vhs sooner or later. The extension from the FluidTYPO3 ecosystem ships several hundred additional ViewHelpers for tasks the core deliberately does not cover: image manipulation, iterator logic, math operations, string handling, content queries, page navigation. For frontend developers at agencies and in-house teams, vhs is not an optional nice-to-have but the foundation on which complex template structures emerge without PHP detours.

The typical audience are teams that maintain demanding sitepackages: publishers with heterogeneous content types, universities with nested navigation trees, corporations with multilingual portals. Without vhs, every other special requirement would have to be offloaded into a custom ViewHelper or into TypoScript. With vhs, the logic stays where it belongs: in the template.

Typical use cases

A first scenario is content queries across foreign page trees. A customer portal of a mechanical engineering company with 3,000 product pages needs a teaser block on every page with the latest news from a separate news rootline branch. The ViewHelper v:content.get pulls content from any pages and enables modular page composition without having to build TypoScript CONTENT objects.

A second scenario is iterator processing. A publishing house maintains articles with categories, tags and authors as ObjectStorage. In pure Fluid, filtering, grouping and sorting across nested objects is cumbersome. With v:iterator.filter, v:iterator.sort or v:iterator.groupBy, such operations become readable and maintainable directly inside the template.

A third scenario is image processing. An e-commerce shop with 500 products per season needs responsive image variants with picture tag, WebP fallback and LQIP placeholder. With vhs media ViewHelpers, this block is defined once in a partial and reused everywhere.

A fourth scenario is the mathematical processing of figures in reporting pages. Anyone who wants to output prices with subtotals, percentages or weighted averages reaches for v:math.sum, v:math.percentage or v:math.division, without having to build a dedicated controller for every calculation.

Technical architecture

EXT:vhs is a pure library extension without backend modules and without database tables. It registers namespaces in Fluid ({namespace v=FluidTYPO3\Vhs\ViewHelpers}) and thereby exposes the ViewHelpers through the prefix v:. The extension has no hard dependencies on the rest of the FluidTYPO3 stack (Flux, Fluidcontent), even if it is often deployed alongside them.

Installation runs through Composer with fluidtypo3/vhs. In a sitepackage, vhs is usually listed as a dependency of the project’s own provider extension, so that namespace registration happens in the layout template or globally through the TypoScript configuration array. Anyone who has to declare the namespace in every single template has usually missed the global registration path.

Relevant for performance is that vhs does not cache its own database queries. Anyone using v:content.get or v:page.menu without Fluid caching at worst creates the same query on every page view. The solution lies in cleanly configured Fluid caching through page and content cache and in the conscious use of the CacheStatic mechanism in the TYPO3 core.

The extension package is modular. Individual ViewHelper groups (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) can be used selectively without pulling the entire stack into the project. In practice, however, the full collection is typically installed, because the dependencies between the groups are difficult to isolate and the footprint of the extension as a whole remains acceptable.

Common problems and solutions

The first problem is the infamous namespace collision. Anyone who uses EXT:vhs alongside their own ViewHelpers under the prefix v: gets unpredictable overlaps. The solution is to register custom ViewHelpers consistently under a dedicated prefix (for example my:) and to move vhs calls onto core ViewHelpers where the TYPO3 core now offers an alternative (f:format.padding replaces v:format.padding).

The second problem is version compatibility with newer Fluid versions. In TYPO3 v12 and v13, Fluid has been reworked several times, which causes deprecation warnings or type errors in some vhs ViewHelpers. The solution is an audit of the ViewHelpers in use against the compatibility matrix in the GitHub repository and a selective replacement with core alternatives or bespoke lean implementations.

The third problem is performance under load. v:iterator.filter and v:iterator.sort are convenient but compute-intensive on large datasets. Anyone rendering a template with 10,000 products per page should shift the filter logic into the repository and only pass the already filtered result to the template.

A fourth, often overlooked problem are undocumented behaviour changes between vhs versions. A ViewHelper that returned a string in version 6.x suddenly returns an array in version 7.x, or vice versa. The solution is to pin the vhs version in the Composer lock file and carefully diff the changelog against the project’s templates on every upgrade, ideally with a lint step in the CI pipeline that immediately flags unknown ViewHelper signatures.

Migration and version compatibility

EXT:vhs is officially released for TYPO3 v11 and v12. For v13 there is a development branch that is actively maintained but not yet production-ready in all ViewHelpers. Teams currently planning an upgrade from v11 to v12 can usually carry vhs along without major intervention. The upgrade path to v13 is the critical point for template-heavy projects: here it is worth a cost-benefit comparison between keeping vhs and stepwise rewriting to core Fluid plus custom ViewHelpers.

The strategic answer depends on the extent of vhs usage. Projects that only use a handful of vhs ViewHelpers should replace them on the next upgrade with core constructs or project-specific ViewHelpers. Projects with hundreds of vhs calls across all templates are better off keeping vhs and running a targeted compatibility test on every upgrade. Replacement only pays off where the legacy burden weighs on maintenance more than a controlled continued use would.

Gosign accompanies TYPO3 upgrades with a vhs legacy and decides together with the team which vhs ViewHelpers are replaced by core constructs and which are rebuilt as lean project ViewHelpers. That keeps the template heritage maintainable without tying the project to an external library stack for years to come.