[TYPO3-commerce] SVN version of commerce disables page cache completely

[Ingo Schmitt]

Hi Dmitry,
> Hi!
> 
> I got SVN version of commerce extension. Could not use 0.9.2 because it 
> does not use t3lib_div::makeInstance to create tx_commerce_category. 
> This is partially fixed in SVN but now SVN introduced much worse things.
> 
> I clicked on the link to page that displays product list. In the 
> debugger I see that tx_commerce_pi1::init() calls $TSFE->set_no_cache() 
> twice. Freshly added code, it did not present in 0.9.2. You are aware 
> how bad is set_no_cache(), it was already discussed in this list.

Yes, it was already discussed in the list and I don't really have a 
solution that will work for me. If you look in the Code, the 
$TSFE->set_no_cache()  is only called, if someone tries to display a 
product which is not under your staring point of your commerce plugin. 
So, I think he or she tries to fake product ids or categories ids, which 
might not be correct or try to hack the extension. This was the case in 
one of our installations.
So I think, normally these code parts won't be executed anyway, and if 
it executed, it's totally correct to set no_cache to be shure to display 
  the right content and to be shure that it's not cached or indexed.

> 
> I just want to show product list. I am not logged in, I do nothing 
> nothing special that requires disabling cache. Can you explain why you 
> have to disable page cache in this case? Why you do not rely on 
> pi_checkChash instead? Imagine what will happens in a shop with large 
> visitors number. 0.01 requests per second because of set_no_cache()? 
> Damn slow for a good shop.

Do you have an other solution for my problem above? I'm willing to 
change it, but currently I don't have a better solution.

> 
> Also there is a code like:
> $this->category-> getAllProducts(9999999999)
> 
> What is 9999999999? It is greater than maximum integer value in PHP, 
> which is 2^32-1 for 32-bit platform, and in fact you may pass float 
> number to function, which may give unpredictable results. Possibly you 
> should use PHP_INT_MAX constant instead?
> 
Oh, I didn't know this. But it's changed now in SVN.

> I understand that it is SVN version, not released version. But if you 
> wrote such code, it may appear in the released version (otherwise why 
> did you write it?). I really hope it will not! Many people depend on 
> this extension, so this extension really cannot afford such mistakes!
> 
> I appologize for may be a bit strong message but I have to use this 
> extension and I really care about its quality. I really want it to be 
> better. Please, fix this ASAP. I would be happy to give you a patch but 
> I cannot do it because I do not understand what exactly you do in those 
> places and you do not have any comments in the code to explain it. I 
> just found problems and want to point them to you. Hope this helps you 
> to make commerce better.

We do want to improve commerce. And I personally like some feedback 
about our code and please do share the thinks you are discovering with 
us. But maybe not so strong the next time, or just skype me, I maybe 
could help you with your problems in the code faster...

ingo

> 


Mit freundlichen Gruessen
-- 
Ingo Schmitt                        mailto:is at marketing-factory.de
Marketing Factory Consulting GmbH   http://typo3.marketing-factory.de/
Content Management mit Typo3: Beratung - Schulung - Realisierung