Autoloader Cache is not updated
The autoload registry contents are stored in a separated PHP level caching in TYPO3 4.6.
There are already several mechanisms to flush the cache, e.g. on installing a new extension.
However, during development (and also maybe during TYPO3 Source Updates) new classes in the registry files are not considered.Now, there are several ways to solve that:
- if we rely on the extension manager to flush the cache on updates, we just would need the cacheIdentifier contain e.g. the TYPO3 version number
- if that does not help, we need a way to find out whether a registry file was modified (e.g. MD5 hash of that file)
- if that all does not help or is too expensive, we could use a lifetime for those caches (of course does not help during development and patch reviewing)
[BUGFIX] Autoloader Cache is not updated
The patch adds the current TYPO3 version to the cache identifier.
This ensures a new cache file if upgrading TYPO3.
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn
Reviewed-by: Susanne Moog
Tested-by: Susanne Moog
#2 Updated by Christian Kuhn about 8 years ago
@Oliver: I'd strongly recommend to abandon this change set.
I've instead now pushed https://review.typo3.org/#change,3911 The patch enables usage of the NullBackend for the phpcode cache to easy development on a dev system. This is also very useful for the new language cache ...
I've also documented this switch in the caching framework documentation at http://wiki.typo3.org/Caching_framework
#3 Updated by Oliver Hader about 8 years ago
I know that each check (and file system operation) on each request slows down the scenario. So, see it as a draft...
We should however still consider these stories:1) "As developer I want to test the feature at https://review.typo3.org/#change,3359 which add a new class file to TYPO3"
-> seems to be okay, since most developers should be able to handle that
- either set the NullBackend
- delete files in typo3temp/cache/
Suggestion: Since we already have the hardcoded context "production" we could move that to config_default as all - and hard "development"
2) "As TYPO3 integrator and editor I want to check out the most recent version of TYPO3 and upgraded locally from TYPO3 4.6.0 to 4.7.0alpha2"
-> probably the system is running in production mode and new classes in the next TYPO3 version will stop the system from working
Suggestion: Add TYPO3 version number to cache identifier
- drop my MD5_file() stuff in the recent patch
- introduce context mode to TYPO3 - production/development
- add TYPO3 version number to identifiers of system wide caches
#4 Updated by Björn Pedersen about 8 years ago
Story 2) could be taken care of by the upgrade wizard in the install tool, as this wizard is needed on major version upgrades anyway ( DB schema changes...).
so: add a clear all (low-level) caches to the install tool ( should also clear e.g. the RTE cache and the temp_cached_ files).
This way, we don't need a version number anymore.
#6 Updated by Christian Kuhn about 8 years ago
Your suggestions are great! Actually, I introduced the TYPO3_version addition to the identifier before I read you post of this issue again (see latest patch version in gerrit).
And yes, we are on the same track with the production / development context thing, but I think we need a broader implementation and interface for this (I'd love to have it!). We are currently beyond 4.6 feature freeze, so a solid implementation will not make it for 4.6 anymore. For 4.7 we have plans for a better bootstrap, and this one could possibly consider a context as well. So, I'd like to shift the context thing a bit and maybe work on it for a later version, the caching framework even has methods for it.
Imho the current patch set should do for 4.6, we can ease the development issues with a later version.