sImageUrl is blank when returned from search and getProducts

[authcode]

I've changed my code to use direct merchant images in place of productserve images and am getting strange results.

It would appear that when products are returned from a search or getProducts the sImageUrl variable is blank. But, when products are returned from getHotpicks or getProduct this variable has data.

Can anyone confirm this?

[authcode]

Can someone please look into this? I can't see a problem my end.

[Adrian]

Hi Steve,

Will get the Dev. Team onto this at the earliest opportunity.

Please keep me updated if this does happen to eventually 'sort itself out'!

Will let you know when i hear back from them.

Cheers,

Adrian :)
SW Integration & Technical Support.

[authcode]

Cheers Adrian.

As a background to the problem - I use a single function to write out the product display html. Since the migration some products have merchant images and some don't depending on the method by which the products were returned from the API call. I have checked this by finding the same product by various means (see original post) and sure enough some methods return an image and some don't.

I realise it sounds unlikely that a product's data would be different depending on how it was fetched, but I can't see any other possibility.

[Paul Inman]

Hi Steve, sorry for the slow response.

At the back-end there are two types of product Object that can be returned. A compact and a full version. The compact version does not have sImageUrl.

The idea behind having different levels is to reduce the amount of data being sent where possible.

In the next version of the API we'll be adding a parameter so you can control the level.

Hope this helps,
Paul

[authcode]

Hi Paul,

Thanks for the info. I appreciate your need to reduce bandwidth but I think you've created a significant problem for us:

Since you introduced the anti-abuse measures on the product serve images you've forced us to use sImageUrl instead of sAWImageUrl but now you're saying that not all API responses will return sImageUrl.

So until the API update we're stuck with sites where the majority of products are missing images because you won't let us use your image server?

These recent changes seem extremely ill-conceived. How do you suggest we obtain product images when one method is effectively blocked and the other is restricted???

[Paul Inman]

Hi Steve

So until the API update we're stuck with sites where the majority of products are missing images because you won't let us use your image server?

These recent changes seem extremely ill-conceived. How do you suggest we obtain product images when one method is effectively blocked and the other is restricted???

We're not stopping you from using the server for normal use, I know this is going full circle but can you default back to using our images if you haven't got a local copy? Then once the next version is live you can continue gathering your own cache.

[authcode]

Hi Paul,

I must have this confused!

If I use sImageUrl as you recommended, in certain situations I won't get images because of the compact product object.

If I use sAwImageUrl I don't get more than about 4 images per page before they stop loading because of the anti-abuse measures.

My image code simply takes the image URL, checks to see if there's an image in the cache and if there isn't then creates a thumbnail and caches it. Is that counting as abuse because I can't see any simpler way of achieving the same thing? Why is no one else getting this problem? What is the recommended method of displaying product images?

[Confuscius]

Hi Steve

I do not know if this is any help as I am on the 'other' side using the ShopWindow software but the logic used there is the following:

// pick an image to show
if ( strlen($oProduct->sAwImageUrl)>5 ) {
$sProductImageUrl = $oProduct->sAwImageUrl;
}
else if ( strlen($oProduct->sImageUrl)>5 ) {
$sProductImageUrl = $oProduct->sImageUrl;
}
else if ( strlen($oProduct->sAwThumbUrl)>5 ) {
$sProductImageUrl = $oProduct->sAwThumbUrl;
}
else if ( strlen($oProduct->sThumbUrl)>5 ) {
$sProductImageUrl = $oProduct->sThumbUrl;
}
else {
$sProductImageUrl = '';
}

In other words, flow through what is available and adjust action as appropriate - could you not loop through a fixed number of times so you cahed say 3 NEW images per call? Over time your cached percentage of images would get larger. Just thinking out loud as a non techie!

Paul

PS for Paul Inman - I would appreciate a response to my last post in this RELATED thread - http://www.shopwindowforum.com/showthread.php?t=302

[authcode]

Hi Confuscius,

I understand your logic there but I still don't understand a couple of things from the SW API end:

1) Why have an image server if you can't afford the bandwidth to serve images? Seems absolutely pointless to even bother.
2) Why have a compact product object at all? All product data is compressed text anyway - how much bandwidth is actually saved by culling this data?
3) The default client doesn't do ANY image caching - why is nobody else seeing the same problem?

I would look into how the client handles images to understand why I'm having such a problem but at this point, with all the speed and reliabilty issues over the past x number of months and constant changes to the specs, I've really lost interest in this project. Sorry.

[xlcus]

The default client doesn't do ANY image caching - why is nobody else seeing the same problem?
I'm guessing that as you're doing processing on the images, they're all being retrieved by a your server (a single ip address), where as in the default client, the images are being retrieved by the shopper's computer (lots of different ip addresses). So that's probably why the anti-abuse stuff is triggering.

[authcode]

Thanks xlcus, that explanation makes perfect sense - good thinking.

The solution as mentioned earlier would seem to be to request and cache 3 or 4 images per page load but I don't really see why I should since no one's actually explained what's so wrong about a single IP requesting multiple images. How does that constitute abuse? How does that differ from a shopper or spider looking at hundreds of pages of a default client install?

[authcode]

Sorry to bang on about this but I've recently been looking at getting some images back on my site and I just don't see what's going on.

The sImageUrl images are limited to hotpicks and products and are absent from search results and category listings because of the compact data type. Fine.

I was then told to use sAwImageUrl and progressively cache the images I could get from the productserve server. BUT, I can't get any images from the productserve server! Not a single one.

I can request 100 hotpicks and display their images directly in my browser but if I try to get my server to load just 1 image with createimagefromjpeg the resource is forbidden. What gives?

Has my server's IP been blocked entirely or something?
How exactly do these anti-abuse measures work?

Can someone from AW please give me a straight answer. Pretty please?

[Confuscius]

Knock! Knock! ...

[authcode]

Hi Confuscius. Are you running into similar problems?

Is anyone else here trying to cache images and hitting this problem?

Seems like it's just me at the moment :(

[amarath]

Hi Steve / Paul,

As you may or may not be aware, you are the only two affiliates that are trying to cache our images.

As Paul has highlighted in his previous posts, once we have completed the next release you will be able to cache your own images as you have been.

Please bare with us during this development phase and once we have a further update we will pass this on.

Regards

Amo
Head of ShopWindow

[authcode]

Hi Amo,

I appreciate the response.

But... to be fair, when the anti-abuse measures were first introduced Paul told me to switch to using sImageUrl. When these then disappeared because of the compact data type he told me to switch back to sAwImageUrl for the time being, which then also stopped working. At no point did anyone tell me to wait.

I'll wait for the update.