Bug #100360
open
Cache is not invalidated for referenced content via "Insert Records" / Shortcut CE
Added by Henrik Ziegenhain over 1 year ago.
Updated 6 months ago.
Description
Hi everyone,
we recently stumpled upon a very annoying issue, that got not noticed since some time (years, ever?!)
The page cache is not invalidated, if there are shortcut content elements and the referenced element got changes.
Steps to reproduce:
- Insert a common content element on "page 1"
- Insert a shortcut CE on "page 2" and select the recently added content elment from step 1 as reference
- open new Browser or Incognito Tab
- navigate to "page 1" and "page 2"
- (have look to database and verify, that both pages got cached)
- edit the original CE on Page 1
- reload "page 2" frontend in incognito Tab
- see, that nothing changed
- open "page 1" frontend in incognito Tab - on this page everything is fine, caches got invalidated
This is reproducable on v11 and v12.
This issue gets even more complicated, when one of the extensions Container, Gridelements or Flux are in place.
In this cases child records need to be observed for changes as well. Likly the parent elements get referenced.
Kind regards
Henrik
Related issues
1 (1 open — 0 closed)
- Related to Bug #91561: Lifetime of cache is not properly computed for "Insert Records" CE added
We solved it currently with a custom Hook to DataHandler.
First: we set custom cache-tags
# Add CacheTag to Shortcut Elements
# We need to clear this cachetag on every content edit, to ensure, that referenced objects get updated asap
tt_content.shortcut {
stdWrap {
addPageCacheTags {
stdWrap.cObject = TEXT
stdWrap.cObject {
dataWrap = shortcut_{field:records}
}
}
}
}
Second: Use a hook to flush the custom cache-tags
In our scenario we had to respect child-elements in EXT:flux context. The same would apply for EXT:container and EXT:gridelements.
But I think, this is something that has to be handled by the third party extensions, once the cache tag is set by core.
See https://gist.github.com/h3nn3s/b829b9dada68b84fefbd3a0ac2f42786
- Status changed from New to Needs Feedback
while this issue is valid, I tend to close it - especially for bigger sites, cache invalidation always needs a lot of insights on the project itself.
regarding flux/container/... I suggest that those extensions should hook into cache clearing and extend caches to the relevant pages - or someone writes an cache clearing ext which covers "all" usecases.
is that ok with you?
Hi Georg,
for the extensions I share your opionion. This should be handled by the extensions itself.
For the core-part this should be invalidated by core automatically.
This is how you can add a page cache tag for referenced tt_content records.
tt_content.shortcut {
variables.shortcuts {
conf.tt_content.stdWrap.addPageCacheTags = tt_content_{field:uid}
conf.tt_content.stdWrap.addPageCacheTags.insertData = 1
}
}
When you edit the referenced record, then the page cache is flushed correctly. Beware: The referenced record must be visible, else no cache tag is added.
You can also use the raw record field. This way, the visibility of the referenced record don't care and cache tags are always added:
tt_content.shortcut {
variables.shortcuts {
stdWrap.addPageCacheTags.field = records
stdWrap.addPageCacheTags.split {
cObjNum = 1
1.current = 1
1.wrap = tt_content_|,
}
}
}
Both tested in 13.0.0-dev
- Status changed from Needs Feedback to Under Review
Also available in: Atom
PDF