--- title: "Examples & presets" manual: "Temporal Cache Management" version: "main" source: "Configuration/Examples.rst" rendered: "2026-10-07T14:40:31+00:00" --- # Examples & presets {#configuration-examples} Complete configurations, and what each of them actually changes. For help choosing between them, see [Optimization strategies](../Performance/Strategies.html#performance-strategies) and [Decision guide](../Performance/DecisionGuide.html#decision-guide). > [!NOTE] > Every example that sets `timing.strategy` to `scheduler`, or routes a > content type to the scheduler through `hybrid`, depends on the scheduler > task. > Read [Scheduler task](Advanced.html#scheduler-setup) first: the task type is registered, but a task > still has to be created in the Scheduler module and run by cron before those > transitions are processed. ## Presets offered by the wizard {#configuration-presets} The Wizard tab of the backend module offers these three presets. The values below are the ones it shows; the wizard does not write them — apply them in the Extension Manager or in `config/system/additional.php`. ### Simple {#simple} Global scoping, dynamic timing, no harmonization — the shipped defaults. ```text scoping.strategy = global timing.strategy = dynamic harmonization.enabled = 0 ``` Every temporal transition flushes every page cache, and the page cache lifetime is capped at the next transition anywhere on the site. Nothing beyond the extension itself has to be set up. ### Balanced {#balanced} ```text scoping.strategy = per-page timing.strategy = hybrid harmonization.enabled = 1 harmonization.slots = 00:00,06:00,12:00,18:00 ``` With `timing.hybrid.pages` and `timing.hybrid.content` left at their defaults, page transitions stay dynamic and content transitions are routed to the scheduler task. The cache lifetime follows the page rule, so it is still calculated on every page cache generation, narrowed to page transitions site-wide plus content transitions on the page being rendered. ### Aggressive {#aggressive} ```text scoping.strategy = per-content scoping.use_refindex = 1 timing.strategy = scheduler harmonization.enabled = 1 harmonization.slots = 00:00,04:00,08:00,12:00,16:00,20:00 ``` The extension stops modifying the cache lifetime altogether. Invalidation happens only when the scheduler task processes a transition, and then it flushes exactly the pages on which the changed content appears, resolved through `sys_refindex`. This is the combination in which per-content scoping pays off — and the one that does nothing at all without the scheduler task. ## Worked configurations {#configuration-scenarios} ### Exact publication times matter {#exact-publication-times-matter} Flash sales, embargoed articles: the transition must happen at the time the editor entered. ```text scoping.strategy = per-page timing.strategy = dynamic harmonization.enabled = 0 ``` Dynamic timing is the only strategy that expires the cache at the transition itself. Harmonization stays off so no timestamp is moved. Scoping is `per-page` because under dynamic timing the scoping strategy only supplies the next-transition timestamp, and `per-page` is the one that narrows that timestamp to the page being rendered; `per-content` would return the site-wide value here. ### Many content transitions, menus must stay current {#many-content-transitions-menus-must-stay-current} ```text scoping.strategy = per-content scoping.use_refindex = 1 timing.strategy = hybrid timing.hybrid.pages = dynamic timing.hybrid.content = scheduler ``` Page transitions keep their dynamic lifetime, which is what keeps menus correct. Content transitions are handed to the scheduler task, which flushes only the pages the content appears on. Note that the lifetime query still runs on every page cache generation: it follows the page rule, and that rule is `dynamic` here. ### Fewer, grouped cache flushes {#fewer-grouped-cache-flushes} ```text harmonization.enabled = 1 harmonization.slots = 00:00,06:00,12:00,18:00 harmonization.tolerance = 3600 ``` Transitions within an hour of a slot are moved onto it, so several records share one transition time instead of each having its own. Records further than an hour from every slot keep their original times. Harmonization is applied when it is invoked — through the **Harmonize selected** action in the Content tab of the backend module, or through `vendor/bin/typo3 temporalcache:harmonize` — not when editors save a record. ### Publication at one fixed time of day {#publication-at-one-fixed-time-of-day} ```text harmonization.enabled = 1 harmonization.slots = 09:00 harmonization.tolerance = 3600 ``` With a single slot, only timestamps within an hour of 09:00 are moved onto it. Raise `harmonization.tolerance` to cover the spread you actually want to absorb; a timestamp at 20:00 is 11 hours from the slot and needs a tolerance of at least 39600 to be moved. ### Multi-language site {#multi-language-site} No language-specific setting exists. Every transition query filters on the language of the current context, and the cache tags the scoping strategies emit are page-based, so language handling needs no configuration. ## PHP configuration {#configuration-examples-php} ### Complete configuration {#complete-configuration} **config/system/additional.php** ```php [ 'strategy' => 'per-content', 'use_refindex' => true, ], 'timing' => [ 'strategy' => 'scheduler', ], 'harmonization' => [ 'enabled' => true, 'slots' => '00:00,06:00,12:00,18:00', 'tolerance' => 3600, 'auto_round' => false, ], 'advanced' => [ 'default_max_lifetime' => 86400, 'debug_logging' => false, ], ]; ``` Every key is optional; the getters in `NetresearchTemporalCacheConfigurationExtensionConfiguration` supply the documented default for anything absent. ### Environment-specific configuration {#environment-specific-configuration} **config/system/additional.php** ```php