image replacement problem

photoclick

In an unlisted gallery there is a photo. I provided the link to that photo to a third party, let's say for advertisement banner. I later replaced the photo with ta new one (click the wrench icon in the light box and select Replace). The link I provided to the third party still shows the OLD image. It does not redirect to the newely replaced image. I believe this is wrong.

Here is the original link [HTML]https://photos.smugmug.com/photos/i-g44PHbC/0/O/i-g44PHbC.jpg[/HTML]

and here is the original image


This is the replaced image
and here is the link to the new, replaced image that I got from the Share panel: [HTML]https://photos.smugmug.com/photos/i-g44PHbC/1/O/i-g44PHbC.jpg[/HTML]

Can this issue be investigated, please? If I upload the image to the gallery and later replaced the SAME Placeholder with a new image I expect to see the new image by visiting the original link. Otherwise what is the point of the Replace function?

Thank you,
mike

Richard

Mike,

Here's what I'm seeing:



I suspect that the replace is working as expected but that you are seeing something else because of caching, either in your browser or in the cloud CDN.

photoclick

It is CDN caching - I tried links from different browsers and computers. And it pointed to two different images since yesterday. So, what is the recycle time for CDN caching? Here is a new test:

original image:

https://photos.smugmug.com/photos/i-PnCT2Pt/0/O/i-PnCT2Pt.jpg

replaced image:

https://photos.smugmug.com/photos/i-PnCT2Pt/1/O/i-PnCT2Pt.jpg

photoclick

and, by the way, this is what I see now:

leftquark

The URL changes when you replace an image. You'll see a version number in the links you're getting (it starts with 0, then the replaced image 0 becomes 1). You can see the # change in photoclick's links (i-PnCT2Pt/0/O) -> iPnCT2Pt/1/O). We hang onto the original in case you need to go back to it.

photoclick

Yes, I see the version number changes. And I realize now you hang onto the original. But if someone still has a the original, version zero, link (i-PnCT2Pt/0/O) - will that link (should that link) force the visitor to the latest version?

photoclick

I have to bring it up again -something is not right here. I am paying to advertise on other site and gave them this link:

http://www.tailoredportraits.com/System/Marketing/n-wPRgvt/i-5R6QzLQ/0/O/i-5R6QzLQ.jpg

I replaced the image (Lightbox >Replace) a month ago. It still pulls the older copy. I contacted support. And all I have in response is "we don't have time estimate..." What gives? Or, to be honest, wtf? This thread is two months old and no one is willing to admit you have a caching issue with CDN and custom domain combination?
For the curious - yes, it works if I give up custom domain and start using "photos.smugmug.com". But at this point I will give up smugmug as a hosting service than the pleasure of utilizing my domain.

I just want to know if anyone can look into it, please.

leftquark

Because you used a direct embed link to the image, then replaced it, the direct embed URL needs to be updated. Replace the /0/ with /1/ (or whatever number of times you replaced it). You can get the most current embed link from the share panel. We don't delete your originals, in the event that you need to revert, and the direct links include the version number.

leftquark

After talking with the sorcery team it appears we should be redirecting for you, pending CDN cache. The custom domain is still using the old CDN but it should have updated by now. We checked with a few folks and some people see the redirect and some don't (I dont). Continuing to investigate...

leftquark

Looks like we're not invalidating the CDN cache when you do a replace (so the auto-redirect won't apply to anything cache'd on the CDN), so you'll want to go in and update the link to the latest version of your photo

photoclick

Are you not invalidating CDN cache on purpose, by design? I guess, my question is, is there any format of a link I can use that will work in this situation and not resorting to "photos.smugmug" format?

Ferguson

There's another aspect of this which is a bit strange, though from my perspective it worked OK, just a surprise.

I did this:

1) Uploaded a photo, grabbed a link (https://photos.smugmug.com/photos/i-tLsX749/0/X3/i-tLsX749-X3.jpg). Pineapple normal colors.

2) Edited the photo, changed colors to be bizzare, replaced with lightroom, grabbed a link (https://photos.smugmug.com/photos/i-tLsX749/1/X3/i-tLsX749-X3.jpg). As described this link has a 1.

I then clicked each link, and both got the bizzare photo. Indeed, clicking the first also changes the address bar to the second.

So I then:

3) Edited the URL to my custom domain (http://www.captivephotons.com/photos/i-tLsX749/0/X3/i-tLsX749-X3.jpg) for the first, and

4) Edited the URL to my custom domain (http://www.captivephotons.com/photos/i-tLsX749/1/X3/i-tLsX749-X3.jpg) for the second.

When I click on the second I get the bizarre colors, which is correct and expected. When I click on the first, I am redirected to the Smugmug domain and https. No cache issue (to be fair, I never clicked on the first custom domain URL before the replacement so caching may not be at play).

The https aspect is non-breaking, I think, since having https pop up unexpectedly on an insecure page is fine (unlike the reverse). But changing domains was a bit of a surprise. I did not try this embedded in someone's forum pages, I am guessing it will work the same way as just clicking it. But I'm surprised at the domain switch.

I'm also, frankly, surprised that the original image is kept. And presumably all sizes of the original image. It would never have dawned on me you retained all the replaced copies, and are relying on a redirect for them. My guess is 99.99% of your customers that replace photos would be surprised to know that is occurring (the other guy nodded off during the discussion, it's not that he knew). I certainly thought the URL stayed the same. Frankly I think it should, and loose the redirect, especially since "in the event that you need to revert" is hardly something we are able, ourselves to do. I mean, the old URL doesn't "work" in the sense of allowing you to access it.

And oh my, won't this be confusing when you (finally, correctly) start updating metadata on replace.

Why not just have "replace" be a "replace" in all senses of the word.

Seriously, who thinks of these convoluted things. Like "replace should replace some things, but not date or time, but maybe title except on alternate thrusdays and from Lightroom if you are facing east".

Richard

Ferguson wrote: »

Why not just have "replace" be a "replace" in all senses of the word.

The main value of "replace" is lost if links you have given out no longer work and metadata are borked. I don't need SM to keep older versions for me--I have a local database for that. Besides, if I want SM to keep several versions, I can do that easily enough without using replace.

denisegoldberg

Richard wrote: »

The main value of "replace" is lost if links you have given out no longer work and metadata are borked. I don't need SM to keep older versions for me--I have a local database for that. Besides, if I want SM to keep several versions, I can do that easily enough without using replace.

Agreed. If I replace a photo I expect the new photo to be shown for all access to that photo. The latest version of the photo needs to be shown both for custom domain and for references using photos.smugmug.com.

--- Denise