Hello @markisu72
The acceptance of these images is not specifically managed by our plugin, but it is accepted or denied by the Zettle server that needs to be able to handle them. I expect that the type of JPG image or the size of the image is causing the problem.
In order to resolve this issue, I would try to adjust the image by changing the size or exporting the JPG via another application and testing if that image can be synced to Zettle. Only by testing, you can find out how you can get this to work. I would suggest using paint (or some other image processor) to make other JPG exports and see what works. Most JPG’s should be acceptable, but not all type are.
Let me know if this helps you resolve this and if you have any further questions for me.
Kind regards,
Joost
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
Hello @markisu72
yes, that changes seems to be the cause of the issue. Zettle does not accept webp images and those will not be transferred to their server.
Our plugin uses JSON webhooks for communicating between WooCommerce and Zettle. The purpose of webhooks is sending notifications from the service to website. Like when the stock is changed on Zettle it sends a webhook about that to let the website know and apply the same stock change on the website.
Images are sent in the same way as all other data during sync;
they are sent as URL, so the website/image URLs must be accessible from the internet, otherwise Zettle will not be able to access the image.
However, I don’t think this has much effect on your situation, and you might need to focus on the WebP images in order to resolve your situation. Let us know if you have any more questions or if we can mark this thread as resolved.
Kind regards,
Joost
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
Hello @markisu72
have you tried to create a new instance of this product (while WebP is turned off) to see if that new product would sync the image correctly. It could be that the database initially saved an incorrect URL for retrieving the image…
I’m just trying to come up with other solution for this problem, because we have not had a similar setup and issue before, so this can only be resolved by trial & error.
Let me know if that showed any improvement.
Kind regards,
Joost
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 2 years, 7 months ago by
markisu72.
Hi Joost,
I found the issue…
It is a quite annoying one, though.
We’re getting (as most others, I assume) attacked by a lot of malicious bots executing automated hacking attempts. Some of the rather stupid ones use automated requests e.g. implemented in PHP or Java… I say ‘stupid’ because they send requests using a user agent string containing ‘PHP’ or ‘Java’.
It is a good practice to block all clients which obviously run automatic scripts (thus, are no humans) or don’t identify themselves with a proper user agent.
And guess what… Zettle’s image crawler uses “Java/17.0.6” as user client, thus being in the same identification pattern as hackers.
It got blocked by the bot detection – righteously so, because it does not identify properly.
I now have softened the bot detection and now the images get through.
But please, could you tell Zettle, they should implement a proper user agent for their calls? Like that, we cannot keep the bad bots out without doing the same for Zettle. This is a security issue.
Now, having opened the gate for the Zettle image crawler again… will it retry to fetch the images? If so, for how long? How can I force a refetch?
New product images are being fetched immediately but the old ones are still missing.
Thx
Markus
Hello @markisu72
Since not much development is currently being done on this plugin, I am not positive on the outlook of the security issue being resolved very soon.
However, if you have a bit more specific instructions on what changes would need to be made, I can check with the team if there is any option to improve this behavior for a future release.
The 2nd question you raised: I think you should be able to trigger the image sync after the initial attempt, but going to the product and pressing “Update” on the product page. This is very manual work, so if you want to do this in bulk, you could also change the status of the product to “draft” and when you then change it back to “Published”, the image sync should also kick in again (this one you can do in bulk with the bulk tools in the product overview page).
Please let me know if this helps you correct your library.
Kind regards,
Joost
Hi Joost,
yes, the images are back in Zettle now. Thanks for your help! 🙂
Regarding the user agent thing…
I don’t now exactly, which Java library your devs are using to fetch the images from the server, but in general, it is just an additional parameter / attribute to be set in the request object before executing the request itself.
Here is an example, how it could look like
import java.io.IOException;
import java.net.URL;
import java.net.URLConnection;
public class TestUrlOpener {
public static void main(String[] args) throws IOException {
URL url = new URL("http://localhost:8080/foobar");
URLConnection hc = url.openConnection();
hc.setRequestProperty("User-Agent", "Zettle Image Crawler");
System.out.println(hc.getContentType());
}
}
As you can see in that example, one only needs to explicitly set the User-Agent property to let the request identify the requester to be Zettle.
I assume, the current User-Agent “Java/17.0.6” is just the result of not setting this explicitly and thus the default setting will be used… So, your code is running on Java 17.0.6 😉
It should be a one-liner to change this.
Hope that helps.
Best
Markus
-
This reply was modified 2 years, 7 months ago by markisu72.
-
This reply was modified 2 years, 7 months ago by markisu72.
Hello @markisu72,
The main issue you reported to us has been cleared up, so I will mark this thread as resolved.
This user agent issue seems to primarily reside between you/the user and Zettle. You have strict anti-spam rules, which mistakenly identified the Zettle image crawler as a malicious bot and subsequently blocked it. I recommend to reach out to Zettle support with this latest explanation for further clarification and assistance. We can certainly raise this with our Zettle partners internally, but it’s important to understand that our internal process might not yield immediate feedback. It’s in your best interest to pursue both avenues for resolution.
Kind regards,
Joost
