Feature #70125
closed
Clear code caches automatically if core version changes
0%
Description
While TYPO3 introduced aggressive caching some time after 4.5, it doesn't seem to feature automatic cache clearing on core updates yet. This can lead to a broken installation until the relevant caches have been figured out and cleared manually which is unreasonable when performing central updates for multiple websites (e.g. by symlinking typo3_src to a shared symlink typo3_src-6.2 pointing to the specific shared release). While such symlinks are generally encouraged, having to clear caches manually on all instances should be unnecessary. Before aggressive caching was introduced (e.g. with 4.5) this did not cause any problems at all.
An example of what happens when caches are not cleared automatically can be seen in bug #69619. It does not matter if PHP opcode caching is enabled as the internal caching done by TYPO3 itself breaks TYPO3. Just clearing/disabling opcode caching is not enough, internal caches need to be cleared as well. I think this should not happen with a product like TYPO3 and is an oversight of the implementation of aggressive caching.
It would be better if TYPO3 could detect a change in its core version and clear all relevant caches automatically (TYPO3-internal code/config caches, localization caches, PHP opcode caches). TYPO3 already knows which core version is installed (shown e.g. in BE window title). Any change in version number (upgrades as well as downgrades) should trigger cache clearing in the way it is currently offered as a manual action by the install tool. To be able to do so, the last used version number would need to be saved somewhere (LocalConfiguration?) and checked as early as possible in the application lifecycle.
Automatic cache clearing would only be possible if the code base changes "at once", e.g. by using symlinks, as is the preferred way to install TYPO3. If TYPO3 is uploaded via FTP or similar caches would still need to be cleared manually as code base may not be at one consistent version when cache clearing is first triggered.
Updated by Christian Kuhn over 8 years ago
I don't really like the idea to detect in all scopes (ajax, fe, be, install) if by any chance the core may have been updated and - in the rare case it did - trigger a full blown cache kill. this has lots of problems: for instance it is not trivial to decide where the "current core version" is stored - db won't work since caches are used before db is connected. localConfiguration isn't cool either since this may give problems if the file is not writable in early install tool. and i don't like the idea to store non-configuration-fluent data within localConfiguration.
It is probably much easier if some of the important caches (extbase reflection, cache core) just add typo3_version constant within their cache element identifier calculation. This would automatically lead to new cache entries during upgrade. but it has drawbacks, too, since it may for example trigger a max filled cache system, which is not a cool thing for opcaches for instance.