[TYPO3-commerce] $GLOBALS['TSFE']->set_no_cache() --> bad practice --> why using it?

[Franz Koch]

Hi Ingo,

> The calls to $GLOBALS['TSFE']->set_no_cache() in PI1 are only made, if 
> someone tries to pass wrong parameters to the Frontent-Rendering. 

well - but then there seems to be a bug, because my "blank" main page of 
the shop with only the category listing always throws a set_no_chache.

The no_cache option in my case is set, because the security checks in 
the following lines fail:
- 138,139,140,143
- 159

The first part might fail because my shop doesn't provide any article in 
the first two category levels. The last fails because of a missing 
catUid in piVars - but such a piVar is never set on the default main page.

Is this then more a misconfiguration of my shop or more likely a bug?


> This happened in our installations by "brute-force" or by setting wrong links 
> by Editors. Without the no_cache parameter you'll have a possibility 
> that the wrong content is shown in the page and the parameter are cached 
> by realurl and the whole think gets stuck. Also, if 
> $GLOBALS['TSFE']->set_no_cache() is set, no indexing is made by 
> indexed_search.

But there must be a different way. Does anybody know if setting the 
following to values would also prevent realurl caching and indexed 
search caching?
---
$this->pi_checkCHash = true;
$this->pi_USER_INT_obj = true;
---

I mean - if it's declared as USER_INT it should not be cached. Question 
is if this setting forces the same then setting the extension by default 
to USER_INT.

And I still don't think that setting no_cache is necessary. I understand 
your concern, but your described problem would be not only commerce 
specific which means that the whole caching-system of TYPO3 is buggy. If 
so, I clearly vote to get in touch with the core team to finally get a 
working caching system. I think Dimitry Dulepov mentioned that he might 
do some research and changes to the caching-system. So please post your 
concerns to the dev-list!


> $GLOBALS['TSFE']->set_no_cache() is only set, if the given parameter of 
> catUid or singeUid don't match to the given starting category uid you 
> have defined in TS or by flexform. Normally this should not happen and 
> therfore this part of the extension shouldn't be called.

Well I configured the catUid in TS, but as described above - the main 
page of my shop generates a set_no_cache.


> So why bother on this issue concerning wrong parameters?
because it doesn't fully work as intended ;)


> after Peters posting. Concerning the clear basket link i have to 
> investigate further, since I must be shure, that the baskethash is 
> cleared also, to have not the wrong content of the basket cached.
I modified commerce so that the clearBasket link is a cached link and it 
doesn't seem to cause any trouble (it's USER_INT anyway).

--
Kind regards,
Franz Koch