Bug #78777
closed
TYPO3 plugin without caching
0%
Description
I've written an extension with Extbase/Fluid and this extension has a plugin:
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
'MyVendor.' . $_EXTKEY,
'Pi1',
array(
'MyController' => 'list'
),
// non-cacheable actions
array(
'MyController' => 'list'
)
);
But when creating a link
<f:link.action arguments="{foo: 'bar'}">...</f:link.action>
the resulting url has a cHash parameter:
http://localhost/mypage/?tx_myext_pi1[foo]=bar&cHash=d1768a40d9370f7a8d327043da156a05
Why? I defined this plugin as "do not cache" so there should be no cHash parameter.
When the cHash parameter is set, the page contents are cached, even if the plugin is defined as USER_INT, right?
TYPO3 version is 7.6.12.
Updated by Benni Mack over 7 years ago
Hey Sven,
nope. this is not how it works.
cHash defines that based on the GET variables a different cache entry is set for a page (thus, you can have multiple "cached" versions of a page inside the cache).
So, now, USER_INT / COA_INT are a different story.
The page gets cached (also based on GET vars etc) and a placeholder string is put into the content <!--INT_INC...> (seriously!) and before the page is rendered, the non-cached plugins (and their PHP functions in their purest form) are called and the contents from them are replaced with the markers. This way, the rest of the page (e.g. header footer, text elements) are cached, but the non-cacheable things are added later on.
It's very sophisticated and very powerful, and awesome.
Be aware: cHash (and caching different versions of a page via that) and COA_INT are totally different things and in this situation unrelated.
Updated by Benni Mack over 7 years ago
- Status changed from New to Needs Feedback
So can you explain what is not working? TYPO3 does everything under the hood for you and the cHash is fine here.
Updated by Sven Burkert over 7 years ago
The plugin is working with cHash parameter, but I thought, when there's a cHash, there will also a cache entry be generated. And it seems so: My USER_INT plugin has a pagination. This pagination has links like these:
http://localhost/mypage/?tx_myext_pi1%5B%40widget_0%5D%5BcurrentPage%5D=2&cHash=b343d288de2aa7a17b679d0877610eba http://localhost/mypage/?tx_myext_pi1%5B%40widget_0%5D%5BcurrentPage%5D=3&cHash=ca057415c1c33a09dcb3db1b625158e4
Every time I click on a different page in the pagination, a cache entry in table "cf_cache_pages" is created (the value in field "content" seems to be the same). But, according to your explanation, the page with the USER_INT plugin should be cached only once. My problem with this is, that this table will get flooded with thousands of cache entries of the same page and the same contents.
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Needs Feedback to New
Sorry for the very late update.
Updated by Sven Burkert almost 7 years ago
I think this issue is pretty severe. Shouldn't someone have a look at it?
Updated by Sven Burkert over 6 years ago
I think I see my mistake: In table "cf_cache_pages" not the page content is cached, but the TypoScript configuration for specific parameters. And because the pagination (see my example above) has different parameters, this leads to several entries in "cf_cache_pages".
If this is correct, please close this issue.
Updated by Georg Ringer over 6 years ago
- Status changed from New to Closed
I am closing this issue.
further information to consider: there could be next to the USER_INT plugin also a plugin with parameters which requires a chash, so it is absolutly valid to use a chash by default. you can always disable generating the chash in the link.