Countdown for TYPO3

Countdown extensions solve a communication problem that plain text cannot

When a trade fair starts in 23 days, when the early bird offer expires at midnight or when the new shop goes live on 1 May, a sentence like “just a few days left” is not enough. Users react to ticking clocks much more strongly than to static dates, and on a TYPO3 page the simplest variant is to add a visible countdown timer. Several TYPO3 extensions from the TER offer this functionality, the best known is simply called “countdown”. For every corporate website with event announcements, product launches or limited-time campaigns, this is a recurring requirement that without an extension usually ends up as a custom JavaScript hack. The choice between extension and in-house solution rarely comes down to technology, but to the question of who should maintain the countdown in the editorial team.

Typical use cases range from trade fairs to e-commerce campaigns

The first scenario is trade fairs and conferences. An association announces its annual conference six months in advance and wants to make the remaining time visible, ideally with days, hours, minutes and seconds. The countdown runs on the landing page, switches over in the final 24 hours and disappears automatically after the event ends, without an editor having to adjust the page. That saves maintenance effort and also prevents awkward situations such as a counter that continues to show a negative value after the event.

A second scenario is product launches and pre-order windows. E-commerce projects based on aimeos or external shops use countdowns on landing pages to bind customers to the launch date. For pre-orders, the countdown acts as a urgency signal and demonstrably lifts conversion rates.

A third scenario are application and submission deadlines. Universities show a countdown to the deadline on the application page, associations use it for early bird prices, public institutions for submission deadlines of public tenders. Here it is not about marketing but about service: visitors should be able to see at a glance how much time they have left. For application portals in the academic space this is practically standard, because grant applications work with a fixed deadline and a hard cut-off time.

Technical architecture runs through a combination of Fluid template and minimal JavaScript

Classic countdown extensions in TYPO3 consist of two parts. The backend part is a content element or plug-in in which the editor maintains target date, target time, time zone, label and optionally an end-time message. The frontend part renders this data in a Fluid template and attaches a small JavaScript that computes the difference to the current time and updates the DOM.

Most extensions additionally ship a configuration for the rendering: number of digits (days, hours, minutes, seconds), display as circular graphic or as flip clock, colours and animation. The JavaScript typically runs with a setInterval of 1000 ms and computes client-side, so that the server cache stays unchanged. What matters is that the timer does not end at a negative value but fires an event that displays an “event started” or “offer expired” message.

For GDPR-critical projects, it is worth looking at the JavaScript dependencies. Some extensions load jQuery or MomentJS as a side effect, which causes additional render path. Modern variants get by with a few lines of vanilla JS and a CSS grid, which also works without an extension.

Common problems involve time zones, caching and SEO

The most common support topic is the time zone. The editor enters a date in the backend, the server is set to UTC, the visitor lives in CET, and the countdown shows an hour too many. The extension has to cleanly distinguish between server time, backend editorial time and browser time. We always recommend passing the target date in ISO 8601 with an explicit time zone (“2026-05-01T12:00:00+02:00”) to the JavaScript.

The second problem is the page cache. If the rendered HTML page is cached for an hour, the countdown must not contain a server-side computed “23 days 7 hours”, because the cache hit freezes that value. The solution: the Fluid part only renders the target date as a data attribute, and the difference calculation happens exclusively in the browser.

Thirdly, SEO is a factor. A pure JavaScript countdown shows Google neither the target date nor the occasion. For search engines, a schema:Event JSON-LD belongs in the page, with startDate, endDate and name, so that Google results can show the event as a rich snippet. Anyone adding the extension should therefore not only pass the target date to the timer but additionally write it as structured data into the page header. Without that markup, the countdown remains invisible to Google and loses its marketing effect already in the search result.

TYPO3 v12 and v13: extension or lean alternative construct

Whether a countdown extension still makes sense on TYPO3 v12 and v13 depends on the scope of the project. For a single event page, a small content element with a data attribute and 30 lines of JavaScript is enough, completely without extension overhead. For editorial teams with many events that want to maintain the timer themselves on a regular basis, an extension is justified because editors need a familiar UI element in the backend.

In practice, Gosign builds both: for one-off launches we deliver a lean content element without an extension that consists only of a Fluid template and minimal JS. For recurring use cases we integrate a maintained extension and override the Fluid template to adapt the design to the rest of the project. When upgrading old countdown extensions, a switch to the vanilla variant almost always makes sense, because jQuery-based legacy versions can neither keep up with TYPO3 v12 nor with modern performance budgets.