Hi there,

I'm attempting to generate cache of all our thumbnails for all our images. The reason why I want to do this is because we have a php script that pulls a random set of thumbnails from the database and combines them into a single JPEG image that is then displayed in our email signature (the email signature calls the php script which returns the image). As far as I understand it, the script tries to get the URL of the cached thumbnails, and generates the combined image from the URLs given to it from ZenPhoto. Unfortunately, since upgrading to 1.4.3, this no longer works.

The script is below;

`

`
I'm getting errors in the error_log that suggests that the URL zenphoto returns is trying to create a new thumbnail, rather than using the cached file. So I tried to pre-cache the thumbnails. This seems to work, however when clicking on the little thumbnail icon in overview-Cache page, it gives me the Debug i.php page for the thumbnail, and the image link is broken. If I look at the link to the image, it is;

http://www.domain.com/zp-core/http%3A//www.domain.com/cache/motion/4e8a9d558dec0163873abeba1e44603effb17979.jpg

Maybe that doesn't matter, I'm not sure if that's really the problem. The error that we get in the error_log from ZenPhoto is;

[31-Jul-2012 11:23:34] PHP Warning: imagecreatefromjpeg(./zp-core/i.php?a=retouching/nokia&i=Nokia-Guitar-RGB-Final_WEB_ZP.jpg&w=71&h=71&c=1&cw=975&ch=975&cx=0&cy=139&q=75&t=1&wmk=!) [function.imagecreatefromjpeg]: failed to open stream: No such file or directory in /home2/username/public_html/signature_strip.php on line 36
[31-Jul-2012 11:23:34] PHP Warning: imagecopy(): supplied argument is not a valid Image resource in /home2/username/public_html/signature_strip.php on line 37

So it seems our signature_strip.php script asks for the URL of the thumbnail, ZenPhoto doesn't think it isn't cached so it returns a URL that generates a new thumbnail, however this is something that our script cannot handle? Is that correct? Or do I not understand it properly? Apologies as I did not write the script and I am not a PHP programmer. I am trying to find the root of the problem so I can either try and fix it myself, or better describe the issue to someone who is better versed in PHP.

Any help with this would be greatly appreciated!

thanks!
Tristan.

I have no time to dig into this. Class methods like getAlbumThumb() get either the url to the cached image if it exists already or if it does not exist yet to the image processor to get it.

I suggest maybe to use the full images instead (use the unprotected full image functions as full images are cached as well if set to protected for watermarks etc).

Hi Acrylian! Thanks for the reply. We'll look at trying to somehow crop and use the full image instead, however it still doesn't make sense to me, as all the thumbnails are cached already. I've been through the whole website (it's not that big), all thumbnails have been generated and displayed on the site, yet the getAlbumThumb() always returns the image processor. I tried using the pre-caching as a desperate last measure, as I thought that perhaps ZenPhoto was trying to fetch a different cache other than what the user sees. Is it possible there is a bug and that getAlbumThumb is not fetching the cached version when it should?

What changed is that all images are cached. Since the gallery part is file system based the cost of performance to compare always if or not is too much so they all are. But I think that was introduced with 1.4.2 already.

You meantion a wrong link above. Try setting the webpath in the config file manually.

I'm sorry I'm not sure I understand? If all images are cached (including thumbnails), why does getAlbumThumb() always return the image processor? Shouldn't it always return the cache then?

I can confirm that all the thumbnails are cached - I've checked all the thumbnails on the site when displayed and they all are sourced from cache. So if as you say getAlbumThumb() will get the url to the cached image if it exists already then surely it should return the URL of the cached thumbnail and not the image processor?

It should not do this. If it does it might be a bug. Do you use the html static cache plugin and call the above functions on a Zenphoto theme page? In that case clear the html cache as that plainly caches a html page and if there are calls to an image processor - which it cannot know - it will cache that as well.

You might want to try the nightly build. If I remember correctly there was some problem with some types of thumbnails such that the cache was not being checked. Sorry, I do not remember the details.

Ok thanks I'll try the nightly and see how I go.

Hi there.

So I tried the nightly and no luck. I have noticed however that two of our thumbnails work (out of about 80). They are from the two subalbums that have been created since upgrading to 1.4.3. So the question is, why do newly created subalbum thumbnails correctly return to getAlbumThumb() whereas all older jobs return the image processor? Obviously we would like to avoid the scenario of having to re-add all of our subalbums to get this working...?

Acrylian you said;

You meantion a wrong link above. Try setting the webpath in the config file manually.

regarding the incorrect link on the debug cache page for thumbnails - to which config file do you refer?

