VHS dla TYPO3

EXT:vhs to niewidzialna skrzynka narzędziowa każdego profesjonalnego szablonu TYPO3

Kto pracuje w TYPO3 z Fluid i wychodzi poza zwykłe wyświetlanie treści, prędzej czy później trafia przy EXT:vhs. Rozszerzenie z ekosystemu FluidTYPO3 dostarcza kilkaset dodatkowych ViewHelperów dla zadań, których core świadomie nie pokrywa: manipulacja obrazami, logika iteratorów, operacje matematyczne, obsługa stringów, zapytania treści, nawigacja stron. Dla deweloperów frontendowych w agencjach i zespołach inhouse vhs to nie opcjonalny nice-to-have, tylko baza, na której powstają złożone struktury szablonów bez objazdów PHP.

Grupą docelową są zazwyczaj zespoły, które pielęgnują rozbudowane Site Packages: wydawnictwa z heterogenicznymi typami treści, uczelnie z zagnieżdżonymi nawigacjami, koncerny z wielojęzycznymi portalami. Bez vhs co drugie specjalne wymaganie musiałoby być wyniesione do własnego ViewHelpera lub do TypoScript. Z vhs logika pozostaje tam, gdzie powinna być: w szablonie.

Typowe scenariusze zastosowania

Pierwszym scenariuszem jest zapytanie o treści z obcych drzew stron. Portal kliencki producenta maszyn z 3000 stron produktów potrzebuje na każdej stronie bloku teaserowego z aktualnymi newsami z oddzielnej gałęzi rootline newsów. ViewHelper v:content.get pobiera treści z dowolnych stron i umożliwia tym samym modułowe kompozycje stron, bez konieczności budowania obiektów TypoScript-CONTENT.

Drugim scenariuszem jest przetwarzanie iteracyjne. Wydawnictwo pielęgnuje artykuły z kategoriami, tagami i autorami jako ObjectStorage. Samym Fluid filtrowanie, grupowanie i sortowanie przez zagnieżdżone obiekty jest uciążliwe. Z v:iterator.filter, v:iterator.sort lub v:iterator.groupBy takie operacje można bezpośrednio czytać i utrzymywać w szablonie.

Trzecim scenariuszem jest przetwarzanie obrazów. Sklep e-commerce z 500 produktami na sezon potrzebuje responsywnych wariantów obrazów z tagiem picture, fallbackiem WebP i placeholderem LQIP. Z ViewHelperami media vhs ten blok jest raz definiowany w partialu, a następnie wszędzie ponownie używany.

Czwartym scenariuszem jest matematyczne przygotowanie wskaźników na stronach raportowych. Kto chce wyświetlać ceny z sumami częściowymi, udziałami procentowymi lub średnimi ważonymi, sięga po v:math.sum, v:math.percentage lub v:math.division, bez konieczności budowania dla każdej kalkulacji własnego kontrolera.

Architektura techniczna

EXT:vhs to czysta biblioteka-rozszerzenie bez modułów backendowych i bez tabel bazy danych. Rejestruje przestrzenie nazw w Fluid ({namespace v=FluidTYPO3\Vhs\ViewHelpers}) i udostępnia tym samym ViewHelpery przez prefiks v:. Rozszerzenie nie ma twardych zależności od reszty stosu FluidTYPO3 (Flux, Fluidcontent), nawet gdy jest często używane razem z nimi.

Instalacja odbywa się przez Composer z fluidtypo3/vhs. W Site Package vhs jest zazwyczaj prowadzone jako zależność własnego rozszerzenia providera, dzięki czemu rejestracja przestrzeni nazw odbywa się w szablonie layoutu lub globalnie przez tablicę konfiguracyjną TypoScript. Kto musi deklarować przestrzenie nazw w każdym szablonie pojedynczo, zazwyczaj pominął ścieżkę rejestracji globalnej.

Dla wydajności istotne jest, że vhs nie cache’uje własnych zapytań bazodanowych. Kto używa v:content.get lub v:page.menu bez cache’owania Fluid, w najgorszym razie generuje to samo zapytanie przy każdym wywołaniu strony. Rozwiązanie leży w porządnie skonfigurowanym cache’owaniu Fluid przez page- i content-cache oraz świadomym używaniu mechanizmu CacheStatic w core TYPO3.

