Link locations changed

BigAl · April 26, 2011

This is quite irritating. The image links have become a *whole* lot more complex.

With older pics, the image location of the thumbnail is

http://bigal-sa.smugmug.com/Other/Help/screenshot-47576/1153494013_x5kaJ-Ti.gif

and all one had to do was change the Ti to get a link to the larger images.

The current link location is

http://bigal-sa.smugmug.com/Other/Help/i-6B7CV55/0/Ti/kindle-34539-Ti.gif

with the link to a larger image given by

http://bigal-sa.smugmug.com/Other/Help/i-6B7CV55/0/L/kindle-34539-L.gif

This makes it rather painful when sharing images with clickable links to larger images :pissed

jfriend · April 26, 2011

I don't understand why SM doesn't explain to us how these new URLs work? They should have explained these changes before they were implemented.

There's lots of code that operates on URLs and some of it has broken. What is this new ID in the URL? How are custom sizes supposed to be generated? Are there changes in the API coming. Will every image continue to have an imageID and an imageKey even though they aren't used in the new image URLs? Will old URLs for both standard sizes and custom sizes continue to work forever (embedded in external and SM sites and as constructed in existing JS customizations).

All of a sudden this change looks very scary to those of us who do advanced things with programming, with URL construction and with custom sizes. Andy, this was not smart to spring this on us with no advanced notice and then no explanation of how it works once you did spring it on us. I would have expected a little more forethought from you all than this.

Please get some info out right away on how these new URLs work and on how custom sizes are supposed to work with them.

Now, I'm even more scared of potential future changes to gallery URLs which could really mess with a bunch of customizations.

beardedgit · April 26, 2011

Hiya

Just thought I'd chip in with my twopenn'orth...

As a WP blogger I embed a lot of linked images, displaying "L" size pics on the blog pages and having each image linked to a larger copy, usually "X3". The usual "quick" method of embedding a linked pic is to open the image dialog box, paste in the "L" link, save and close the box, open the link dialog box, paste in the same link, edit the end "L" to "X3", save and close the box. Quick and simple.

I did that with my latest images and yup, it borked. Clicking the linked images only showed them at "L". I checked all the usual suspects - WP installation, lightbox plugin, Java, Flash, but they were all unchanged. Previous posts with older pics worked fine. Eventually I fired off a SM support request (ticket number 279578) and then continued to bang my head against a brick wall for many hours until I realised that the link format had been changed without prior notice, and that the size parameter is in there twice and has to be changed in both places.

I went back to the blog and re-edited the size parameters in both places for each link and it's working now.

