Countdown für TYPO3

Countdown-Extensions lösen ein Kommunikationsproblem, das reine Texte nicht schaffen

Wenn eine Messe in 23 Tagen beginnt, wenn das Frühbucher-Angebot um Mitternacht abläuft oder wenn der neue Shop am 1. Mai live geht, reicht ein Satz wie “Nur noch wenige Tage” nicht. Nutzer reagieren auf tickende Uhren deutlich stärker als auf statische Daten, und auf einer TYPO3-Seite ist die einfachste Variante, einen sichtbaren Countdown-Timer einzubauen. Mehrere TYPO3-Extensions aus dem TER bieten diese Funktionalität, die bekannteste ist schlicht “countdown”. Für jede Unternehmenswebsite mit Event-Ankündigungen, Produktlaunches oder befristeten Aktionen ist das eine wiederkehrende Anforderung, die ohne Extension meist in individuellem JavaScript landet. Die Wahl zwischen Extension und eigener Lösung hängt selten an der Technik, sondern an der Frage, wer den Countdown in der Redaktion pflegen können soll.

Typische Einsatzszenarien reichen von Messen bis zu E-Commerce-Aktionen

Das erste Szenario sind Messen und Konferenzen. Ein Verband kündigt seine Jahrestagung sechs Monate im Voraus an und will den verbleibenden Zeitraum sichtbar machen, idealerweise mit Tagen, Stunden, Minuten und Sekunden. Der Countdown läuft auf der Landing-Page, schaltet sich in den letzten 24 Stunden um und verschwindet nach Veranstaltungsende automatisch, ohne dass ein Redakteur die Seite anpassen muss. Das spart nicht nur Pflegeaufwand, sondern verhindert auch peinliche Situationen wie einen Counter, der nach dem Event weiterhin einen negativen Wert anzeigt.

Ein zweites Szenario sind Produktlaunches und Vorbestell-Fenster. E-Commerce-Projekte auf Basis von aimeos oder externen Shops nutzen Countdowns auf Landing-Pages, um Kunden an den Starttermin zu binden. Bei Vorbestellungen dient der Countdown als Dringlichkeits-Signal und steigert nachweislich die Conversion.

Ein drittes Szenario sind Bewerbungs- und Antragsfristen. Hochschulen zeigen auf der Bewerbungsseite einen Countdown bis zum Fristende, Verbände nutzen ihn für Frühbucher-Preise, öffentliche Einrichtungen für Einreichfristen öffentlicher Ausschreibungen. Hier geht es nicht um Marketing, sondern um Service: Besucher sollen auf einen Blick erkennen, wie viel Zeit ihnen bleibt. Für Antragsportale im Wissenschaftsbereich ist das praktisch Standard, weil Förderanträge mit fixer Deadline und harter Cut-off-Zeit arbeiten.

Technische Architektur läuft über eine Kombination aus Fluid-Template und Minimal-JavaScript

Klassische Countdown-Extensions in TYPO3 bestehen aus zwei Teilen. Der Backend-Teil ist ein Content-Element oder Plugin, in dem der Redakteur Zieldatum, Zielzeit, Zeitzone, Label und optional eine Endzeit-Nachricht pflegt. Der Frontend-Teil rendert diese Daten in ein Fluid-Template und hängt ein kleines JavaScript an, das die Differenz zum aktuellen Zeitpunkt berechnet und im DOM aktualisiert.

Die meisten Extensions bringen zusätzlich eine Konfiguration für das Rendering mit: Anzahl der Stellen (Tage, Stunden, Minuten, Sekunden), Darstellung als Kreisgrafik oder als Flip-Clock, Farben und Animation. Das JavaScript läuft typischerweise mit einem setInterval von 1000 ms und rechnet client-seitig, sodass der Server-Cache unverändert bleibt. Wichtig ist, dass der Timer nicht bei einem negativen Wert endet, sondern per Event eine “Event gestartet” oder “Angebot abgelaufen”-Nachricht anzeigt.

Für DSGVO-kritische Projekte lohnt sich ein Blick auf die JavaScript-Abhängigkeiten. Einige Extensions laden jQuery oder MomentJS nach, was zusätzlichen Renderpath verursacht. Moderne Varianten kommen mit ein paar Zeilen vanilla-JS und einem CSS-Grid aus, das auch ohne Extension funktioniert.

Häufige Probleme betreffen Zeitzonen, Caching und SEO

Das häufigste Supportthema ist die Zeitzone. Der Redakteur trägt ein Datum im Backend ein, der Server steht auf UTC, der Besucher lebt in MEZ - und der Countdown zeigt eine Stunde zuviel an. Die Extension muss sauber zwischen Server-Zeit, Backend-Redaktionszeit und Browser-Zeit unterscheiden. Wir empfehlen immer, das Zieldatum in ISO-8601 mit expliziter Zeitzone (“2026-05-01T12:00:00+02:00”) an das JavaScript zu übergeben.

Das zweite Problem ist das Page-Cache. Wenn die gerenderte HTML-Seite für eine Stunde gecached ist, darf der Countdown kein server-seitig berechnetes “23 Tage 7 Stunden” enthalten, weil der Cache-Hit diesen Wert einfriert. Die Lösung: Der Fluid-Teil rendert nur das Zieldatum als data-Attribut, die Differenz-Berechnung läuft ausschliesslich im Browser.

Drittens ist SEO ein Punkt. Ein reiner JavaScript-Countdown zeigt Google weder das Zieldatum noch den Anlass. Für Suchmaschinen gehört ein schema:Event-JSON-LD in die Seite, mit startDate, endDate und name, damit Google-Ergebnisse die Veranstaltung als Rich Snippet ausgeben. Wer die Extension einbaut, sollte also das Zieldatum nicht nur an den Timer übergeben, sondern zusätzlich als strukturierte Daten in den Seiten-Header schreiben. Ohne diese Auszeichnung bleibt der Countdown für Google unsichtbar und verliert seine Marketing-Wirkung schon im Suchergebnis.

TYPO3 v12 und v13: Extension oder schlankes Alternativkonstrukt

Ob eine Countdown-Extension auf TYPO3 v12 und v13 noch sinnvoll ist, hängt vom Umfang des Projekts ab. Bei einer einzigen Event-Seite reicht ein kleines Content-Element mit einem data-Attribut und 30 Zeilen JavaScript, komplett ohne Extension-Overhead. Für Redaktionen mit vielen Events, die den Timer regelmässig selbst pflegen wollen, rechtfertigt sich die Extension, weil Redakteure ein bekanntes UI-Element im Backend brauchen.

Gosign baut in der Praxis beides: Für Einmal-Launches liefern wir ein schlankes Content-Element ohne Extension, das nur aus einem Fluid-Template und Mini-JS besteht. Für wiederkehrende Use-Cases integrieren wir eine gepflegte Extension und überschreiben das Fluid-Template, um das Design an das restliche Projekt anzupassen. Beim Upgrade alter countdown-Extensions ist fast immer ein Wechsel auf die vanilla-Variante sinnvoll, weil jQuery-basierte Altversionen weder in TYPO3 v12 noch auf modernen Performance-Budgets mithalten können.