VHS para TYPO3

EXT:vhs es la caja de herramientas invisible de toda plantilla TYPO3 profesional

Quien trabaja en TYPO3 con Fluid y va más allá del simple volcado de contenidos, acaba tarde o temprano en EXT:vhs. La extensión del ecosistema FluidTYPO3 entrega varios cientos de ViewHelpers adicionales para tareas que el núcleo no cubre a propósito: manipulación de imágenes, lógica de iterador, operaciones matemáticas, manejo de strings, consultas de contenido, navegación de páginas. Para desarrolladoras frontend en agencias y equipos internos, vhs no es un nice-to-have opcional, sino la base sobre la que nacen estructuras de plantilla complejas sin rodeos por PHP.

El público típico son equipos que mantienen sitepackages exigentes: editoriales con tipos de contenido heterogéneos, universidades con navegaciones anidadas, grandes empresas con portales multilingües. Sin vhs cada segundo requisito especial tendría que externalizarse a un ViewHelper propio o a TypoScript. Con vhs la lógica se queda donde corresponde: en la plantilla.

Escenarios típicos de uso

Un primer escenario es la consulta de contenido desde ramas de árbol ajenas. Un portal de clientes de un fabricante de maquinaria con 3.000 páginas de producto necesita en cada página un bloque teaser con noticias actuales procedentes de una rama de rootline de noticias separada. El ViewHelper v:content.get recupera contenidos de cualquier página y permite así composiciones de página modulares sin tener que construir objetos CONTENT en TypoScript.

Un segundo escenario es el procesamiento con iteradores. Una editorial mantiene artículos con categorías, etiquetas y autores como ObjectStorage. Solo con Fluid los filtrados, agrupaciones y ordenaciones sobre objetos anidados resultan incómodos. Con v:iterator.filter, v:iterator.sort o v:iterator.groupBy esas operaciones pueden leerse y mantenerse directamente en la plantilla.

Un tercer escenario es el tratamiento de imágenes. Una tienda de comercio electrónico con 500 productos por temporada necesita variantes responsive con etiqueta picture, fallback WebP y placeholder LQIP. Con los ViewHelpers Media de vhs ese bloque se define una vez en el partial y se reutiliza en todas partes.

Un cuarto escenario es la preparación matemática de indicadores en páginas de reporting. Quien quiere mostrar precios con subtotales, porcentajes o medias ponderadas recurre a v:math.sum, v:math.percentage o v:math.division sin tener que construir un controlador propio para cada cálculo.

Arquitectura técnica

EXT:vhs es una extensión puramente de librería, sin módulos de backend y sin tablas de base de datos. Registra namespaces en Fluid ({namespace v=FluidTYPO3\Vhs\ViewHelpers}) y pone así los ViewHelpers a disposición bajo el prefijo v:. La extensión no tiene dependencias duras con el resto del stack FluidTYPO3 (Flux, Fluidcontent), aunque a menudo se utiliza junto con ellos.

La instalación se realiza mediante Composer con fluidtypo3/vhs. En un sitepackage, vhs suele llevarse como dependencia de la propia provider extension, de modo que el registro de namespaces ocurre en la plantilla de layout o globalmente mediante el array de configuración TypoScript. Quien tiene que declarar los namespaces por separado en cada plantilla normalmente ha pasado por alto el camino de registro global.

Para el rendimiento es relevante que vhs no cachea sus propias consultas a base de datos. Quien utiliza v:content.get o v:page.menu sin caché Fluid genera, en el peor caso, la misma consulta en cada acceso a página. La solución está en un caché Fluid bien configurado sobre Page y Content Cache, así como en el uso consciente del mecanismo CacheStatic del núcleo TYPO3.

El paquete de la extensión es modular. Grupos individuales de ViewHelpers (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) pueden utilizarse de forma dirigida sin que todo el stack entre al proyecto. En la práctica, sin embargo, se instala la colección completa, porque las dependencias entre grupos son difíciles de encapsular y el footprint total de la extensión sigue siendo asumible.

Problemas frecuentes y soluciones

El primer problema es la famosa colisión de namespaces. Quien usa EXT:vhs en paralelo a ViewHelpers propios bajo el prefijo v: obtiene superposiciones impredecibles. La solución es registrar los ViewHelpers propios con constancia bajo un prefijo propio (por ejemplo my:) y redirigir las llamadas vhs a los ViewHelpers del núcleo donde el núcleo TYPO3 ya ofrece una alternativa (f:format.padding sustituye a v:format.padding).

El segundo problema es la compatibilidad con versiones de Fluid más nuevas. En TYPO3 v12 y v13 Fluid se ha reelaborado varias veces, lo que en algunos ViewHelpers de vhs provoca deprecation warnings o errores de tipo. La solución es una auditoría de los ViewHelpers utilizados frente a la matriz de compatibilidad en el repositorio de GitHub y la sustitución selectiva por alternativas del núcleo o implementaciones propias y ligeras.

El tercer problema es el rendimiento bajo carga. v:iterator.filter y v:iterator.sort son cómodos, pero computacionalmente costosos con grandes volúmenes de datos. Quien renderiza una plantilla con 10.000 productos por página debería mover la lógica de filtro al repositorio y pasar a la plantilla solo el resultado ya filtrado.

Un cuarto problema, a menudo pasado por alto, son los cambios de comportamiento no documentados entre versiones de vhs. Un ViewHelper que en la versión 6.x devolvía un string entrega de pronto en la 7.x un array o al revés. La solución es fijar la versión de vhs en el Composer lock file y revisar en cada upgrade el changelog con cuidado frente al inventario de plantillas propio, idealmente con un paso de lint en el pipeline de CI que señale de inmediato firmas de ViewHelper desconocidas.

Migración y compatibilidad de versiones

EXT:vhs está oficialmente liberada para TYPO3 v11 y v12. Para v13 existe una rama de desarrollo mantenida activamente, pero aún no apta para producción en todos los ViewHelpers. Los equipos que planean actualmente un upgrade de v11 a v12 pueden llevarse vhs por regla general sin grandes intervenciones. El upgrade path a v13 es para proyectos intensivos en plantillas el punto crítico: aquí vale la pena un análisis coste-beneficio entre mantener vhs y el desmontaje gradual hacia Core Fluid más ViewHelpers propios.

La respuesta estratégica depende del alcance del uso de vhs. Los proyectos que solo utilizan un puñado de ViewHelpers vhs deberían sustituirlos en el próximo upgrade de forma dirigida por construcciones del núcleo o ViewHelpers específicos del proyecto. Los proyectos con cientos de llamadas a vhs a lo largo de todas las plantillas, en cambio, se benefician de seguir con vhs y realizar en cada upgrade un test de compatibilidad dirigido. La sustitución solo merece la pena donde la carga heredada lastra más el mantenimiento que un arrastre controlado.

Gosign acompaña upgrades de TYPO3 con deuda de vhs y decide junto con el equipo qué ViewHelpers vhs se sustituyen por construcciones del núcleo y cuáles nacen de nuevo como ViewHelpers ligeros del proyecto. Así la herencia de plantillas sigue siendo mantenible sin atarse durante más años a un stack de librerías externo.