markisu72

Hi Joost,

I will check this asap.
It is very cumbersome, though, because I always have to completely reconfigure our system / firewall / CDN for that test and we’re in the beginning of the upcoming Christmas buying frenzy.. it is not a good time to test this (on production)…

I also contacted Zettle support, if there is any means to find out a concrete root/error cause for *why* the image is not being shown, instead of doing some wild guessing on the live system…

They replied twice, that they don’t see any responsibility on their side and I should get in contact with you guys to get more information…
Is there any means to get some more information besides “image is broken / rejected”?

Otherwise it is really trying to find the needle in the haystack…
Thx
Markus

• This reply was modified 1 year, 1 month ago by markisu72.

Hi Joost,

thanks for the feedback.

Regarding “you might need to focus on the WebP images in order to resolve your situation”…

What I wanted to explain in my previous post is, that our setup delivers JPEG or WebP depending on what the _client_ requests… Thus, if Zettle would get a WebP-image, then *Zettle* would have made a http call with a http request header, *explicitly* requesting WebP… if this header was set, but Zettle does not like WebP, it would be a bug on Zettle side. If Zettle is requesting without that header, it will get JPEG, no matter what.

If Zettle would fetch WebP images in our setup, then Zettle is making a faulty request. This is something, we could not fix on our end (except of disabling WebP delivery for everyone altogether, which is no option).

Anyway, I did make a test by temporarily disabling WebP altogether and it did _not_ solve the issue.

I even replaced the new product image with the previous one (which showed in Zettle for more than a year until I changed it) and it still did not show again, as one could expect. Same issue.

So, if it’s not WebP and not the image (because I used one which showed before), what next? How can we get some input about why they don’t show?

Best
Markus

Hi Joost,

ok, how are the images being transferred?
Is the URL being send and Zettle fetches the image via URL or is the image transferred via base64-stream or alike directly via web service?

In the log, I see ‘imageData’ being empty.

All images are available as JPG and WebP in parallel.
They are being served based on the client’s capabilities.
If the client requests the image with ‘accept WebP’-request-header, then it will get the webp version served, even though it requested a file with .jpg-ending.
This is a standard NGINX feature (and also is supported by Cloudflare, Sucuri, BunnyCDN, etc… as standard) used by gazillions of installations out there.

So, it is the question, how exactly the image is being requested.
If it goes via http-call and the client does not accept webp (as described in the link you shared), then the client _must_ make sure that it sends an appropriate http request header.

Since we recently switched to deliver webp based on the clients HTTP request header, this might be an explanation, if the URL is being used.

It also seems to affect 100% of the product images we changed since we started to deliver webp, which also could be another hint.

Tracking this down could be quite tricky, though.
So, before investing more effort into it, I am curious to learn how Zettle is actually getting the image file.

The image itself is 1600x1200px and has 119KB.
So, that should not be an issue, but yes, I surely can also test modifying it.

Thanks for your support!
Markus

Hi Joost,

good hint with the tax setting.
Actually we started to sell EU-wide some few weeks ago and during that change, we also started using One-Stop-Shop from Vendindero/Germanized.

During that step, we made some changes regarding the tax setting.
It sounds like this might have had some unintended impact.

No need to do something on your side, I just wanted to inform you.

Best

Markus

Hi Joost,
thanks for the feedback.
If this is nothing to be worried about, I am fine ??
Thx

Markus

I don’t want to downgrade Woo, because there had been a DB upgrade.

We need to restore an old backup.

I found out, what is causing the issue: it’s AutomateWoo, also from WooCommerce.

Also, when opening the order, it takes ages to open them in the editor.

Every order which has been created before the update to 8.1.1 opens within 3-4 seconds.

When cancelling the (test) orders, I run into timeouts

Followed up in https://www.ads-software.com/support/topic/critical-8-1-1-creates-only-broken-orders/

ok, thanks!

Hi,

is it possible that this is due to “Ajax variation threshold” option?
Can I safely set it to a higher value?
What will be the impact?

Thanks

Markus

Hmm. Seems only to cover part of the cases…

Hi,

ich found a solution by applying a filter:

function alterImageSRC($image, $attachment_id, $size, $icon) {
	$image[0]=str_replace(get_site_url(),"CDNURL",$image[0]);
	return $image;
}

add_filter('wp_get_attachment_image_src', 'alterImageSRC', 10, 4);

Works for me.

Markus

Thanks, Joost!

Hey,

obviously a very old one…
I somehow expected that it would get automatic updates.
After downloading the newest version, all is fine!

Thanks
Markus