Skip to content

TYPO3 CMS "clear cache" buttons explained

With TYPO3 CMS 6.2 the "clear cache" toolbar buttons have changed. But what actually hides behind each button and when do I need to click which button?

"clear cache" buttons of TYPO3 CMS

I keep asking this myself all the time and usually I finally hit all of them. But wait... maybe this is not the best idea on earth, since there wouldn't be 3 of them if one is supposed to click all of them all the time. So let me dive into the magic world of TYPO3 CMS caches with you and lets discover the idea of those buttons.

(You only see two buttons? You're probably not in Development-Mode; enable the Developer-Preset in the Install Tool.)

Caches of the Core

Maybe you don't even want to know that, but still I'm providing this here. The TYPO3 CMS Core has quite a lot of caches in use by default:

  • cache_core
  • cache_classes
  • cache_hash
  • cache_pages
  • cache_pagesection
  • cache_phpcode
  • cache_runtime
  • cache_rootline
  • cache_imagesizes
  • cache_treelist
  • cache_md5params
  • l10n
  • fluid_template
  • extbase_object
  • extbase_reflection
  • extbase_typo3dbbackend_tablecolumns
  • extbase_typo3dbbackend_queries
  • extbase_datamapfactory_datamap
  • workspaces_cache

Those caches are organized in so called cache-groups, where each cache can be part of none or more groups. The group structure allows to flush all caches of a group at once with a single command. The default groups and their members are:

  • pages: cache_hash, cache_pages, cache_pagesection, cache_rootline
  • all: same as pages + workspaces_cache, cache_treelist
  • lowlevel: cache_imagesizes
  • system: all remaining caches

"cache_runtime" and "cache_md5params" are not member of any group. "cache_runtime" is only existing throughout a request, hence, clearing it would be pretty pointless. "cache_md5params" is for Frontend redirects and maybe cleared only via the CleanUp section of the Install Tool.

At this point you might already have an idea what those mysterious buttons in the Backend actually do. Each of them simply flushes one of the above groups.

"Flush frontend caches": This clears all caches of group "pages"
"Flush general caches": This clears all caches of group "all"
"Flush system caches": This clears all caches of group "system"

The "lowlevel" group is actually unused in Core. The only member "cache_imagesizes" is automatically managed by the \TYPO3\CMS\Core\Imaging\GraphicalFunctions class. There is no way to clean this cache except by accessing the database directly.

So the whole magic around those buttons is as simple as that, but...

Which one do I press now?

Ah yes, that's why I'm writing this actually.

For really understanding that, we need to know exactly what every cache actually is there for so we can conclude which button has the least impact.
Don't worry, I'll not bore you with those internal details here, rather I'll go for providing some common usecases and will tell you, which button is the right one and causes the least work for the system to rebuild caches. Here we go.

  • Changing a page or content on a page: Usually nothing to do, because the Core already takes care of clearing the appropriate caches. (Side note: You might need to configure page TSconfig TCEMAIN.clearCacheCmd from time to time.)
  • Updating the (TypoScript) template: Clear Frontend caches
  • Changing a language file (eg .xlf): Clear System caches (to reload the language files) AND Frontend caches (to refresh FE output)
  • Changing a Fluid template: Clear System caches (to re-parse the template) AND Frontend caches (to refresh the FE output if the template is used on a cached page)
  • Changing the TCA: Clear System caches
  • Changing ext_tables.php or ext_localconf.php of extensions: Clear System caches
  • Changing code in a cached Pibase plugin: Clear Frontend caches
  • Changing code of an Extbase plugin: Clear System caches (to update the reflection data)
  • Adding/Removing classes in code files: Clear System caches (to flush the class loader cache)
  • Changing sprites: Clear System caches

A note about performance: Up to TYPO3 CMS version 6.2.10 and 7.1 clearing the System caches  was really expensive since the cache_classes (class loader cache) is in this very group and was emptied therefore as well. Regenerating all this class information for all Core classes and all extension classes can really take quite a while and locks down the complete website in the meantime. Since 6.2.10 the class loader is now split into two parts, the new part being the composer class loader, which statically loads all Core class information upfront. Therefore clearing the System caches is much cheaper now, but don't forget that all Extbase classes still need to be re-parsed for reflection information.

One more thing...

There is of course another "Clear Cache" button (or even two in some cases). I'm talking about those in the Install Tool.

If your server is running an Opcode-Cache for PHP, the Install Tool provides a dedicated button ("Clear PHP opcode cache") to forcefully flush/invalidate this cache. The code behind this is the OpcodeCacheUtility, which takes care of all the nasty details of the available Opcode-caches. You only need this button actually if your Opcode-Cache has a faulty configuration and it does not detect changed PHP files. This will usually only strike you when updating the Core for instance.

The second button, which is always present, is labeled with "Clear all cache". One might ask: Is this the same as pressing all three buttons from above or are there even more caches?
The answer is Yes and No! No, not another cache. Yes, it does the same as those three buttons, but it does even more.

I'm citing the comment from the code: "This clear cache implementation follows a pretty brutal approach."
The code does not query each cache and tells everyone that it has to flush, but rather strips away the data source below their "feet". That means it truncates the typo3temp/Cache directory as well as all database tables prefixed with cf_. The experienced TYPO3-geek might now notice that there are still tables in the database, which have prefix cache_, this is very true and indeed this "brutal" function does not touch them, because those are not critical for running the Backend of CMS.
Still, after doing the brutal actions, the function does one more thing. All caches are reloaded - with possible configuration changes by extensions - and each of them is asked to flush again. This will finally also wipe out all remaining caches like cache_* tables and alternative cache backends such as Redis, Memcached, APC(u), etc.

Luckily, the second button keeps the promise and really clears all caches.

 

This information applies to TYPO3 CMS versions 6.2 to 7.2

Back