Pakiet rozszerzenia jest zbudowany modularnie. Pojedyncze grupy ViewHelperów (Asset, Condition, Format, Iterator, Math, Media, Page, Resource, System, Variable) mogą być celowo używane, bez konieczności wprowadzania całego stosu do projektu. W praktyce jednak cała kolekcja jest instalowana, bo zależności między grupami trudno enkapsulować, a footprint rozszerzenia w całości pozostaje akceptowalny.

Częste problemy i rozwiązania

Pierwszym problemem jest notoryczna kolizja przestrzeni nazw. Kto używa EXT:vhs równolegle do własnych ViewHelperów pod prefiksem v:, otrzymuje nieprzewidywalne nakładania się. Rozwiązaniem jest konsekwentne rejestrowanie własnych ViewHelperów pod własnym prefiksem (np. my:) i przestawianie wywołań vhs na ViewHelpery core, gdzie core TYPO3 oferuje już alternatywę (f:format.padding zastępuje v:format.padding).

Drugim problemem jest kompatybilność wersji z nowszymi wersjami Fluid. W TYPO3 v12 i v13 Fluid był wielokrotnie przebudowany, co przy niektórych ViewHelperach vhs prowadzi do deprecation-warnings lub błędów typu. Rozwiązaniem jest audyt używanych ViewHelperów wobec Compatibility-Matrix w repozytorium GitHub i selektywne zastępowanie alternatywami core lub własnymi, smukłymi implementacjami.

Trzecim problemem jest wydajność pod obciążeniem. v:iterator.filter i v:iterator.sort są wygodne, ale wymagające obliczeniowo przy dużych zbiorach danych. Kto renderuje szablon z 10 000 produktów na stronę, powinien przenieść logikę filtra do repozytorium i przekazywać szablonowi tylko już przefiltrowany wynik.

Czwartym, często pomijanym problemem są nieudokumentowane zmiany zachowań między wersjami vhs. ViewHelper, który w wersji 6.x zwracał string, w wersji 7.x nagle dostarcza tablicę lub odwrotnie. Rozwiązaniem jest zafiksowanie wersji vhs w composer-lock-file i przy każdym upgrade staranne sprawdzenie changelog wobec własnego zasobu szablonów, idealnie z krokiem lint w pipeline CI, który natychmiast zgłasza nieznane sygnatury ViewHelperów.

Migracja i kompatybilność wersji

EXT:vhs jest oficjalnie zwolnione dla TYPO3 v11 i v12. Dla v13 istnieje gałąź rozwojowa, która jest aktywnie utrzymywana, ale jeszcze nie we wszystkich ViewHelperach jest gotowa do produkcji. Zespoły, które obecnie planują upgrade z v11 na v12, mogą z reguły wziąć vhs ze sobą bez większych ingerencji. Ścieżka upgrade do v13 jest dla projektów intensywnie wykorzystujących szablony punktem krytycznym: tu opłaca się porównanie kosztów i korzyści między zachowaniem vhs a stopniową przebudową na core-Fluid plus własne ViewHelpery.

Strategiczna odpowiedź zależy od skali użycia vhs. Projekty, które używają tylko garści ViewHelperów vhs, powinny zastąpić je przy następnym upgrade celowo konstruktami core lub projektowymi ViewHelperami. Projekty z setkami wywołań vhs w szablonach natomiast korzystają z dalszego prowadzenia vhs i przeprowadzania przy każdym upgrade celowego testu kompatybilności. Zastąpienie opłaca się tylko tam, gdzie dług obciąża pielęgnację bardziej niż kontrolowane dalsze prowadzenie.

Gosign towarzyszy upgrade TYPO3 z długiem vhs i decyduje wspólnie z zespołem, które ViewHelpery vhs zostają zastąpione konstruktami core, a które powstają na nowo jako smukłe projektowe ViewHelpery. W ten sposób spuścizna szablonów pozostaje utrzymywalna, bez wiązania się na kolejne lata z zewnętrznym stosem bibliotek.