give different results. The first doesn't read any info at all (even the photo size). This is weird as it is much easier for me to link the 18th photo in the gallery than the 18/whatevernumberthatis.
-Russ
I haven't seen anything documented for Smugmug URL construction so relying on something that you don't see being used in your galleries probably isn't a wise thing. In the first URL,
The 2657204 is the gallery ID. The 18 is the page number in that gallery not a photo number. In some views that only show one photo per page, it appears to the the same as the photo sequence number, but I think it's really just the page number. If that page number doesn't exist, it appears that Smugmug ignores it. You can see this URL construction in play in the Journal gallery style when you go from one page to the next and it works in the Smugmug style too.
It's a worthwhile question of the Smugmug developers to see if they have a URL construction that gets you the Nth image in a gallery. I wouldn't be surprised if it exists, but I don't know what it is myself.
I think the documentation might be wrong, by default 100 results are returned for the feeds. The default can be modified to 10 by adding the following the the feed URL...
I haven't seen anything documented for Smugmug URL construction so relying on something that you don't see being used in your galleries probably isn't a wise thing. In the first URL,
The 2657204 is the gallery ID. The 18 is the page number in that gallery not a photo number. In some views that only show one photo per page, it appears to the the same as the photo sequence number, but I think it's really just the page number.
Thanks John, that makes sense. I only use the views that are one-photo-per so I just assumed that it was actually the nth photo and not the nth page. Either way I still think it is odd that it can figure out what photo to display on that page but not figure out what exif to display. Seems like that would be a two line fix.
Thanks John, that makes sense. I only use the views that are one-photo-per so I just assumed that it was actually the nth photo and not the nth page. Either way I still think it is odd that it can figure out what photo to display on that page but not figure out what exif to display. Seems like that would be a two line fix.
Renstar,
I think it depends on what style you have chosen, as different styles pagenate differently.
If you want to start on a specific image, your best bet is to use this notation...
Removing keywords from a multiple-keyword search
This has been reported in the Bug Reporter. However, its status has been changed to "Won't Fix", so I thought I would bring it up here, to warn people that it might happen.
(As an aside, if smugmug decide not to fix a reported bug, it would be polite to give the reasons for this decisions in the bug's comment field. Smugmug has a reputation for good customer support, leading to many users to help the company out, but by answering questions in the dgrin forums, and by properly reporting bugs via the Bug Reporter. If a bug is being reported, then it must be having an impact large enough to cause the user to research the bug-reporting procedure. By anonymously changing bugs to "Won't Fix" without giving a reason, smugmug is risking its reputation for customer service.)
This has been reported in the Bug Reporter. However, its status has been changed to "Won't Fix", so I thought I would bring it up here, to warn people that it might happen.
Where do you see that? I can't find such a status.
(As an aside, if smugmug decide not to fix a reported bug, it would be polite to give the reasons for this decisions in the bug's comment field. Smugmug has a reputation for good customer support, leading to many users to help the company out, but by answering questions in the dgrin forums, and by properly reporting bugs via the Bug Reporter. If a bug is being reported, then it must be having an impact large enough to cause the user to research the bug-reporting procedure. By anonymously changing bugs to "Won't Fix" without giving a reason, smugmug is risking its reputation for customer service.)
The changelog says 04/04/2007 03:13PM: Status changed from new to resolved by guest 04/04/2007 03:13PM: Resolution changed from open to wontfix by guest
The changelog says 04/04/2007 03:13PM: Status changed from new to resolved by guest 04/04/2007 03:13PM: Resolution changed from open to wontfix by guest
One of the perils of a public wiki. It's bugged, internally, on our internal site, like I said. I changed the status on the public wiki too.
One of the perils of a public wiki. It's bugged, internally, on our internal site, like I said. I changed the status on the public wiki too.
I find this quite confusing that you have a public wiki and an internal one. It also occurs to me that it complicates stuff for the SM employees as well. Remember when I got that notification that my bug was fixed on your internal wiki (internal bug #41), but in reality it wasn't yet. My bug on the public wiki (bug #33) still has the status new without any sign of that someone actually had a look at it.
That kind of makes me wonder sometimes if it's worth actually taking the time posting a bug in the wiki - here on dgrin most of the time one of the team responds very quickly to the issues. The only time I got the impression that somethings changing on the wiki when I got that notification from the internal wiki - then I saw that someone had copied my entry, probably manually, into the internal wiki. That was 6 months after me reporting the bug on the public wiki.
What I actually want to say. Why not put some more work into access rights in the public wiki and use that instead of copying every bug report into your internal one which is then filed under a different ID to add to the confusion? Just make changing the status of a bug and all the other Admin stuff like deleting users an Admin only option. Why would you want to let a guest resolve a bug on the wiki anyways? Also only the one who filed the bug should be able to edit it. It's fine that guests can file bugs though.
With some access management and if the SM team actually starts using the public wiki as well, it should be more up-to-date and therefore more attractive for the customers to use. You can still keep your internal wiki for bugs discovered internally, but please handle the ones reported in the public wiki also publically.
I find this quite confusing that you have a public wiki and an internal one. It also occurs to me that it complicates stuff for the SM employees as well. Remember when I got that notification that my bug was fixed on your internal wiki (internal bug #41), but in reality it wasn't yet. My bug on the public wiki (bug #33) still has the status new without any sign of that someone actually had a look at it.
Ouch Sebastian, I'm sorry it's confusing. I sent you a note last week letting you know that I reset it back. Have a look at bug 33 It's status open.
BTW, just file them here if you like. Thanks. I'll see if we can sort things out on the bug reporter!
Ouch Sebastian, I'm sorry it's confusing. I sent you a note last week letting you know that I reset it back. Have a look at bug 33 It's status open.
BTW, just file them here if you like. Thanks. I'll see if we can sort things out on the bug reporter!
Yeah Andy, I got an instant reply that you'll check.
Basicly it was my point - the status of my bug always has been *new* (plus open for not being resolved yet) in the public bug reporter- just like it was when I filed it. To my knowledge it was never assigned to anyone. You just worked with the data in the internal bug reporter and, who ever has taken responibility for it, (I'm assuming here) forgot about updating the public bug reporter.
All in all this just looks like nothing is happening on the bug front which kind of makes me as a user wonder (general speaking for any user that might report a bug) why there's absolutely no recognition of what I spent my time reporting on here.
Do you get my point here with the mirroring you're trying to do here with your internal and public bug reporter and the problem of keeping them in synchronisation. There're just not linked at all to me as the bug IDs are different as well.
---end of general criticism about the bug reporting system---
I just wanted to add a personal note on the specific bug as it's an important one in my view especially because it's been around so long and involves a general privacy issue in my point of view.
Clearly it's most important when I delete a photo that the photo is totally not accessible anymore. It's understandable that you can't erase it immeadiately from all your backups as this takes time.
Still I also think that the whole photo page (including the caption) should be inaccessable as well from the point I delete the photo, which is apparently not the case and that's why I deleted the photo. It's especially essential in terms of google and other search engines dropping the link to the photo, but this only happens if you can't access the photo page anymore.
In my reported example which possibly could apply to a (big) number of other deleted photos it's been around 6 months without a resolution. You're constantly innovating and enhancing my experience, but I think that bugs really should have a higher priority over new features. It doesn't matter if it's a small or big bug - the annoyance with the user is usually higher than think. Normally you fix stuff way quicker than any other company, but there are sometimes issues (I can't name any right now) that take way to long to be resolved.
Yeah Andy, I got an instant reply that you'll check.
Basicly it was my point - the status of my bug always has been *new* (plus open for not being resolved yet) in the public bug reporter- just like it was when I filed it. To my knowledge it was never assigned to anyone. You just worked with the data in the internal bug reporter and, who ever has taken responibility for it, (I'm assuming here) forgot about updating the public bug reporter.
All in all this just looks like nothing is happening on the bug front which kind of makes me as a user wonder (general speaking for any user that might report a bug) why there's absolutely no recognition of what I spent my time reporting on here.
Do you get my point here with the mirroring you're trying to do here with your internal and public bug reporter and the problem of keeping them in synchronisation. There're just not linked at all to me as the bug IDs are different as well.
---end of general criticism about the bug reporting system---
I just wanted to add a personal note on the specific bug as it's an important one in my view especially because it's been around so long and involves a general privacy issue in my point of view.
Clearly it's most important when I delete a photo that the photo is totally not accessible anymore. It's understandable that you can't erase it immeadiately from all your backups as this takes time.
Still I also think that the whole photo page (including the caption) should be inaccessable as well from the point I delete the photo, which is apparently not the case and that's why I deleted the photo. It's especially essential in terms of google and other search engines dropping the link to the photo, but this only happens if you can't access the photo page anymore.
In my reported example which possibly could apply to a (big) number of other deleted photos it's been around 6 months without a resolution. You're constantly innovating and enhancing my experience, but I think that bugs really should have a higher priority over new features. It doesn't matter if it's a small or big bug - the annoyance with the user is usually higher than think. Normally you fix stuff way quicker than any other company, but there are sometimes issues (I can't name any right now) that take way to long to be resolved.
Sebastian
Sebastian, I have raised this again with the SmugSorcerers - thanks for your continued patience.
Update on this: it is still (well, actually) an issue. I get that the initial link I gave was malformed, but I hope this one isnt: http://renstar.smugmug.com/gallery/2694311
The photo info again does not load properly. In photos with exif, it loads, but the filename and photo dimensions (which are more important on the pano) don't show.
Update on this: it is still (well, actually) an issue. I get that the initial link I gave was malformed, but I hope this one isnt: http://renstar.smugmug.com/gallery/2694311
The photo info again does not load properly. In photos with exif, it loads, but the filename and photo dimensions (which are more important on the pano) don't show.
-Russ
Hi Russ,in the one just prior to it, the dimesions show. We'll pick up the dimensions if they are there in the exif properly.
Ren... looking at your pano, I'm wondering if (#1) the SW you're using to stitch is stripping the EXIF data? (#2) Or if you're using a new template in the SW, the EXIF is not being transferred. (I think the 2nd may be the case) Can you please share the SW you're using?
Ren... looking at your pano, I'm wondering if (#1) the SW you're using to stitch is stripping the EXIF data? (#2) Or if you're using a new template in the SW, the EXIF is not being transferred. (I think the 2nd may be the case) Can you please share the SW you're using?
Thanks...
I'm using panorama factory, I know the exif gets stripped, and that wasnt bothering me, it was the smugmug page not loading info that it knows (and loads) anyway, when the page is accessed from a slightly different URL. Andy passed it on and im sure it will be fixed sometime. It is a relatively minor thing that can be easily missed, which is why i was passing it on. It really wont be that bothersome to me if it takes a long time to fix as I'm sure there is much more important work to be done.
I can always use breezebrowser to put some of the capture exif in, but at this point its not that big a deal to me. Thanks for the offer of help though
Shopping cart glitch
Great addition to the product catalogue with the canvas prints. Just so happens I had someone ask me for these last week! I was checking them out and I found a glitch.
The default crop box for 16x20 mounted canvas is the opposite orientation as the image.
The 16x20 rolled canvas looks fine.
It's more of an anoyance than anything but I thought you might want to know.
Great addition to the product catalogue with the canvas prints. Just so happens I had someone ask me for these last week! I was checking them out and I found a glitch.
The default crop box for 16x20 mounted canvas is the opposite orientation as the image.
The 16x20 rolled canvas looks fine.
It's more of an anoyance than anything but I thought you might want to know.
Yeah I've logged it.
You can hit the red crop button and flip the crop
Problem with drop-down tools and back button
I keep running into a real problem with the drop-down tools in a gallery. Here's what happens:
I pick a photo. I decide I want to see what the Smugmug color correction options look like for that photo so I pick "Color Effects" from the tool drop-down. I examine the different color choices. I decide I don't want any of them. I hit the back button in the browser (there appears to be no other way to cancel that page). Now I advance to another photo. I want to look at the color effects choices there. There's no way to do it. The back-button left the color effects item chosen in the drop-down and there is now no way to trigger that action. Since clicking on a different photo in the gallery no longer reloads the page, that won't even fix the drop-down. Even going to another page of images in the same gallery won't change the drop-down.
The ONLY way to select color effects on any other image in the gallery is to leave the gallery entirely and then come back again, find the image I want and start over from there.
This makes it impossible to go through a bunch of images in the same gallery apply color effects to some and not to others.
The choices I can see are:
Fix the drop-down so you can still trigger the color effects action even if it was previously selected (probably requires Javascript).
Add a cancel button to the color effects page so if I don't want the choices, I don't have to use the back-button - I can use the cancel button that won't leave the color effects item chosen in the drop-down.
Change the design of the color effects page in some other way that couldn't have this problem.
Change the selection of a commands like color effects in some other way that couldn't have this problem.
It seems that the same issue could happen to almost any of the commands in the right drop-down (crop photo, Zoom thumbnail, Color Effects, Edit this caption/keyword, edit geography). Anytime you might want to visit several different photos, examine the effect of a command on that photo and then cancel some of them with the back button. Once you've hit Back, you can no longer choose that command on any photo in the gallery without leaving the gallery first.
Note, this problem is mostly a side effect of the January JavaScript changes that do preloading and skip page loads. The problem has always existed, but previously you could just select any other image in the gallery and the problem would fix itself. Now, selecting another image does not do a page reload so the problem stays until you leave the gallery - making it more of an issue.
Note, this problem is mostly a side effect of the January JavaScript changes that do preloading and skip page loads. The problem has always existed, but previously you could just select any other image in the gallery and the problem would fix itself. Now, selecting another image does not do a page reload so the problem stays until you leave the gallery - making it more of an issue.
JT's aware and promises something with this in a future release. Thanks John for making the posting about it
Problem with displaying pictures on office PC
Hello Smugmug Team,
first of all I must say I am really happy with the services you offer. Even being in Germany, the performance is great (especially after the remake of your site)!
Since the remake I do have a problem in displaying the pictures on my PC at work (at home its fine). On both systems I am running Firefox 2.
At work the whole page looks fine, just the pictures are not shown at all.
Screenshot below:
I have tried deleting the cache and cookies, etc as posted in other threads in this forum but nothing helps.
Can this be blocked by firewalls in the office or something like that?
What other options can I try to get it running?
first of all I must say I am really happy with the services you offer. Even being in Germany, the performance is great (especially after the remake of your site)!
Since the remake I do have a problem in displaying the pictures on my PC at work (at home its fine). On both systems I am running Firefox 2.
At work the whole page looks fine, just the pictures are not shown at all.
Screenshot below:
I have tried deleting the cache and cookies, etc as posted in other threads in this forum but nothing helps.
Can this be blocked by firewalls in the office or something like that?
What other options can I try to get it running?
Many thanks
Dennis
That is exactly what a page looks like if JavaScript is not running in your pages from work. That could either be because it's being filtered at the company firewall or it could be because the browser setting for JavaScript is forced off. I believe you can currently still use some of the other views (like all thumbs) that don't need JavaScript to display images. There may also be other work-arounds like using a different browser where Smugmug defaults to the old-style view rather than the new JavaScript dynamic view.
That is exactly what a page looks like if JavaScript is not running in your pages from work. That could either be because it's being filtered at the company firewall or it could be because the browser setting for JavaScript is forced off. I believe you can currently still use some of the other views (like all thumbs) that don't need JavaScript to display images. There may also be other work-arounds like using a different browser where Smugmug defaults to the old-style view rather than the new JavaScript dynamic view.
Yep, chaning the view style works - just tried that. Also made a request that smugmug includes a fallback mechanism via < noscript> and that they display a note that this site needs JS to be fully operational.
Yep, chaning the view style works - just tried that. Also made a request that smugmug includes a fallback mechanism via < noscript> and that they display a note that this site needs JS to be fully operational.
Many thanks for the quick replies. I will give it a try on Monday and tell you how things are.
But you may be right that our firewall block JS. In MS IE it doesn't work either.
Comments
I haven't seen anything documented for Smugmug URL construction so relying on something that you don't see being used in your galleries probably isn't a wise thing. In the first URL,
http://renstar.smugmug.com/gallery/2657204/18/
The 2657204 is the gallery ID. The 18 is the page number in that gallery not a photo number. In some views that only show one photo per page, it appears to the the same as the photo sequence number, but I think it's really just the page number. If that page number doesn't exist, it appears that Smugmug ignores it. You can see this URL construction in play in the Journal gallery style when you go from one page to the next and it works in the Smugmug style too.
It's a worthwhile question of the Smugmug developers to see if they have a URL construction that gets you the Nth image in a gallery. I wouldn't be surprised if it exists, but I don't know what it is myself.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Thanks for the tip, works great and I can email it out to people with the number I want, cool.
Thanks John, that makes sense. I only use the views that are one-photo-per so I just assumed that it was actually the nth photo and not the nth page. Either way I still think it is odd that it can figure out what photo to display on that page but not figure out what exif to display. Seems like that would be a two line fix.
If you'd like to debate that with our engineers, cool - start a thread
Portfolio • Workshops • Facebook • Twitter
nah, no worries, it isnt a deal breaker. just wanted to make sure you all knew that a page seemingly rendered correctly with missing info
I think it depends on what style you have chosen, as different styles pagenate differently.
If you want to start on a specific image, your best bet is to use this notation...
http://[nickname].smugmug.com/gallery/[AlbumID]#[PhotoID]
Cheers,
David
SmugMug API Developer
My Photos
This has been reported in the Bug Reporter. However, its status has been changed to "Won't Fix", so I thought I would bring it up here, to warn people that it might happen.
(As an aside, if smugmug decide not to fix a reported bug, it would be polite to give the reasons for this decisions in the bug's comment field. Smugmug has a reputation for good customer support, leading to many users to help the company out, but by answering questions in the dgrin forums, and by properly reporting bugs via the Bug Reporter. If a bug is being reported, then it must be having an impact large enough to cause the user to research the bug-reporting procedure. By anonymously changing bugs to "Won't Fix" without giving a reason, smugmug is risking its reputation for customer service.)
If I go to the URL http://pbolchover.smugmug.com/keyword/houston-giraffe-houston%20zoo I get a gallery giving all photos containing the keywords "houston", "giraffe" and "houston zoo" In smugmug view, there is the option to remove keywords. If I then choose the option to remove the keyword "houston", I end up with the (incorrect) URL
http://pbolchover.smugmug.com/keyword/giraffe%20zoo
instead of the expected URL
http://pbolchover.smugmug.com/keyword/giraffe-houston%20zoo
The problem appears to be that removing the keyword "houston" actually removes all occurrances of the string "houston" from the list of keywords. This corrupts the multi-word keyword "houston zoo", leading to the error.
Portfolio • Workshops • Facebook • Twitter
Click on view all SmugBugs
Click on Smugbug 48 (the bug in question)
The changelog says
04/04/2007 03:13PM: Status changed from new to resolved by guest
04/04/2007 03:13PM: Resolution changed from open to wontfix by guest
Portfolio • Workshops • Facebook • Twitter
That kind of makes me wonder sometimes if it's worth actually taking the time posting a bug in the wiki - here on dgrin most of the time one of the team responds very quickly to the issues. The only time I got the impression that somethings changing on the wiki when I got that notification from the internal wiki - then I saw that someone had copied my entry, probably manually, into the internal wiki. That was 6 months after me reporting the bug on the public wiki.
What I actually want to say. Why not put some more work into access rights in the public wiki and use that instead of copying every bug report into your internal one which is then filed under a different ID to add to the confusion? Just make changing the status of a bug and all the other Admin stuff like deleting users an Admin only option. Why would you want to let a guest resolve a bug on the wiki anyways? Also only the one who filed the bug should be able to edit it. It's fine that guests can file bugs though.
With some access management and if the SM team actually starts using the public wiki as well, it should be more up-to-date and therefore more attractive for the customers to use. You can still keep your internal wiki for bugs discovered internally, but please handle the ones reported in the public wiki also publically.
Thanks for listening,
Sebastian
SmugMug Support Hero
Ouch Sebastian, I'm sorry it's confusing. I sent you a note last week letting you know that I reset it back. Have a look at bug 33
BTW, just file them here if you like. Thanks. I'll see if we can sort things out on the bug reporter!
Portfolio • Workshops • Facebook • Twitter
Basicly it was my point - the status of my bug always has been *new* (plus open for not being resolved yet) in the public bug reporter- just like it was when I filed it. To my knowledge it was never assigned to anyone. You just worked with the data in the internal bug reporter and, who ever has taken responibility for it, (I'm assuming here) forgot about updating the public bug reporter.
All in all this just looks like nothing is happening on the bug front which kind of makes me as a user wonder (general speaking for any user that might report a bug) why there's absolutely no recognition of what I spent my time reporting on here.
Do you get my point here with the mirroring you're trying to do here with your internal and public bug reporter and the problem of keeping them in synchronisation. There're just not linked at all to me as the bug IDs are different as well.
---end of general criticism about the bug reporting system---
I just wanted to add a personal note on the specific bug as it's an important one in my view especially because it's been around so long and involves a general privacy issue in my point of view.
Clearly it's most important when I delete a photo that the photo is totally not accessible anymore. It's understandable that you can't erase it immeadiately from all your backups as this takes time.
Still I also think that the whole photo page (including the caption) should be inaccessable as well from the point I delete the photo, which is apparently not the case and that's why I deleted the photo. It's especially essential in terms of google and other search engines dropping the link to the photo, but this only happens if you can't access the photo page anymore.
In my reported example which possibly could apply to a (big) number of other deleted photos it's been around 6 months without a resolution. You're constantly innovating and enhancing my experience, but I think that bugs really should have a higher priority over new features. It doesn't matter if it's a small or big bug - the annoyance with the user is usually higher than think. Normally you fix stuff way quicker than any other company, but there are sometimes issues (I can't name any right now) that take way to long to be resolved.
Sebastian
SmugMug Support Hero
Portfolio • Workshops • Facebook • Twitter
Update on this: it is still (well, actually) an issue. I get that the initial link I gave was malformed, but I hope this one isnt:
http://renstar.smugmug.com/gallery/2694311
I got that link directly off of my category page which is smugmug generated:
http://renstar.smugmug.com/Colorado
The photo info again does not load properly. In photos with exif, it loads, but the filename and photo dimensions (which are more important on the pano) don't show.
-Russ
Portfolio • Workshops • Facebook • Twitter
Then why does it show here (this image has no exif as it is a pano stitch):
http://renstar.smugmug.com/photos/newexif.mg?ImageID=142693703
but not here (a photo that has valid exif):
http://renstar.smugmug.com/gallery/2696931
but here on the exact same photo..
http://renstar.smugmug.com/gallery/2696931/2/142838746
http://renstar.smugmug.com/photos/newexif.mg?ImageID=142838746
-r
Portfolio • Workshops • Facebook • Twitter
No problem, sorry I wasn't more clear earlier.
-r
Thanks...
I can always use breezebrowser to put some of the capture exif in, but at this point its not that big a deal to me. Thanks for the offer of help though
-r
Great addition to the product catalogue with the canvas prints. Just so happens I had someone ask me for these last week! I was checking them out and I found a glitch.
The default crop box for 16x20 mounted canvas is the opposite orientation as the image.
The 16x20 rolled canvas looks fine.
It's more of an anoyance than anything but I thought you might want to know.
SmugMug Technical Account Manager
Travel = good. Woo, shooting!
nickwphoto
You can hit the red crop button and flip the crop
Thanks!
Portfolio • Workshops • Facebook • Twitter
I keep running into a real problem with the drop-down tools in a gallery. Here's what happens:
I pick a photo. I decide I want to see what the Smugmug color correction options look like for that photo so I pick "Color Effects" from the tool drop-down. I examine the different color choices. I decide I don't want any of them. I hit the back button in the browser (there appears to be no other way to cancel that page). Now I advance to another photo. I want to look at the color effects choices there. There's no way to do it. The back-button left the color effects item chosen in the drop-down and there is now no way to trigger that action. Since clicking on a different photo in the gallery no longer reloads the page, that won't even fix the drop-down. Even going to another page of images in the same gallery won't change the drop-down.
The ONLY way to select color effects on any other image in the gallery is to leave the gallery entirely and then come back again, find the image I want and start over from there.
This makes it impossible to go through a bunch of images in the same gallery apply color effects to some and not to others.
The choices I can see are:
- Fix the drop-down so you can still trigger the color effects action even if it was previously selected (probably requires Javascript).
- Add a cancel button to the color effects page so if I don't want the choices, I don't have to use the back-button - I can use the cancel button that won't leave the color effects item chosen in the drop-down.
- Change the design of the color effects page in some other way that couldn't have this problem.
- Change the selection of a commands like color effects in some other way that couldn't have this problem.
It seems that the same issue could happen to almost any of the commands in the right drop-down (crop photo, Zoom thumbnail, Color Effects, Edit this caption/keyword, edit geography). Anytime you might want to visit several different photos, examine the effect of a command on that photo and then cancel some of them with the back button. Once you've hit Back, you can no longer choose that command on any photo in the gallery without leaving the gallery first.Note, this problem is mostly a side effect of the January JavaScript changes that do preloading and skip page loads. The problem has always existed, but previously you could just select any other image in the gallery and the problem would fix itself. Now, selecting another image does not do a page reload so the problem stays until you leave the gallery - making it more of an issue.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Portfolio • Workshops • Facebook • Twitter
Hello Smugmug Team,
first of all I must say I am really happy with the services you offer. Even being in Germany, the performance is great (especially after the remake of your site)!
Since the remake I do have a problem in displaying the pictures on my PC at work (at home its fine). On both systems I am running Firefox 2.
At work the whole page looks fine, just the pictures are not shown at all.
Screenshot below:
I have tried deleting the cache and cookies, etc as posted in other threads in this forum but nothing helps.
Can this be blocked by firewalls in the office or something like that?
What other options can I try to get it running?
Many thanks
Dennis
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Sebastian
SmugMug Support Hero
Portfolio • Workshops • Facebook • Twitter
Many thanks for the quick replies. I will give it a try on Monday and tell you how things are.
But you may be right that our firewall block JS. In MS IE it doesn't work either.
Cheers
Dennis