Bug #82828
open
stdWrap.cache doesn't use cached entries
0%
Description
Tried to use stdWrap.cache on different instances (TYPO3 7.6.23 and 8.7.8) according to https://docs.typo3.org/typo3cms/TyposcriptReference/7.6/Functions/Cache/ But the content is rendered for each page instead of sharing it with other pages.
Also the exact example doesn't work:
page = PAGE
page.5 = TEXT
page.5 {
stdWrap.cache.key = mycurrenttimestamp
stdWrap.cache.tags = tag_a,tag_b,tag_c
stdWrap.cache.lifetime = 3600
stdWrap.data = date : U
stdWrap.strftime = %H:%M:%S
}
Updated by Susanne Moog about 7 years ago
- Status changed from New to Needs Feedback
Can you check if the following works for you:
page.10 = TEXT
page.10 {
cache.key = mycurrenttimestamp
cache.tags = tag_a,tag_b,tag_c
cache.lifetime = 3600
data = date : U
strftime = %H:%M:%S
}
I think there is a documentation change missing since https://review.typo3.org/#/c/35915/15 was merged.
Updated by Julian Hofmann about 7 years ago
Thank you, your snippet works and I could solve my usecase.
But I think, it is not only a missing documentation change.
"cache" is currently documentated under "Function" (with wrong example), but also as Property of stdWrap (with link to cache function). So, the stdWrap.cache example should work, too. Or is there no cache-property in stdWrap anymore? But stdWrap.cache is writing to the cache (or at least stores the cache-identifiers) but doesn't get data from the cache.
Updated by Susanne Moog about 7 years ago
It does get data from the cache but due to the execution order of the stdWrap properties the data gotten from the cache gets overwritten by the subsequent stdWrap calls. If I understand the history correctly before the change the "cache get" stopped the execution of the subsequent calls while now the result from "cache get" gets set as value and is then used in further potential processing. I'm not sure which way is more / less correct or what the intended behaviour was. I'll try to figure it out.
Updated by Frans Saris about 7 years ago
Looks like the documentation is outdated and should be updated. See comment in the breaking.rst https://review.typo3.org/#/c/35915/15/typo3/sysext/core/Documentation/Changelog/master/Breaking-64200-CustomCObject.cache.TypoScriptEvaluation.rst
Updated by Stefan Neufeind about 7 years ago
- Category set to Documentation
- Status changed from Needs Feedback to Accepted
So this makes it a documentation-issue then. Thanks - updated.
Updated by Julian Hofmann about 7 years ago
No, it is not just a documentation thing.
The breaking.rst says "``stdWrap.cache`` continues to exist and can be used as before." - this is not true. It is not working like before.
The break is discribed for cases where "you've previously used the ``cache.`` property in your custom cObject", not for normal (non-custom) cObjects.
Updated by Garvin Hicking 5 months ago
- Status changed from Accepted to Needs Feedback
Hi Julian,
I would somehow like to wrap (haha) this up but am having a bit of difficulty seeing how to properly adjust this and were.
Do you maybe have a suggestion on what to (retro-actively) change in the breaking.rst as well in the docs of https://docs.typo3.org/m/typo3/reference-typoscript/main/en-us/Functions/Cache.html#cache-1? The text there is unchanged compared to 7.6 so I do think we could improve this there?
Regards,
Garvin
Updated by Julian Hofmann 5 months ago
Whew. A lot of time has passed...
If I read this correctly, then stdWrap.cache has simply stopped working since the change. At least no longer for reading cache contents (or is overwritten again).
It would therefore be worth considering whether stdWrap.cache is still of any use at all.
Alternatively, it should be documented that it can only be used to fill the cache (whereby the question arises as to how/where it can then be read out again)
Updated by Garvin Hicking 5 months ago
I've asked lolli since I sadly can't answer if/how/where stdWrap.cache is utilized or useful, so sadly can't really contribute here and hope it gets picked up by someone who uses stdWrap.cache :)
(Leaving this open for a while)