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)
Updated by Christian Kuhn almost 10 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
Updated by Oliver Hader almost 10 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
Updated by Björn Pedersen almost 10 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.
Updated by Christian Kuhn over 9 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.