Image (Resize, Crop, ...) doesn't use previous generated files

It seems to me, that kirby’s thumb-generation not always uses the previous generated thumbs in thumbs-folder.

I have a website which uses intensively thumb-generation (resize, crop, quality). Although all thumbs exists, kirby generates them again. But the file-timestamps of the previous generated thumbs are unchanged.

Maybe kirby does not always identify previous generated thumbs and then tries to generate them again, and on save of these newly generated thumbs it doesn’t overwrite the existing ones.

Kirby Information:
Toolkit Version: 2.4.1
Kirby Version: 2.4.1
Panel Version: 2.4.1

If I understood you correctly, this is the same issue I have since some time:

No, sorry, that’s not the same. The files exists in the thumbs-folder.

Okay, so it’s actually the exact opposite? Your old thumbnails do not get deleted at all, and for me even the new ones are deleted and generated again.

Could it be a permission error that prevents Kirby from deleting the old thumbs for you?

No, in my casse, kirby should’nt delete the old files. Kirby has to use the old files, because the original image hasn’t changed!

And there is no permission error, because kirby is able to generate missing files in the thumbs folder. Kirby seems to have problems checking the existence of files.

Sorry, I think I’m confused. What you just described is exactly what the previously mentioned issue is about. “Even though the images are unchanged, Kirby creates the thumbnails again.”

I’ve recorded a video about it, maybe that helps:

No, the behaviour is completely different. The files are kept in the folder, and are not deleted. There is no manipulation of the page in the panel, so kirby would delete the thumbs. Eg. when I open the page one day, the thumbs are generated/used. Next day, where meanwhile nothing changed, when I open the same page the thumbs are internally again generate, although the thumb-files exists, but not updated on files system - and the files should not be updated.

Edit: This doesn’t concern to all images/thumbs. This effect occurs random. Maybe it depends on PHP internal cache management?!

If it doesn’t happen to all images it’s definitely something weird. You could recreate this issue with a starterkit on your server and send me a zip so I can test if it happens on my server too.

Otherwise I really don’t know how to fix this.

Thank you for your offering, but the site is to complex to create an example.

Is it possible to identify, whether a thumb was fresh created or loaded from thumbs-folder, after executing the crop-, resize-, …-command?

Why do you think some thumbs are freshly created? I thought you had somehow made sure they were?

Because the execution of the commands crop or resize takes some 1000-10000 ms. When the thumbs are loaded from thumbs-folder, the execution lasts only a view ms (3-4).

As I mentioned before, the files in the thumbs-folder are staying unchanged (size, timestamp).

I guess you could just put in a dump() command in the source code or log something to file to see if the isThere() check is true and the thumb newly created. I can’t really believe that the thumb is just overwritten without the time stamp being modified. Even if I set the overwrite option to true, so that the thumb is always recreated, the modified timestamp gets changed.

When I try to call isThere() an error is returned:

Call to undefined method Asset::isThere()

My code looks like that:

$newimage = $page->image()->crop($width, $height, 15);
$isThere = $newimage->isThere();

I don’t think it works like that, the thumb method does not return an object of type Thumb, but of type Media. What I meant was to dump something directly in the thumb constructor in the source code (in kirby/vendor/getkirby/toolkit/lib/thumb.php)

OK, I put an echo into the constructor for type Thumb, and it reports that the thumbs already exists and they were not created again. That’s fine.

But the problem still exists that it lasts sometimes multiple seconds to get the thumb after a resize or crop. Any idea?

Edit: To ensure that the server does not respond too slow for checking the existence of the thumb, I included a stopwatch. The execution time of isThere is 0 ms.

I think I can relate to that issue and posted a similar topic some time ago: Very slow server respond times when creating thumbnails it seems they could be related to each other.

But the problem still exists that it lasts sometimes multiple seconds to get the thumb after a resize or crop. Any idea?

Got the same very very slow first respond times (~10 seconds) on localhost when I have a page with lots of images where thumbnails get generated.

Do you have the same behavior like this?

Yes, it seems to be a similar problem. The difference is, that my website is online and runs with Linux/Apache. For image processing I use imagick.

As I mentioned before, this effect occurs randomly. When the website is not used (for a few hours), this effect occurs. But when a page was loaded, a reload is fast as it should be.

Does this only happen on localhost? If so, in what way does it differ from your remote server? Caching enabled? PHP version? Other?

After a little bit more investigation, the code which causes this behaviour is in kirby/component/thumb.php in the function public function create($file, $params):

$thumb = new Generator($file, $params);

My experience in PHP is two weak to further follow the problem. Has anyone a suggestion?

With analysing the runtime of commands, I was able to identify the position where the starting-point of this problem is. The call-sequence to the starting-point is:

  • ...->image()->crop(...)
  • traits/image.php:
  • public function crop() ->
  • public function thumb(): return $this->kirby->component('thumb')->create($this, $params);
  • component/thumb.php:
  • public function create(): $thumb = new Generator($file, $params);
  • toolkit/lib/thumb.php:
  • public function __construct(): $this->destination = $this->destination(); ->
  • public function destination(): $result = call($this->options['destination'], $this);
  • toolkit/helpers.php:
  • function call(): call_user_func_array($function, $arguments)

And exactly the call of call_user_func_array($function, $arguments) causes this problem.