Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
Hello,
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 !
Comments
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?
Yes, I do use image names from my cameras, so, they are numbered.
Example
(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]
This might indicate the issue I have mentioned
I-IMG_6242.JPGis 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:Please try the same image but with a different filename not ending with a number.
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.
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.
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.
That's is really weird and should not happen. We have not change anything related to this…
I have downgraded my online site to 1.5.1 : 800 px are generated (and displayed with image.php) like before.
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.
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.
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.
So far I have not been able to reproduce this either.
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 ...
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.
Edit : yes, erasing database entries resets everything.
I've just set pictures size to 800px, and
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.
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.
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.
Thanks for investigation. We will try to reproduce this.
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.
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.
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 ;-)
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.
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.
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…
@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.
I have not tried the new support buid yet, I will do it soon.
Remark
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 !
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.
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.
Thanks for the feedback!
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.