Hello again, thanks for the tip. I talked to my host and I was given instructions about how to do it myself. I set it to 16mb. We'll just have to wait and see what happens.
Do we know what the default size is before setting it manually?
Default mysql max_packet_size is 16MB but most hosting environments have a PHP max_post_size (could be different name) of 8MB. The two need to be in synch.
My host, suggested that initial value was just 1mb. I really hope this was the issue. What I hate is that you pay 300 euros, spend hundreds of hours on cscart and still encounter issues. 
@scooterlord,
I hope you agree with me, that such kind of issue can happen with any other ecommerce solution. To avoid such problems CS-Cart published the list of compatible hosting providers.
…still getting the error. Any other ideas?
@scooterlord,
Finally was the value of the max_packet_size setting changed? Did you checked it in the phpinfo ?
Yup. 16mb
I'm lost on this. Not sure how it got routed to a max_packet_size in mysql. The issue is that you are getting data in an ajax response that is unexpected. The solution is to
- find out what that data is by using firebug or other diagnostic tool to look at the XHR responce.
- Once you see what's there (probably an error/warning message of some kind), go address that issue.
…I can fix this issue but switching to file cache, delete cache, revert back to mysql, delete cache again. But I can't be doing it this every time nor can I check what's wrong. I have already posted above the error:
Warning: Error while sending QUERY packet. PID=494498 in /homeobooks/app/Tygh/Backend/Database/Mysqli.php on line 81
Fatal error: Call to undefined method Tygh\Backend\Database\Mysqli::_connect() in /homeobooks/app/Tygh/Backend/Database/Mysqli.php on line 87
I don't know what I am supposed to fix. Nor should I have to.
Why are you using mysql for cache? Using the same DB to cache data from the DB is prone to race conditions. Strongly suggest you use file. In V3 and beyond, file works well.
…I am on webfaction, actually a super-fast hosting service. I am on 4.0.1 because I had issues upgrading to the following versions - currently and SUPPOSEDLY being looked by the greek cs-cart team.
I don't know if this is an issue of 4.0.1, changelogs are so incomplete, but the file caching created hundreds of thousands of files within just a couple of days; the result was for the whole server to bend to its knees.
With the help of webfaction staff, we created a private mysql instance, we installed sqlite, redis, we created a sumbolic link for photos, we switched to fastcgi… I mean, we literally tried EVERYTHING possible. With all the files from the cache, the result was a slowdown of all the other hosted sites INCLUDING cscart. I have like 20 websites on my account, there are like 50 more accounts on the server, and cscart created problems for the whole server.
So, only thing that works, and works ULTRA-fast is mysql caching - db size increases up to 400mb and that's about it. If it wasn't for the damn json problems, everything would be fine. Except of course the fact that I am stuck with 4.0.1 and not 4.1.2. For which I was just a reseller, and I have already spent a year of my time listening to the client's nagging - and he is right - and still after a year problems haven't been solved.
Understand your frustration… But if you are doing ajax requests that are measured in MB then that's a separate problem.
If using 'file' caching is not an option for you, then you should work with cs-cart help desk on this issue.
Make sure you have init_set('display_errors', false) where appropriate.
I would not use fastCGI and you should be using mysqli for performance reasons.
If you are a reseller then I would raise the red flag with the sales team rather than the support team. They can get much better response internally than you'll ever get through a support ticket.
How can a request be measured? And, why would it take 'special care and love' to work? Shouldn't it be build in a way that it should just WORK? The site is no big deal, 2 filters, 500 products. Why wouldn't this be handled with ease?
However, thanks again for your reply. Having tried all the above, using fastcgi works faster.
At this point, performance-wise it's as fast as it should be, as long as there aren't any problems.
Also, when I was talking about the greek team, I meant the sales team - who are trying to solve this 'internally'.
Hey i have a solution for it. I faced same issue. It is the bug in cpanel file editor
Just open config file. You will see some blank apace before