OpenCart Community

Hello!
I have ocStore 3 and I tried to use this guide: http://octurbo.com/caching-opencarts-category-counts/
After that pagination disappeared and filters doesnt work. But I still can surf through pages adding ?page=XX and apply filters modifying link.

What can I do to make everything work fine?

well, undo it and disable category product count in admin, silly to show those counts anyway as no customer is interested in those unless they are in the product counting business.

That solution seems nice but it has no provision to replace the cache file in an expiration date or if data in the database changes and from what I can see actually slows things down.

If you want to cache DB queries, I can recommend you my Database Cache extension. It will not just cache category products count, but all DB queries, which greatly increases the overall speed. Have it running on a few stores with 100K+ products and it works pretty good so far. It's free, so you can just download and try for yourself.

Not sure why you copyright this extension.

Copyright (C) 2011-2019 The Krotek. All Rights Reserved.

it is literally 90% copied from the equally named extension by pnsols
You can take that up with them.

Besides, for normal stores the overhead will vastly outweigh the benefits and the benefits are very limited.

Any query other than select,show tables or show columns will render the cache involving any of the tables referenced in that query obsolete.
Since OC updates the product table after every select to increase the product view count, almost any cache is immediately obsolete and as such this script is more busy writing and discarding caches than it is using them.

letxobnav wrote: ↑

Sat Aug 17, 2019 2:22 pm

Not sure why you copyright this extension.

Copyright (C) 2011-2019 The Krotek. All Rights Reserved.

it is literally 90% copied from the equally named extension by pnsols
You can take that up with them.

He abandoned this extension and knows I got it from now. And actually it uses a 3rd party caching algorithm from the start.

letxobnav wrote: ↑

Sat Aug 17, 2019 2:22 pm

Besides, for normal stores the overhead will vastly outweigh the benefits and the benefits are very limited.

I don't know what you call a "normal store", but it GREATLY increases the speed of highly loaded stores with lots of products and heavy themes.

For those, just looking for solutions, not arguments:
Caches category data for Opencart 3.0 to make it faster
https://gist.github.com/weismannweb/8ad ... 8d751281b2

just turn it off, no self-respecting e-commerce site would even consider showing product counts on menu's.

and if you insist then just cache the entire menu structure in the common/menu controller with only language as variable.

He abandoned this extension and knows I got it from now. And actually it uses a 3rd party caching algorithm from the start.

fair enough but if you want to continue to peddle this thing, either make provisions for:

1) multi byte character support which it does not have and causes errors
2) most importantly cater for the fact that OC updates the view count in the product table on every product request rendering the caches useless.

or at least mention these issues.
With those solved it could actually be a good one, for high traffic sites that is.

Ideally OC should have never put that field in the product table as it currently also renders any mysql query cache referencing the product table useless.
Taking that field out into a separate table is easy and necessary.

even i was looking for this response. Thank you.

Taking that field out into a separate table is easy and necessary.

Or, since the parent categories are already dependable on the main categories to optimize the category table, to simply regroup the category counts by cat parent cache or by visible cat cache.

That field was about the "viewed" field in the order table.

The fact that OC updates that field every time a product if viewed and as such the product table, renders "his" db cache extension rather useless as well as any mysql query cache as they are flushed with an update.

So my point was to move that field into a separate table so that the product table is not updated every view with this useless field and thus the caches extension-wise or mysql-wise become relevant and useful again.