VHS para TYPO3

EXT:vhs é a caixa de ferramentas invisível de todo template TYPO3 profissional

Quem trabalha com Fluid em TYPO3 e vai além da simples exibição de conteúdo, cedo ou tarde acaba chegando ao EXT:vhs. A extensão do ecossistema FluidTYPO3 entrega várias centenas de ViewHelpers adicionais para tarefas que o core deliberadamente não cobre: manipulação de imagem, lógica de iterador, operações matemáticas, tratamento de string, consultas de conteúdo, navegação de página. Para desenvolvedoras frontend em agências e times internos, o vhs não é um nice to have opcional, mas a base sobre a qual estruturas de template complexas surgem sem desvios por PHP.

O público-alvo típico são times que mantêm site packages extensos: editoras com tipos de conteúdo heterogêneos, universidades brasileiras como USP ou UFRJ com navegações aninhadas, conglomerados com portais multilíngues. Sem vhs, a cada segunda exigência especial seria necessário um ViewHelper próprio ou algo em TypoScript. Com vhs, a lógica permanece onde deve estar: no template.

Cenários típicos de uso

Um primeiro cenário é a consulta de conteúdo a partir de árvores de página externas. Um portal de cliente de uma indústria de máquinas com 3.000 páginas de produto precisa, em cada página, de um bloco de teaser com news recentes de um ramo rootline separado. O ViewHelper v:content.get busca conteúdos de páginas arbitrárias e permite composições modulares de página sem construir objetos CONTENT em TypoScript.

Um segundo cenário é o processamento de iteradores. Uma editora mantém artigos com categorias, tags e autores como ObjectStorage. Em Fluid sozinho, filtragem, agrupamento e ordenação por objetos aninhados são trabalhosos. Com v:iterator.filter, v:iterator.sort ou v:iterator.groupBy, operações assim ficam legíveis e manuteníveis direto no template.

Um terceiro cenário é processamento de imagem. Uma loja e-commerce com 500 produtos por temporada precisa de variantes responsivas com tag picture, fallback WebP e placeholder LQIP. Com Media ViewHelpers do vhs, esse bloco é definido uma vez no partial e reutilizado em todo lugar.

Um quarto cenário é o preparo matemático de indicadores em páginas de reporting. Quem quer exibir preços com subtotais, percentuais ou médias ponderadas usa v:math.sum, v:math.percentage ou v:math.division, sem construir um controller próprio para cada cálculo.

Arquitetura técnica

EXT:vhs é uma library extension pura, sem módulos de backend e sem tabelas de banco. Ela registra namespaces no Fluid ({namespace v=FluidTYPO3\Vhs\ViewHelpers}) e disponibiliza assim os ViewHelpers sob o prefixo v:. A extensão não tem dependências rígidas com o restante do stack FluidTYPO3 (Flux, Fluidcontent), ainda que frequentemente seja usada em conjunto com eles.

A instalação é feita via Composer com fluidtypo3/vhs. Em um site package, o vhs costuma ser tratado como dependência da própria provider extension, para que o registro de namespace aconteça no template de layout ou globalmente via array de configuração TypoScript. Quem precisa declarar os namespaces em cada template separadamente geralmente esqueceu do caminho global de registro.

Relevante para performance é que o vhs não cacheia consultas de banco próprias. Quem usa v:content.get ou v:page.menu sem cache do Fluid gera, no pior caso, a mesma consulta em cada carregamento de página. A solução está em um cache Fluid bem configurado via page cache e content cache, além do uso consciente do mecanismo CacheStatic no core TYPO3.

O pacote da extensão é modular. Grupos individuais de ViewHelpers (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) podem ser usados de forma direcionada, sem trazer todo o stack ao projeto. Na prática, porém, a coleção inteira costuma ser instalada, porque as dependências entre grupos são difíceis de encapsular e o footprint geral permanece aceitável.

Problemas frequentes e soluções

O primeiro problema é a infame colisão de namespace. Quem usa EXT:vhs em paralelo com ViewHelpers próprios sob o prefixo v: encontra sobreposições imprevisíveis. A solução é registrar ViewHelpers próprios sempre sob um prefixo próprio (por exemplo my:) e trocar chamadas vhs por ViewHelpers do core quando ele já oferece alternativa (f:format.padding substitui v:format.padding).

O segundo problema é compatibilidade de versões com Fluid mais novos. Em TYPO3 v12 e v13, o Fluid foi revisado várias vezes, o que em alguns ViewHelpers vhs gera warnings de deprecation ou erros de tipo. A solução é um audit dos ViewHelpers usados contra a matriz de compatibilidade no repositório GitHub e a substituição seletiva por alternativas do core ou por implementações próprias enxutas.

O terceiro problema é performance sob carga. v:iterator.filter e v:iterator.sort são confortáveis, mas intensivos em cálculo em grandes volumes de dados. Quem renderiza um template com 10.000 produtos por página deve mover a lógica de filtro para o repository e passar ao template apenas o resultado já filtrado.

Um quarto problema, muitas vezes ignorado, são mudanças de comportamento não documentadas entre versões vhs. Um ViewHelper que na versão 6.x retornava uma string, na versão 7.x entrega de repente um array ou vice-versa. A solução é fixar a versão vhs no arquivo lock do Composer e, a cada upgrade, verificar cuidadosamente o changelog contra o acervo de templates próprios, idealmente com um passo de lint na pipeline de CI que sinalize assinaturas de ViewHelper desconhecidas imediatamente.

Migração e compatibilidade de versões

EXT:vhs é oficialmente liberado para TYPO3 v11 e v12. Para v13 existe um branch de desenvolvimento mantido ativamente, mas ainda não pronto para produção em todos os ViewHelpers. Times que planejam atualmente um upgrade de v11 para v12 podem, em regra, levar o vhs junto sem grandes intervenções. O caminho de upgrade para v13 é o ponto crítico em projetos template-intensivos: aqui vale uma comparação custo-benefício entre manter o vhs e reconstruir gradualmente em Fluid do core mais ViewHelpers próprios.

A resposta estratégica depende do quanto o vhs é usado. Projetos que empregam apenas um punhado de ViewHelpers vhs devem, no próximo upgrade, substituí-los por construções do core ou ViewHelpers específicos do projeto. Projetos com centenas de chamadas vhs em todos os templates se beneficiam de manter o vhs e fazer em cada upgrade um teste de compatibilidade direcionado. A substituição só vale onde a carga legada pesa mais na manutenção do que uma continuidade controlada.

A Gosign acompanha upgrades TYPO3 com carga de vhs e decide junto com o time quais ViewHelpers vhs são substituídos por construções do core e quais surgem como ViewHelpers enxutos do projeto. Assim a herança de templates permanece manutenível, sem que o time se prenda por mais anos a um stack de biblioteca externo.