The little x's (`3d/job { x | x | x } [3 images]) are because the particular image failed to render for the size. Clicking on the x is supposed to take you to the debug page where anyting displayed about the failure will be shown. What actaully gets shown will depend on you PHP settings. If you have it set to show PHP errors on the WEB page, then these errors will be displayed and help you know why the images did not render.

The broken link itself seems to be a bug. Fixed in the nightly build. But probably not useful in this case since the image will not be rendered.

Hi acrylian. Thanks for the response. Actually it's not nonsense, it's what the script is meant to do - only it unfortunately doesn't work anymore since upgrading to 1.4.3 because of the behavior of getAlbumThumb() that I've been describing. I explained in my first post what it does, but perhaps I wasn't clear? If so I apologise. The script grabs a number of random thumbnails from subablums, then attempts to combine those thumbs together and returns them as an image. Because this is for use in an email signature, the data that is returned is an image so it can be displayed in the email client. It is now failing, where it used to work fine, because since 1.4.3 (seemingly regardless of the existence of a cached thumb or not) zenphoto is returning the image processor instead of the cached thumb, and the php function used in our script to combine the images is expecting a jpg back and not a php url. As I said, I tried using the url that the image processor is returning, and I couldn't seem to get it to make an image anyway, but I'm not sure if it's supposed to on it's own or not?

sbillard - I'm sorry I wasn't more clear - there aren't three x's on the line (`3d/job { x | x | x } [3 images]) - there are three thumbnail images, correctly generated and rendered. When I click on one of them it takes me to the debug page, and to the bug I described. Thanks for fixing it, perhaps it may help me.

I understand this is frustrating for you, and I apologise. It is very frustrating for me as well, and I am trying to work out what has changed so I can fix it, or if it is in fact a problem in zenphoto, and I am trying to give the best feedback I can to you so that it can be resolved. It seems that our script is perhaps still ok, and something may have gone awry somewhere in zenphoto's thumb caching, as I had two thumbs working ok with the script (from subalbums that had been created since upgrading to 1.4.3), but nothing else worked, and since I cleared the cache and regenerated all the thumbnails, and refreshed the metadata, now even those two don't work.

Please let me know if anything is still unclear, or if you need any more information from me.

thanks,
Tristan.

The bug fix will not help you. It comes into play only when attempting to debug and image renditions.

I guess the first thing I would do if I were you is reset the `Obscure cache filenames` option so you have a better clue as to what is in your cache. With that not set the file names have the sizing parameters imbedded. Most likely you are not getting a thumbnail of the same sizing as you have cached.

There could be many reasons for this, but most likely would be that when you run that script you do not have the theme (and therefore the theme options) properly established.

Hi there. Thanks for the quick response. I'll keep trying.

Could you please remove our website URL from the earlier post?

Thanks again,
Tristan.

I indeed missed the explaination above somehow, sorry for that. I would try to make a theme custom page out of this, then you can be sure that all Zenphoto functions are available.

The url has been removed.