---
title: "Caching"
manual: "TYPO3 EXT:thuecat"
version: "6.0"
permalink: "https://docs.typo3.org/permalink/werkraummedia/thuecat:frontend-output-caching@6.0"
source: "Integration/FrontendOutput/Caching.rst"
rendered: "2026-10-14T06:55:32+00:00"
---

# Caching {#frontend-output-caching}

Lists are cached so a visitor rarely waits for one to be built twice.
Three caches do the work, all in the `pages` cache group.

## The three caches {#frontend-output-caching-caches}

-   **`tx_thuecat_teaser`**

    One rendered list item, keyed by the record, the detail page it links to and the language. An
    attraction shown by several lists — filtered, curated, on different pages — is rendered once and
    reused by all of them.

-   **`tx_thuecat_list`**

    A whole rendered list, keyed by the plugin, the filter selection, the pagination page and the
    language.

-   **`tx_thuecat_searchmask`**

    A rendered filter form, keyed by the plugin, its page, the selection and the language.
    Deliberately not by the pagination page, so paging through results reuses one form.

## Invalidation {#frontend-output-caching-invalidation}

Because the caches belong to the `pages` group, everything that already clears page caches
clears these too: the **Clear cache** buttons in the backend, and any editor saving a
record. Editors need do nothing differently, with the one exception below — a changed attraction,
town or category takes its cached output with it, and the next visitor sees the new content.
Saving a list plugin discards every list it stored, so a changed setting such as the sort order
shows on the next request.

Entries are discarded by the records they show rather than by age, so nothing goes stale waiting for
a lifetime to run out. A filter combination nobody has requested before is still built from scratch,
but only its unseen items cost anything: the rest come from the teaser cache.

> [!IMPORTANT]
> Re-sorting attractions in the backend discards only the stored list pages that showed a moved
> attraction. A list in backend order can keep a page that never showed it, and that page then
> repeats one attraction and misses another. Clear the frontend caches after re-sorting. The next
> import run rebuilds the lists as well, see the note below.

## Lifetime {#frontend-output-caching-lifetime}

The three caches configure a lifetime of one year. This is not a staleness setting — invalidation by
tag is what keeps content current — it exists because TYPO3's default would otherwise expire entries
after an hour.

Override it per cache in [`ext_localconf.php`](https://docs.typo3.org/m/typo3/reference-coreapi/14.3/en-us/ExtensionArchitecture/FileStructure/ExtLocalconf.html#file-extension-ext-localconf-php) or [`config/system/additional.php`](https://docs.typo3.org/m/typo3/reference-coreapi/14.3/en-us/Configuration/Typo3ConfVars/Index.html#file-project-config-system-additional-php):

```php
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']
    ['tx_thuecat_teaser']['options']['defaultLifetime'] = 3600;
```

Shortening it only costs rebuilds without making anything fresher.

> [!NOTE]
> An import currently discards the caches of every record it visits, whether or not that record
> changed, so lists are rebuilt after each import run. A known limitation, to be addressed
> separately; it costs speed, never correctness.