Some cached images are not generated -1.5.2 and 1.5.3b


I've got a problem with the cached images :
Adding a new photo, my basic theme is using a 800x450 size, thumbs are generated but not _800 files.
So, when cliking a thumb, I do not get any picture. But the name of the picture does open the colorbox picture.

All pictures added before 1.5.3 upgrade are ok (_800 cached images were generated)

Under 1.5.1, for example, I get a 926e0d51d543b9c976d9c3540bf8d19226302f33.I-IMG_6226_800_filigrane.jpg file, and this picture is used when I click the thumb named I-IMG_6226

From 1.5.3b, I downgraded my localhost machine to 1.5.2 -> same problem.
I downgraded my localhost machine to 1.5.1 -> problem solved

When I edit the image, and try to crop my image under 1.5.2 or 1.5.3b, I get a blank large frame with a very small black square.

My themeoption.php does contain this line :
setThemeOptionDefault('image_size', 800);

Of course, I know I can downgrade my online site to 1.5.1, but I'd like to keep 1.5.3b !


  • acrylian Administrator, Developer
    edited June 2019

    The 800px files generally will only be generated if the size of the original is larger than this, If hte same already or smaller it is not (unless you enable upscaling on the backend which is really not recommend for quality). But I guess that you do know already ;-)

    Actually we did not change anything from 1.5.1 to 1.5.2/3 in this regard. We did from 1.5 to 1.5.1 as we accidentally broke cache file naming respectively changed them.

    Do you have original image file names with numbers at the end like image_530.jpg? This is a not solvable bug as ZP misunderstands the _530 as a 530px sized image although it is a full size image. But this was the case for forever.

    Besides can you point me to an image in question, especially a full image so we can try to reproduce this?

  • ctdlg Member

    Yes, I do use image names from my cameras, so, they are numbered.

    (not published yet)

    I do get errors in debug log file :

    {19928:Tue, 04 Jun 2019 17:37:57 GMT}
    WARNING: imagecopy() expects parameter 2 to be resource, boolean given in /home/clatique/public_html/multimedia/zp-core/lib-GD.php on line 186
    imagecopy called from zp_copyCanvas (lib-GD.php [186])
    from cacheImage (functions-image.php [485])
    from i.php [166]

    Screen capture

  • acrylian Administrator, Developer

    This might indicate the issue I have mentioned I-IMG_6242.JPG is technically a cache file name for a size of 6242 so it is not processed as ZP mistakes the number for the size. This actually should have always caused problems even in 1.5.1. There was a lengthly discussion about this with Vincent about this (either here on the forum or on a ticket). We cannot solves this without changing the cachce file name and invalidating lots of cache files. As mentioned we accidentally did that with 1.5 and reverted therefore. Extract from the 1.5.1 release post:

    Fixes various issues with (default image size) image cache file names unnecessarily introduced in 1.5. This resulted in non properly generated images and due wrong filename invalidated actually proper cache files. We apologize that this caused some troube for some users with large galleries.

    Please try the same image but with a different filename not ending with a number.

  • ctdlg Member

    I renamed my new pictures without numbers.
    Same problem : the image cache for my 800 px width is not generated, trying to crop the image gives a small black square inside the frame.
    I will try to understand what is happening.

  • ctdlg Member

    Erased logs and album cache.
    I refreshed album page, thumbs were created - no error in logs.

    I clicked a new picture thumb, after some seconds, the frame of the picture disappears. Logs show :

    {20860:Wed, 05 Jun 2019 05:37:15 GMT} Zenphoto v1.5.3b
    WARNING: imagecopy() expects parameter 2 to be resource, boolean given in /home/clatique/public_html/multimedia/zp-core/lib-GD.php on line 186
    imagecopy called from zp_copyCanvas (lib-GD.php [186])
    from cacheImage (functions-image.php [485])
    from i.php [166]

    I tried unhiding cached file names in the security option page, pictures showed ( cache was created for 800px new pictures. )

    Eureka ? No :
    I erased the cache to build a new one. Again, no 800 px picture cache. Cannot display my new pictures at 800 px !

    Setting the security of cached images On/off does not solve the problem anymore.

    But one thing was strange : after changing the security for the 1st time, I had to proceed to a new installation check, the operation we have to do after upgrading/downgrading.

  • acrylian Administrator, Developer

    I did review the issue discussion and this can indeed not be the issue here. The issue arises when a cache file name is requested outside image/album context which also triggers cache generation. This happens within articles and not on image pages.

    I will try to reproduce this with files.

    But one thing was strange : after changing the security for the 1st time, I had to proceed to a new installation check, the operation we have to do after upgrading/downgrading.

    That's is really weird and should not happen. We have not change anything related to this…

  • ctdlg Member

    I have downgraded my online site to 1.5.1 : 800 px are generated (and displayed with image.php) like before.

    • if I click on a new image thumb with no 800 px image cache
    • if I build the cache from the album admin panel

    I will try upgrading my localhost machine, step by step, folder by folder.
    What I know right now : problem comes from zp-core folder on my zenphoto cms or configuration.
    new 1.5.3 root index.php and plugins folder are ok.

    I will keep you updated.

  • acrylian Administrator, Developer

    I am not aware we changed anything here from 1.5.1, although I have a suspicion right now where the issue could be. I will run some test very soon.

  • acrylian Administrator, Developer

    Sadly I am not able to reproduce any issue neither locally nor on our own server. 800px images are created as always with obsucred cache names or without.

    I tried the same name as your image even with the uppercase suffix as that was my suspicion something here broke with some transparency additions. But all works as expected for me.

    I found another small issue with the "cache as" option listing file types if may not support at all (like webp) if using GD. But regardless of that it worked for me…

    Is it really all images or only certain ones? If the latter I need one of the original images to try.

  • fretzl Administrator, Developer

    So far I have not been able to reproduce this either.

  • ctdlg Member

    I did a fresh install (1.5.3b) on my localhost machine, copied 2 albums.
    All was fine : cache manager was working with 800px pictures.
    Then I set all config tabs settings like those from my localhost machine.
    I cleared the cache, and ... 800 px pictures are not generated.

    There is a conflict between cache manager and my config !

    Is there a way to reset all parameters to it's original values ?

    I will try erasing all database values from my fresh install, start again installation... and check setting by setting ...

  • acrylian Administrator, Developer

    This is weird. Could you please tell me exactly what settings you did? Perhaps you could send me screenshots of that via mail (English backend please ;-))
    The cache manager does what the site does on the fly as well. It's generally all the same technique behind it.

  • ctdlg Member

    Edit : yes, erasing database entries resets everything.
    I've just set pictures size to 800px, and

    • cache is working again with cache album images button.
    • or simply clicking a thumb, also generates 800 px cache image.

    I have set all the plugins I use on my gallery, to the new one : it is still working, so plugins are not involved.

    I have to clear album image cache before each attempt.

    Of course, I could do screenshots of all my settings, but it is not necessary : now, I know I will find what is wrong.

    I have a working and a non working zenphoto installations on my localhost, I split my screen in 2 : the good one on the left, the defective one on the right.

    End of today's testing : I will keep you informed tomorrow. I do hope to explain you what conflicts with cachemanager !
    Thank you very much for all your help.

  • acrylian Administrator, Developer

    Okay, looking forward to more info and appreciate the help. If we can reproduce this then we need to fix it before we can release 1.5.3 which is actually ready otherwise.

  • ctdlg Member

    Problem finally found : watermark is the problem.

    This setting is OK : 800 px cache images are created

    This setting does not work : 800 px cache images are not created

    My watermark is a png picture, 33x18 pixels inside plugins/watermarks folder.

    You should be able to reproduce my problem.

  • acrylian Administrator, Developer

    Thanks for investigation. We will try to reproduce this.

  • acrylian Administrator, Developer
    edited June 2019

    Seems we can reproduce issues with this. It seems to be related to fixing the PNG and gif alpha transparency on scaled images in 1.5.2. We did test all this exensively but there seem to be special conditions where it doesn't work.

    Sadly we need to release 1.5.3 without a fix as the fresh install bug fix is currently more important. This fix is going to take longer and will therefore not happen before 1.5.4 sadly.

  • ctdlg Member

    It seems size of the watermark we use is the problem :
    I made a new filigrane.png, 1920x1080, replaced the file located in the plugin folder, and it does work.

    If I replace your watermark.png file (zp-core/watermarks), same problem depending of picture size.

    100x75px does work, 50x30 does not work.

    Tested with filigrane and watermark options.

    So, simply mention the fact that your picture must be at least 100x75px large.

    It's not sad you are about to release 1.5.3 !
    it's great.

  • acrylian Administrator, Developer
    edited June 2019

    Thanks, that is a good hint. But actually there should be no such size requirement but if a minimum size is the simplest and best fix we might do that. We will will investigate this further and fix whatever we manage to fix here as soon as we can ;-)

  • ctdlg Member

    I've upgraded again my online site, from 1.5.1 to 1.53.b, and changed the filigrane.png (I've made a 600x320 picture)
    Online site is OK. No more cache problem.

    Appreciate the backend option that allow you to select all, unpublished or published pictures.
    For sure, I will find other useful new possibilities.

  • acrylian Administrator, Developer

    Okay, thanks. Perhaps having just a minimum size requirement for watermark images is a pragmatic fix. Afterall you can define how large it should become in relation on the image later.

  • acrylian Administrator, Developer

    It seems there is no general minimum size recommendation possible. If it works correctly depends on the watermark size and the resized size of the image depending on the percentage value and if upscaling is allowed. So it is a bit relative because of that.

    So recommendation would be if it does not work, try a larger watermark right now…

  • acrylian Administrator, Developer

    @ctdlg Please try the support build again. The issue occured because of upscaling of watermarks or if the watermark was not resized at all. Since upscaling basically never looks good anyway, we also have removed that option now. So watermarks from now on never will be larger than their original size.

  • ctdlg Member

    I have not tried the new support buid yet, I will do it soon.


    I cleaned my image cache and rebuilt it.
    Many images end with a number, and I got no error rebuilding the cache. This was not supposed to work. ( now using 1.5.3b)
    I had no problem with 1.5.1 too.
    Example : "I-Img_6236.jpg" -> image caching gives me no problem.

    The only "error" is :
    only the 64 first albums are automatically scanned and computed.

    I had to enter all other albums admin pages manually to regenerate those caches.

    64 is 2 power 6.
    Strange behavior !

  • acrylian Administrator, Developer
    edited June 2019

    Check what mode of the cacheManger you are using. There are two now: The classic one and the newer cURL based one. The latter works better if it works as it somehow does not behave the same on all servers. Works fine locally and on our own but not on the server of my colleague.

    If you iuse the classic mode this is not reliably create all cached images and never did, you may have to run it several times. Thus the new way was introduced.

    Anyway, precaching is not necessary as ZP will do whenever needed.

    The support build has not changes in this area but please test for the actual issue regarding watermarks discussed here. We need the feedback for releasing 1.5.3.

  • ctdlg Member

    I've tried your new build, and I can confirm the actual issue regarding watermarks is solved.

    cURL does work on my server, 85 albums out of 120 were re-generated.

  • acrylian Administrator, Developer

    Thanks for the feedback!

    cURL does work on my server, 85 albums out of 120 were re-generated.

    Yes, but somehow the precaching does not work as expected on all servers. It works generally as intended if you see a frequently growing list of images/albums being processed. If you instead see a blank page for quite some time and all appears at once it does not. We haven't found out why this behaves so different on some servers. Therefore there is an option to use the old way as it was before, even if that is not that reliable either.

Sign In or Register to comment.