Gary Glass wrote:
Well, I didn't explain that the way I got to that view was just by clicking on the image in a large single image view. E.g.:http://www.shutterglass.com/gallery/2066860_cS9Lj/2/106382114_uDE5K/Large
IIRC, that action used to open the image in an overlay box. But even if I do not recall correctly, the current behavior doesn't make sense to me. It doesn't make sense that clicking on the image loads a larger size of the image inside a container that is too small to show it.
Scott McLeod Photo wrote:
I have some batch actions that I perform on some images so that after they are uploaded usually about half need rotating. Well for about the last 2 weeks, I select all the images and rotate, every time 2 or 3 off about 200 are rotated twice thus requiring a another rotation back. This is beginning to be a real p.i.a. because sometimes it may not show up until after I have visually checked the gallery and made it public for the customer.
Please fix it.
Hello Scott, we'd need to see the specific images, thanks!
I noticed some peculiar behavior regarding the search function when looking through a subcategory. If you navigate to a subcategory and perform a search: such as on this page, the results are returned as expected. If you try searching again (now on the results page), things go wildly wrong. Whatever term you search for will look through "Don MacAskill's Cats Photos." This is a real problem, especially if you have users relying heavily on the search function. My hypothesis is that the search page script is not properly parsing the URL to identify the subcategory ID that needs to be searched. Instead, the script defaults to "SubCategoryID=1," which happens to be Mr. MacAskill's cat subcategory.
This problem only exists with subcategories, as far as I can tell. I presume they are not used as frequently, but I'm surprised this bug has not been caught. Should be any easy fix, though. Regardless, I am extremely pleased with SmugMug. Keep up the good work.
User status: this occurs both when logged in and logged out
Brower: IE 8 and FF 3
In some of my recent photos, the exif data does not show up, not even "date taken". The weird thing is that it is happening only with some photos, others taken on the same day are fine. I tried uploading them again, no change. The data is fine in iPhoto. The first three in this gallery are missing the info:http://mattkr.smugmug.com/gallery/7524536_9qrY3#483606010_3etNn
I don't see the invalid URL issue on the gallery slideshow, but I do see it hitting pixel.quantserve.com for every single image it loads in the slideshow. Is that intended?
I have no idea how long ago I first reported this problem (it feels like 6 months ago), but it remains unfixed.
If some unfortunate sole puts this line in their homepage slideshow declaration:
thinking that this is how you say you don't want a splash screen, then slideshow code will eat 100% of a CPU (on Windows Vista, I don't know about other flash platforms). It's really horrible. If you don't have multiple CPUs, it can cripple your ability to use the computer until you realize you have to close that site.
Apparently, the slideshow code is not handling errors well and it goes into some sort of infinite loop when it gets an invalid URL for the splash screen. A little defensive coding with decent error handling should prevent this entirely.
I've written about this a couple times before, but I'm writing about it again because I keep seeing users and viewers inflicted by it and it was so long ago that I first wrote about it, that I have no idea if it's actually going to be fixed or not and it's unlikely it's a particularly time consuming fix. I would think that the folks at Smugmug would be horrified that there are customer's sites out there inflicting serious CPU hogging and sullying the reputation of Smugmug and it's slideshow design. That's why I'm surprised it hasn't been prioritized high enough to get fixed.
The latest victim I've run into is here, though hopefully he will fix his site as I've advised him.
This issue I believe is fixed, can you let us know if you see this issue again?
Also fixed with slideshow:
* the caption truncation bug
* no longer see the print menu when you right click on the sildeshow
* if you have a bad link in for the splash image on the homepage slideshow, it no longer breaks
* memory usage is improved
Also large captions cover the photo.
The captions for the fullscreen slideshow are completely useless unless
html is hidden and not transferred to the show caption. Can it be coded to
ignore anything inside html tags?
Over the past few weeks I have found that my Smugmug galleries don't show any pictures when I use the Safari browser. This used to be an intermittent problem, but has now become constant. My homepage shows OK, but when I click on a gallery, there are no thumbnails or large photos. This doesn't appear to be a problem when I use Firefox.
My homepage slideshow, http://markchapmanphotography.com, works both at home and anywhere else. When I go to one of my galleries and click on slideshow:
The slideshow works at my desktop at work, but not on my home desktop.
It use to, but now it will start and show a maximum of two pages and then quit.
Is there a setting on IE or other that I need to look at?
Mark Chapman[email protected]
Scott McLeod Photo wrote:
Next time it happens I will email the specific images, should I do it after it initially over rotates. I finished all the work from events this past weekend, and didn't document the images numbers, was in a hurry to get things up for customers and wasn't sure how soon someone could get on it. But it has happened in 12 galleries at least 2 images per gallery, but from one gallery today it happened to 5 images. This is over the past two weekends.
This Smugmug user is reporting a problem with their slideshow: http://www.markchapmanphotography.com/.
When I look at the network trace, I see that the slideshow is requesting some bogus image URLs, getting 404 errors on them and then the slideshow sometimes stops working properly.
Here's an example of a network request from that slideshow that generates an error (because it's a mal-formed image URL):
GET /photos/486380349_Tq600x600Z-Ti-0.jpg HTTP/1.1
Note the "Z" after the 600x600 which is not supposed to be there. Also, I have no idea why the slideshow is even trying to fetch thumbnails since they are not being displayed in this slideshow. The user reports that the gallery slideshow has the same problem.
Here's the thread of their original report:http://www.dgrin.com/showthread.php?p=1061375#post1061375
This problem seems 100% reproducible to me.
Taylor, you have your gallery that houses the banner passworded. You can leave it unlisted but you need to remove the password. Passwords break banners as does hiding the image.