Tristan (Support Hero) has been dealing with the support request, I've asked for clarification as to whether the dual size-parameter thing is intentional (and hence there'll be a reason for it) or an error (and hence it'll need fixing). Tristan has agreed to pass the request to somebody "in the know". I've also suggested to Tristan that somebody should update the instructions at http://www.smugmug.com/help/custom-photo-sizes

Hopefully somebody will deal with this soon, as custom-sizes and size-changes are now a PITA

Sorry that my first post here is a bit of a rant.

Nice place you've got here

I'll go sit in the corner and try to keep quiet now.

BG!

TalkieT · April 26, 2011

I had a similar issue (buried in the bug reporting forum) where I have customisation that rewrites the 'Th' to "Ti' for my homepage thumbnails to ensure a consistent experience...

This change broke my layout (not too badly I admit) and I had to quickly relearn some regex to rewrite the URL twice (change both instances of Th to Ti).

On reflection, I could probably remove the previous rewrite since it's only the new size parameter mid URL that seems to be respected.

Anyway, Doc _did_ identify the issue for me when I asked, although he had to go find a coder to track down why my customisation broke.

I'd strongly echo Johns comments - making changes that break existing functionality or change the filename spec etc isn't good - please don't do it again.

A sticky a few weeks out would be appropriate, and firing advance notice to a very few key clients (Jfriend springs to mind) would have been nice.

Cheers - N

Andy · April 26, 2011

BigAl wrote: »
With older pics, the image location of the thumbnail is
http://bigal-sa.smugmug.com/Other/Help/screenshot-47576/1153494013_x5kaJ-Ti.gif
and all one had to do was change the Ti to get a link to the larger images.

Hello Al,

http://bigal-sa.smugmug.com/Other/Help/screenshot-47576/1153494013_x5kaJ-L.gif still works (changing -Ti to -L, for example). Is that not working for you?

Andy · April 26, 2011

jfriend wrote: »

I don't understand why SM doesn't explain to us how these new URLs work? They should have explained these changes before they were implemented.

There's lots of code that operates on URLs and some of it has broken. What is this new ID in the URL? How are custom sizes supposed to be generated? Are there changes in the API coming. Will every image continue to have an imageID and an imageKey even though they aren't used in the new image URLs? Will old URLs for both standard sizes and custom sizes continue to work forever (embedded in external and SM sites and as constructed in existing JS customizations).

All of a sudden this change looks very scary to those of us who do advanced things with programming, with URL construction and with custom sizes. Andy, this was not smart to spring this on us with no advanced notice and then no explanation of how it works once you did spring it on us. I would have expected a little more forethought from you all than this.

Please get some info out right away on how these new URLs work and on how custom sizes are supposed to work with them.

Now, I'm even more scared of potential future changes to gallery URLs which could really mess with a bunch of customizations.

I posted to you in your prior thread that we were doing just as you asked. http://www.dgrin.com/showpost.php?p=1600590&postcount=11

Olde image links work. And will. If they don't, that's a problem and we need to deal with it. As I posted just above to Al, changing a -Ti to a -L for example, "just works" - if it's not working for you, we need to be made aware of the specific examples.

Andy · April 26, 2011

beardedgit wrote: »

Hiya

Just thought I'd chip in with my twopenn'orth...

As a WP blogger I embed a lot of linked images, displaying "L" size pics on the blog pages and having each image linked to a larger copy, usually "X3". The usual "quick" method of embedding a linked pic is to open the image dialog box, paste in the "L" link, save and close the box, open the link dialog box, paste in the same link, edit the end "L" to "X3", save and close the box. Quick and simple.

I did that with my latest images and yup, it borked. Clicking the linked images only showed them at "L". I checked all the usual suspects - WP installation, lightbox plugin, Java, Flash, but they were all unchanged. Previous posts with older pics worked fine. Eventually I fired off a SM support request (ticket number 279578) and then continued to bang my head against a brick wall for many hours until I realised that the link format had been changed without prior notice, and that the size parameter is in there twice and has to be changed in both places.

I went back to the blog and re-edited the size parameters in both places for each link and it's working now.

Tristan (Support Hero) has been dealing with the support request, I've asked for clarification as to whether the dual size-parameter thing is intentional (and hence there'll be a reason for it) or an error (and hence it'll need fixing). Tristan has agreed to pass the request to somebody "in the know". I've also suggested to Tristan that somebody should update the instructions at http://www.smugmug.com/help/custom-photo-sizes

Hopefully somebody will deal with this soon, as custom-sizes and size-changes are now a PITA

Sorry that my first post here is a bit of a rant.

Nice place you've got here I'll go sit in the corner and try to keep quiet now.

BG!

Our help pages are being updated this week. But changing an OLD url to -X3 should just work. I'm looking more into your case.

EDIT: your photo

http://beardedgit.smugmug.com/Fellwalking/Day-Walks/YHA-Borrowdale-April-2011/i-tZH3mPQ/1/L/borrow001-L.jpg

needs to have the size changed in 2 places, that's one bit of documentation that does need to get on the site, and we're doing so this week.

http://beardedgit.smugmug.com/Fellwalking/Day-Walks/YHA-Borrowdale-April-2011/i-tZH3mPQ/1/L/borrow001-L.jpg

would become

http://beardedgit.smugmug.com/Fellwalking/Day-Walks/YHA-Borrowdale-April-2011/i-tZH3mPQ/1/XL/borrow001-XL.jpg

TalkieT · April 26, 2011

Andy wrote: »

Hello Al,

http://bigal-sa.smugmug.com/Other/Help/screenshot-47576/1153494013_x5kaJ-L.gif still works (changing -Ti to -L, for example). Is that not working for you?

Are you deliberately avoiding the real question?

Yes, old URLs still work, and changing old URLS works fine

However, the easy way to produce new links gives URLs with TWO size identifiers in them, and changing the one at the end is pointless - it's the one in the MIDDLE you need to change.

Plus, as I have pointed out, your changes break some (admittedly complex) customisations.

More importantly, as John has pointed out, we can't rely on Smugmug keeping URLs consistent anymore, making customisation MUCH harder and more volatile.

What I want to hear is "Whoops, we stuffed up, we should keep things consistent whenever possible, and if not possible, we should give as much notice as possible, and document the change clearly when it happens. Sorry, we'll learn for next time"

Can't you just say something like that instead? :-)

Cheers - N

Andy · April 26, 2011

Thanks for the feedback guys, I'll make sure that the info on the new forms of URLs gets posted in all the right places.

Allen · April 26, 2011

Andy wrote: »

...
Olde image links work. And will... .

That's not the point. They are using the link Smugmug gives them and
parsing that. So have to re-write their code.

Andy · April 26, 2011

TalkieT wrote: »

Are you deliberately avoiding the real question? N

Hi Neil, I'm not avoiding anything - just trying to answer everyone and all questions.

Yeah, I wish our blog post and help pages went live the moment the new URLs didn't, we should have ensured that, sorry. In this case, we also could have posted a heads up on how the URLs work, even a little bit in advance of the release. Now let me go do that right now.

rickysilk · April 26, 2011

This is bullshhhhhiiitttt. Any photos uploaded now get the new url. So our apps have to be smart enough identify different paths and make the appropriate changes. This is bullshhhhhiiitttt.

denisegoldberg · April 26, 2011

Andy wrote: »

Thanks for the feedback guys, I'll make sure that the info on the new forms of URLs gets posted in all the right places.

I'd really like to understand why you (Smug, not you personally) think it's an improvement to create a URL in a form where information needed for custom sizes is in two places, not one. Yes, I know, I can use the old URL form, but the share page gives me the new form. I suspect the change was at least partially related to exposing the original file name as part of the image id, but placing the size in two places is redundant and just plain annoying.

--- Denise

Andy · April 26, 2011

denisegoldberg wrote: »

I'd really like to understand why you (Smug, not you personally) think it's an improvement to create a URL in a form where information needed for custom sizes is in two places, not one. Yes, I know, I can use the old URL form, but the share page gives me the new form. I suspect the change was at least partially related to exposing the original file name as part of the image id, but placing the size in two places is redundant and just plain annoying.

--- Denise

I'm sorry it's annoying, Denise. It just had to be done. That answer won't satisfy you, I know ... but I wish you'd try and let it

rickysilk · April 26, 2011

denisegoldberg wrote: »

I'd really like to understand why you (Smug, not you personally) think it's an improvement to create a URL in a form where information needed for custom sizes is in two places, not one. Yes, I know, I can use the old URL form, but the share page gives me the new form. I suspect the change was at least partially related to exposing the original file name as part of the image id, but placing the size in two places is redundant and just plain annoying.

--- Denise

Apparently changing only the first size in the path will change the image size. Since there are no docs it's hard to figure out what's going on.

Andy · April 26, 2011

rickysilk wrote: »

Apparently changing only the first size in the path will change the image size. Since there are no docs it's hard to figure out what's going on.

Working on it right now, sorry guys for our fail in not publish this stuff sooner.

Allen · April 26, 2011

Maybe another problem for code writers, check out unlisted galleries, looks like they use the old /photos/XXXXXXXX_xxxxx-M.jpg share links.

Hopefully this is to not expose the cat, sub-cat and gallery name/No. which could be a disaster posting to the web.

Andy · April 26, 2011

jfriend wrote: »

Please get some info out right away on how these new URLs work and on how custom sizes are supposed to work with them.

http://www.dgrin.com/showthread.php?t=196034

I'm closing this thread so that all questions and discussion can be in that new thread that I just posted. Thanks.

Link locations changed

Comments