Also, which thumbnail cache does the getAlbumThumb() fetch exactly? When I try to pre-generate the cache, there is a list of many options - which one is ZenPhoto supposed to grab using getAlbumThumb()? I.e. which one should I be trying to generate/regenerate?

thanks,
Tristan.

The config file within zp-data of course.

getAlbumThumb() fetches the default or standard thumb image size as set on the options. The cachemanager does allow you to set specific image sizes to precache if your theme uses custom size (e.g. those set on the theme layout and not options).

I suppose that if the new images work and the old ones do not the simple solution would be to purge the image cache. Then all the images would be "new" so far as the cache is concerned. You can also try using the refresh-metadata button, again makes old images look new.

Hi there. Unfortunately purging the image cache doesn't work. Already tried that as a troubleshooting measure when it stopped working after first upgrading to 1.4.3. Is it possible that the new jobs are caching to a different location? Or are they stored differently in the database? What might have changed to cause this?

Ok, so I set the webpath and server path in the config manually and it still doesn't link the thumbnail in the debug correctly.

Following this process;

1. Edit album
2. Click 'Cache album images'
3. Apply 'default_85_cw71_ch71_thumb'
4. Provided they are not already cached, thumbnails are created and (in my test case) three small thumbnails appear on a line '3d/job { x | x | x } [3 images]'
5. Click on one of the tiny thumbnails before [3 images] and it opens a new debug page for the thumbnail image;
6. Following the 'Debug i.php | Arguments:' list, there is a line that says 'Image:'. After 'Image:' there is a broken link to the newly generated thumbnail.

The broken link listed on the debug page is;
/zp-core/http://www.domain.com.au/cache/3d/job/eb0cbe39a7151d199226c5485578323f60ec486b.jpg

When it should be;
http://www.domain.com.au/cache/3d/job/eb0cbe39a7151d199226c5485578323f60ec486b.jpg

Is this related possibly to my thumbnail woes? Or something else?

Thank you kindly for all your help and responses so far.

Haven't tried refreshing the metadata. Will do now and will report back.

Ok. So I;

1. Cleared the image cache.
2. Recreated the default and admin thumbnails.
3. Refreshed the metadata.
4. Browsed the whole website to check existence of thumbnails and force it to generate any that might not have been generated for some strange reason

and now still no thumbnails returned by getAlbumThumb() in our script.

And, unfortunately, I now no longer get the thumbnails from the two newer albums that I used to get successfully.

In our theme options, we have the thumbnail size set to 85. Crop is set to 8.23529411765%, left and right, top and bottom. It says next to thumb size 'Standard thumbnails will be scaled to 85 pixels.' When I navigate the the album or subalbum on the webpage and check the dimensions of the thumbnails, they are indeed 85px x 85px. Under the sizes provided by the cache manager, 'default' is set to size 85, crop 71 x 71. How do I pre-generate the thumbnails used by our theme? Or is this not possible?

I also tried feeding in the error I get back from the script into a browser to try and see what the image processor is returning;

In a browser window I entered this (an extract from the error I got in the logs);

http://www.mydomain.com.au/zp-core/i.php?a=3d/top-model&i=TM_spaceship_Final_WEB_ZP.jpg&w=71&h=71&c=1&cw=911&ch=911&cx=293&cy=94&q=75&t=1&wmk=!

And I get a blank page. The logs then have;

Backtrace: USER NOTICE: Too few arguments! Image not found. in /home2/username/public_html/zp-core/functions-image.php on line 33

trigger_error called

from imageError (functions-image.php [33])

from i.php [41]

If it is the site linked in your profile all thumbs seem to be cached to me. Some of the big images are not when I visited them the first time but then they are.

The site is crashed a few times in Safari 6 but that might be a server glitch.
I recommend to check the JS stuff you are doing as FF reports a few errors.

Hi acrylian. Yes it is the site linked in my profile. As I far as I can tell too, the thumbs are cached. This is why I cannot work out why our script does not work, and is always getting the image processor. You can test it if you go to our domain and add;

/signature_strip.php

you can see any relevant php details at;

/phpinfo.php

Thanks for the heads up on the javascript errors - it's nothing major - I believe it's related to using an older version of google analytics. I've used Safari 6 a fair bit on the site and am yet to see problems myself so I'm hoping that is just a server glitch.

If I access that page I see this html:
``

That is of course really nonsense. COuld you maybe tell us what this is supposed to do? If that is supposed to be a custom page in Zenphoto context it is wrong:
http://www.zenphoto.org/news/theming-tutorial#custom-pages-with-the-example-of-archivephp-and-sl