Doesn’t work with lots of items

Do you get an error message in your debug.log if you enable WP_DEBUG and WP_DEBUG_LOG?

Please post your WC System Status Report (using https://pastebin.com/ for example).

Hi there,
Here is the debug recorded during the error forcing.
https://pastebin.com/nihXMxu1

Do you want one for the same action but with the shortened cart link that works?
thanks,
David

Please update your outdated theme first.

Hi there,
I will have to take in looking into that, it has been modified over the years and will not likely be a simple affair.
But if your instinct is towards that I shall endeavour to do so.
Thanks,

You must never edit 3rd party theme files directly! That’s what child themes are for.

https://developer.www.ads-software.com/themes/advanced-topics/child-themes/

…you can still test it though;

1. Create copy of your edited theme
2. Overwrite with the newest version
3. Test
4. Restore the copy of the edited theme

Thank you for what I am sure is good advice that I will look into, but hindsight is a wonderful thing ??

Sometimes you are just rushing to get a business going and whilst I wouldn’t have set out to knowingly do it the wrong way, you just do it the way you can ??

Been there ??

Hi mate,
I took a lot of time updating our theme with no resolution to the problem with your plugin.
In fact having updated our theme there were no errors at all in the debug.log when the error was simulated.
I mentioned it to a friend of mine, he is the chief architect of a product called Channel Unity, essentially a tool which integrates market places into ecommerce solutions, he looks a bit like Millhouse off the simpsons, so you get the picture.
He had this to say :
“2019/02/05 13:02:24 [error] 19091#0: *220402 upstream sent too big header while reading response header from upstream, client: 88.215.45.113, server: growinsane.com, request: “GET /cart/?fill_cart=50×33008,100×34060,10×58720,100×58742,5×58752,100×63366,25×52332,45069,100×63740,100×55915,100×63749 HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php/php7.2-fpm.sock:”, host: “www.growinsane.com”

That is telling us that the plugin sent some output, but that output was larger than the maximum allowed size. It’s weird it would try to return information in this way.
I increased the webserver buffers and this fixed the problem, please give it a test.
”
Well after that, I tested it and all was well.

This fits in with the description I gave you at the start that URL length seemed critical. I am surprised you have not encountered this issue or did not recognise it as it will be a problem for any user with long URLs with what I assume is a default buffer length. My business is more likely to encounter this than others as my customers typically buy a lot of items per order which is much less common than most e-commerce stores so perhaps this is why it didn’t jump out to you and you have not encountered it. I am guessing it is too difficult to implement a work around as it obviously isn’t the logic of your code that is at fault rather the circumstances it may find itself used in. Still you will at least be well placed now to recommend a solution if you hear similar reports of long URLs failing with a gateway 502 error.

Thanks

Thanks for the detailed report. Yes, I notice that for every product in the url WooCommerce sets a new cart cookie to the response; resulting in duplicated cookies in the header which isn’t a problem…. unless you reach such a limit as it seems.

I will see if I can apply a fix for this; but I won’t give this high priority because you have a workaround already and you’re the only one having this issue (for now).

Just a bit more information from my friend that may help if you ever decided you wanted to tackle this more fully :

”
There are a lot of options in the nginx webserver, and I don’t fully understand a lot of them, but in this case it was to do with the pipeline of PHP processing.
The webserver (nginx) passes a request for any PHP file through to PHP-FPM. This is the PHP interpreter, it runs the code, but in doing so gets some output back. This is called a buffer or proxy buffer, and it defaulted (I think) to 4k bytes. My understanding of what happened here is that the data generated (by the cart builder plugin) was over 4k and it went over the maximum buffer size.
My only guess is it’s outputting a lot of debug information. Plugins don’t normally cause such buffer size errors.
I’ve setup some larger values in the web server settings, and so it should be all fine for the future.

If the guy is interested, these are the lines I had to add to the nginx server configuration:

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
”

Thanks,