TYPO3 Core

When EXT:workspaces is installed, every frontend request where a BE user is logged in, triggers a TRUNCATE on both cache_rootline and cache_rootline_tags. This causes this cache to become empty for any subsequent frontend request, which causes terrible performance with multiple unnecessary SQL requests.

Additionally, it may cause the rootline cache to contain incorrect information (cache entries generated based on workspace state will be fetched by subsequent requests causing things like rootlines or access checks to potentially fail).

The problem occurs because \TYPO3\CMS\Frontend\Middleware\PreviewSimulator::checkIfRootlineRequiresPreview will indiscriminately flush this cache in the "finally" block of an exception catch, without any regard for whether or not a workspace other than LIVE is actually active.

Both of these problems - as well as multiple other potential cache-related problems stemming from the need to preview workspaces - may be completely circumvented by allowing CacheManager API to replace an active cache. The idea being that instead of indiscriminately flushing this and other caches, the cache backend can instead be replaced with a NullBackend on-the-fly when \TYPO3\CMS\Frontend\Middleware\PreviewSimulator::checkIfRootlineRequiresPreview determines that a workspace preview is necessary. Plus, only replacing these cache backends BE user's selected workspace is a non-LIVE workspace.

Doing so would mean that:

• There are no possible issues from a cached value that doesn't match the workspace state.
• The performance hit is isolated to whenever a workspace preview is actually happening.
• The actual cache is preserved and remains unmodified, removing the negative impact on other requests.
• No entries will be written to the substituted caches, removing the risk of retaining cached data that applies only to a workspace.