Is the gd driver actually enabled if you check with phpinfo(). If so, what is set as driver in your config file (maybe you have accidentally enabled the im driver?
If you are familiar with xDebug, I’d set a breakpoint in the thumbs component (in /kirby/config/components) and take it from there to debug.
I was getting just the jobs files yesterday with 3.6.2. I ran composer upgrade this morning to bump it up 3.6.4 and suddenly i was getting images in the media folder. Thats all i know
GD Support is enabled and the version is bundled (2.1.0 compatible) (from phpinfo).
The config.php doesn’t have settings concerning the graphics driver, so it should be gd as default.
I have a small de javue and again think of documentation or dependencies that are not met (without error message). I had this just recently in this git ticket.
Unfortunately, I have no experience with xDebug. Now I am thinking how I could get further here. Freshly installed Debian 11, PHP 7.4, no indication of missing packages, no error messages …
I didn’t use the starterkit yet, but plain kirby (composer -nq --no-cache create-project getkirby/cms:3.6.4 kirby) to install, and then deploy the project files like site folder and assets.
I tried with a starterkit and the images are displayed.
I further tracked it down to that the $img->resize() command is not working.
If called $img->url() it works, but with $img->resize(720)->url() it doesn’t work.
That doesn’t create a thumb but just copies the file into the media folder.
So are the thumbs in a Starterkit actually created or not (is not clear to me from what you are writing above)? That is, when you open the notes page, this should result in images with 320px width created in the media folder that are actually that size (i.e. don’t just check the name of the files but the actual size).
If the location of the media folder changes, you also have to set the urls, I think
But that shouldn’t have an influence on the thumb creation, but only why they don’t appear in the frontend (unless this is due to your particular setup, guess that is not easily recreatable, or do you have a Dockerfile to share that doesn’t need any additional setup?)
Finally i tracked down the problem and it was something completely different:
In the content folder there were two image files:
tim.jpg
tim-720x.jpg
Now when kirby tries to $img->resize(720) the first image, the .jobs file is created but no image is saved to the media folder. I don’t know why that happens. It doesn’t make sense.
But: As soon as you delete the second file tim-720x.jpg from the content folder, the resized image will be created! That is a bit mysterious, isn’t it?
I assume someone uploaded the image a second time, saved from the browser in the already resized format. As soon as another picture is in the content folder with the same name as the one going to be created in the media folder, kirby silently refuses to generate the media files. But why?
The handling of the files and names should be reconsidered. This case is not fundamentally excluded. This can happen again and again. Above all, a user could do this - as in this case - and from then on the creation of media files from other files no longer works.
I would consider this as a bug, or an error in the design. What do you think?
If you have a job file tim-720x.jpg.json that belongs to a file tim.jpg, for a file called tim-720x.jpg the job file will be called tim-720x-720x.jpg.json.
And this second file should be treated just like the original, i.e. a thumb should be created with a filename tim-720x-720x.jpg (and it worked in my test).
It’s probably not a great idea to resize an image that already has the desired size because it might actually result in a larger file than the “original”.
That is not the case. There was no second job file. Kirby stopped processing at the first file.
You could possible reproduce if you just copy two image files to a content folder, with the name pattern like
file.jpg
file-720x.jpg
and then use file.jpg as the selected image in a file field.
Then, in the template try to display the first file with something like $img->resize(720)->url(). The result is that no media file will be generated any more for this file.
As soon as you delete the second file file-720x.jpg the media file for the first file is generated again.