Countdown dla TYPO3

Rozszerzenia countdown rozwiązują problem komunikacyjny, którego same teksty nie potrafią

Gdy targi zaczynają się za 23 dni, gdy oferta early-bird wygasa o północy lub gdy nowy sklep rusza 1 maja, zdanie “tylko kilka dni” nie wystarcza. Użytkownicy reagują na tykające zegary zdecydowanie silniej niż na statyczne daty, a na stronie TYPO3 najprostszym wariantem jest wbudowanie widocznego licznika odliczającego. Kilka rozszerzeń TYPO3 z TER oferuje tę funkcjonalność, najbardziej znane nazywa się po prostu “countdown”. Dla każdej strony firmowej z ogłoszeniami wydarzeń, premierami produktów lub akcjami czasowymi jest to powracające wymaganie, które bez rozszerzenia zazwyczaj ląduje w indywidualnym JavaScript. Wybór między rozszerzeniem a własnym rozwiązaniem rzadko zależy od techniki, tylko od pytania, kto w redakcji ma móc pielęgnować countdown.

Typowe scenariusze zastosowania sięgają od targów po akcje e-commerce

Pierwszym scenariuszem są targi i konferencje. Stowarzyszenie ogłasza swoje doroczne spotkanie sześć miesięcy wcześniej i chce uwidocznić pozostały czas, idealnie z dniami, godzinami, minutami i sekundami. Countdown działa na landing page, przełącza się w ciągu ostatnich 24 godzin i automatycznie znika po zakończeniu wydarzenia, bez konieczności dostosowywania strony przez redaktora. To oszczędza nie tylko nakład pielęgnacji, ale też zapobiega żenującym sytuacjom, jak licznik pokazujący po wydarzeniu wartość ujemną.

Drugim scenariuszem są premiery produktów i okna pre-order. Projekty e-commerce oparte na aimeos lub zewnętrznych sklepach używają countdownów na landing page, aby związać klientów z datą startu. Przy pre-orderach countdown służy jako sygnał pilności i wykazalnie zwiększa konwersję.

Trzecim scenariuszem są terminy rekrutacji i wniosków. Uczelnie pokazują na stronie rekrutacyjnej countdown do końca terminu, stowarzyszenia używają go przy cenach early-bird, instytucje publiczne przy terminach składania ofert w przetargach publicznych. Nie chodzi tu o marketing, tylko o serwis: odwiedzający powinni na pierwszy rzut oka rozpoznać, ile czasu im pozostało. Dla portali wnioskowych w nauce to praktycznie standard, bo wnioski o granty pracują ze stałym deadline i twardym cut-off.

Architektura techniczna przebiega przez kombinację szablonu Fluid i minimalnego JavaScript

Klasyczne rozszerzenia countdown w TYPO3 składają się z dwóch części. Część backendowa to element treści lub plugin, w którym redaktor pielęgnuje datę docelową, czas docelowy, strefę czasową, etykietę i opcjonalnie komunikat końcowy. Część frontendowa renderuje te dane w szablon Fluid i dodaje małe JavaScript, które oblicza różnicę do aktualnego momentu i aktualizuje w DOM.

Większość rozszerzeń przynosi dodatkowo konfigurację renderowania: liczba pozycji (dni, godziny, minuty, sekundy), wyświetlanie jako grafika kołowa lub flip-clock, kolory i animacja. JavaScript działa zazwyczaj z setInterval 1000 ms i oblicza po stronie klienta, dzięki czemu cache serwera pozostaje niezmieniony. Ważne, żeby timer nie kończył się przy wartości ujemnej, lecz przez zdarzenie pokazywał komunikat “Wydarzenie rozpoczęte” lub “Oferta wygasła”.

Dla projektów krytycznych pod kątem ochrony danych opłaca się spojrzeć na zależności JavaScript. Niektóre rozszerzenia doładowują jQuery lub MomentJS, co powoduje dodatkową ścieżkę renderowania. Nowoczesne warianty wystarczają kilkoma liniami vanilla-JS i CSS-Grid, które działa również bez rozszerzenia.

Częste problemy dotyczą stref czasowych, cache’owania i SEO

Najczęstszym tematem wsparcia jest strefa czasowa. Redaktor wprowadza datę w backendzie, serwer stoi na UTC, odwiedzający żyje w CET, a countdown pokazuje godzinę za dużo. Rozszerzenie musi porządnie rozróżniać między czasem serwera, czasem redakcji backendowej a czasem przeglądarki. Zalecamy zawsze przekazywać datę docelową w ISO-8601 z wyraźną strefą czasową (“2026-05-01T12:00:00+02:00”) do JavaScript.

Drugim problemem jest Page-Cache. Gdy wyrenderowana strona HTML jest cache’owana na godzinę, countdown nie może zawierać obliczonego po stronie serwera “23 dni 7 godzin”, bo cache-hit zamraża tę wartość. Rozwiązanie: część Fluid renderuje tylko datę docelową jako data-atrybut, a obliczanie różnicy odbywa się wyłącznie w przeglądarce.

Po trzecie, SEO to ważny punkt. Czysto JavaScriptowy countdown nie pokazuje Google ani daty docelowej, ani okazji. Dla wyszukiwarek do strony należy JSON-LD schema:Event z startDate, endDate i name, żeby wyniki Google mogły prezentować wydarzenie jako Rich Snippet. Kto wbudowuje rozszerzenie, powinien więc nie tylko przekazywać datę docelową do timera, ale dodatkowo zapisywać jako dane strukturalne w nagłówku strony. Bez tego oznaczenia countdown pozostaje dla Google niewidoczny i traci swoją skuteczność marketingową już w wyniku wyszukiwania.

TYPO3 v12 i v13: rozszerzenie lub smukłe alternatywne rozwiązanie

Czy rozszerzenie countdown ma sens na TYPO3 v12 i v13, zależy od rozmiaru projektu. Przy pojedynczej stronie wydarzenia wystarcza mały element treści z data-atrybutem i 30 liniami JavaScript, całkowicie bez overhead rozszerzenia. Dla redakcji z wieloma wydarzeniami, które chcą regularnie pielęgnować timer samodzielnie, rozszerzenie jest uzasadnione, bo redaktorzy potrzebują znanego elementu UI w backendzie.

Gosign buduje w praktyce jedno i drugie: dla jednorazowych launchy dostarczamy smukły element treści bez rozszerzenia, który składa się tylko z szablonu Fluid i mini-JS. Dla powtarzających się use cases integrujemy utrzymywane rozszerzenie i nadpisujemy szablon Fluid, żeby dopasować design do reszty projektu. Przy upgrade starych rozszerzeń countdown prawie zawsze ma sens przejście na wariant vanilla, bo oparte na jQuery stare wersje nie dotrzymują kroku ani w TYPO3 v12, ani w nowoczesnych budżetach wydajności.