I’m using site/blueprints/files/default.yml to define my create options for new uploaded files in the panel:
title: Default File
create:
width: 2600
height: 2600
fields:
alt:
label: Alt Text
type: text
required: true
As you can see i did not specify any format conversion because I want the original file format to stay the same. However, JPGs and PNGs are automatically converted to WebP.
Expected Behavior:
• Images should only be resized but not converted to a different format.
Question:
Is there a way to prevent automatic WebP conversion? (because i generate them in the frontend via thumb() function)
I cannot reproduce this. Are you sure there isn’t another blueprint that gets applied instead? Or a config option or plugin? And they get directly converted on upload for you?
Ok that makes sense as the Panel is just using the same method as you for the Frontend to resize them on upload. But I’ll discuss it with the team if this indeed is what we want or could be handled without the config defaults.
Thanks, Nico! I appreciate your input, but this approach feels a bit confusing. Maybe there will be a better way to handle cases like this in the future. For now, I was using kirby-autoresize from medienbaecker (@thguenther), but since this functionality is now built into Kirby, the plugin is outdated.
My use case:
Many of my clients aren’t very tech-savvy. They upload photos and images that are often over 10MB each, and when they upload several at once, the Panel gets cluttered. That’s why I want to resize images automatically during the upload process—just to keep things manageable.
Temporary solution
So for now, my idea is skip the standard resizing settings in the config and for the frontend handle optimization directly case by case in each template using the thumb options with specific sizes and webp where needed.
We’ve already talked in the team and agree that the default format config shouldn’t also be applied for the on-upload resizing. We’ll look into a way to support/fix this.
That said, I still would like to understand your specific case a little better: I would think if you define webp in the config as default format for your thumbs, you’ll render all your thumbs in the frontend as webp, right? Why is it a big issue that the format conversion already happens during the upload process and not only when rendering the thumbnails in the frontend?
@slgdev I run a download portal for my customers, where I often provide large quantities of high-resolution images (6000 × 4000px) for download – sometimes up to 50-150 files at once. However, uploading this amount of data can be very time-consuming, and it has been shown that uploading so many images at once is problematic. I definitely see room for optimization here.
Another problem was the thumbnail creation in the frontend: the direct generation of thumbnails from the high-resolution images almost led to timeouts and was generally very sluggish.
My solution now looks like this:
When uploading an image, I use the hook file.create:afterto automatically create an additional version with 1200px and the suffix -preview. This smaller version then serves as the basis for the thumbnails in the frontend, which significantly improves loading times.
In addition, I have implemented a file.delete:before hook to ensure that the -preview file is automatically removed as soon as the original image is deleted.
I am very satisfied with this solution because it significantly improves frontend performance.
Okay good idea too. But when im uploading and converting all images to webp in the panel - is it also possible to adjust the quality? Like in the thumb function?
Blueprint
create:
width: 2600
height: 2600
format: webp
Frontend
Then i just resize it to my needs
$image->toFile()->resize(555);
Frontend Alternative
If this is maybe not the best way, i go back to the thumb function and use
Hey GB, that sounds like a great approach for handling a large number of files at once. It’s not that many for me, but I might give your solution later a try. P.s. Gruß rüber nach Köln aus Essen
The controller contains over 130 lines of code because I also create resized JPEG versions from PDF and PSD files and optionally integrate a watermark. Unfortunately, it would take too much time to write a compact, runnable version especially for you. However, I wanted to show you a solution that has worked well for me in practice.