TYPO3 PageTSConfig clearCacheCmd scope for external content dependencies

Direct Answer

The correct configuration boundary is cache tags registered during page rendering, not manual enumeration of page IDs in clearCacheCmd. In TYPO3 v12 and v13, you link external data changes to page cache invalidation by attaching a unique tag to the rendered page cache entry and flushing that tag when the external record changes.

Confirmed Mechanism

When your extension renders external content during frontend generation, register a tag on the current page cache entry:

$GLOBALS['TSFE']->registerAdditionalCacheTags(['tx_myext_' . $externalUid]);

After the external data is modified, flush every cached page carrying that tag through the page cache frontend:

$pageCache = GeneralUtility::makeInstance(CacheManager::class)->getCache('cache_pages');
$pageCache->flushByTag('tx_myext_' . $externalUid);

PageTSConfig can also reference these tags in TCEMAIN.clearCacheCmd using the tags: prefix, for example:

TCEMAIN.clearCacheCmd = tags:tx_myext_123

This is useful when a DataHandler operation should trigger the purge, but the tag itself must still be registered during rendering.

Resolving Dependent Page IDs

You do not need to resolve dependent page IDs manually. Tag-based invalidation removes every cached page entry that carries the tag, regardless of where it sits in the page tree. If you instead rely on clearCachePages or page-ID lists in clearCacheCmd, you must implement a DataHandler hook that queries every page embedding the external record—a fragile approach in complex trees with plugins, content elements, and recursive references.

Documented Mechanism

Yes. The TYPO3 Caching Framework documents tag-based invalidation, and registerAdditionalCacheTags() is the documented API for adding tags to the current page cache entry during rendering. The tags: prefix in clearCacheCmd is also part of the PageTSConfig reference for v12/v13.

Assumptions and Boundary Conditions

• This assumes external content is rendered server-side during page generation. If the data is fetched client-side via AJAX after the page is delivered, page cache tags will not help; you would need a separate strategy for that layer.
• no_cache prevents new cache entries but does not purge stale entries already stored. Tags handle both existing and future entries.
• Avoid generic tags like tx_myext_all; they flush more pages than intended and degrade performance under load.
• Keep tag names unique and reasonably short to avoid storage overhead and backend truncation risks.

Practical Verification

Create a test page that registers tx_test_999, confirm the cache entry exists in the TYPO3 admin panel, trigger a flush by that tag, and verify that only the tagged page is regenerated while unrelated pages retain their original cache timestamps.

One diagnostic detail would change this recommendation: is the external content rendered server-side during page generation, or fetched client-side after the page is delivered? If it is client-side, page cache tags are not the right boundary.