Hi there,
I am trying out Kirby at the moment and noticed that the URLs for images include a long string with some random numbers, for example “3200699922-1550228428” in this URL:
https://getkirby.com/media/pages/kosmos/31/3200699922-1550228428/berlin-by-food.png
Two questions:
Is there a reason why the string is added to the URL?
And is there a way to remove it by default?
Thanks for your help!
Ben
Hey Ben,
I quote this from Slack:
- You get hashed URLs for any file or thumbnail. Hashed means that the URL changes for every iteration of the file.
- You can set the expiry header for all images and other files far into the future, which is perfect for caching. The cache will automatically be busted by the updated hash in the URL
- Each file is only served by PHP on the very first request if it does not exist yet. Afterwards it’s either in the browser cache or it will be served directly from disk
- Old versions are automatically deleted when new versions are being generated. You don’t get old crap hanging around
- All files are only requested on demand. If a thumb is not needed (i.e. in srcset) it won’t be generated until someone needs it
- Thumbnails are only generated for sizes you’ve added to your templates. Outside visitors cannot simply generate any thumbnail they like.
Because of this, I don’t think you can get rid of the hash.
The second part of the hash is the modification date, btw.
Hi Sonja,
Thanks a lot for the quick response!
To be honest, I still don’t understand why the hash is being generated.
Where is the advantage over a clean image URL without a hash in it?
It seems to be a new thing since Kirby 3, the image URLs on older Kirby sites don’t include a hash. So maybe @bastianallgeier can explain why it was added?
Background: I build image heavy websites and with the hashs the folder structure is getting really messy and complex. It’s hard to quickly find images via FTP when you only see random numbers in a directory 
Ben
The original files are still in the content folder without any hashes, so there isn’t really a need to search them in the media folder? The files in the media folder are auto-generated. That folder shouldn’t be interacted with, actually.
Ah okay. I didn’t realized that the uploaded pictures get duplicated into the media folder and are still in the content folder without the hash.
But I don’t understand why this is done. Maybe you can explain the advantages?
To me this duplicate files are a big disadvantage: They need double the storage and blow up the number of files. I am pretty new to development but have never seen such a behavior in another CMS. Since Kirby has a minimalistic approach, there must be a good reason for this that I don’t see right now?
And I also saw that Kirby automatically generates thumbnails inside the media folder. I’ve found out that they are only generated when needed in the templates. In the starterkit 100x60px thumbnails get generated for images that are only used on pages and I can’t find the location where they are actually needed. Maybe somebody knows? And is there are function to disable thumbnail generation?
As far as I know, the thumbnails that are automatically generated are the ones that are needed in the Panel for page section lists and card layouts of files and pages etc., so if you don’t use the Panel, they shouldn’t be generated. That is the same behaviour as in Kirby 2, where the Panel generated thumbnails as well.
So, why do the images get duplicated. I’m not fully informed of the complete reasoning behind this but let me say this much:
url() method is accessed in the browser, allowing you, to provide images for download purposes that are not publicly accessible (see this thread). e.g. for files behind a paywall.Although maybe the fact that the Panel generates thumbnails automatically somehow contradicts point 3… but from here I need help from the devteam @bastianallgeier or @lukasbestle or @distantnative
Thanks for the explanations!
I understand the reason for duplication when the content folder is not in the public root but in most cases it probably is (as it is also the default setup). The other points are not really reasons for this kind of image handling but rather consequences of it.
So an explanation from the dev team would be awesome. Let’s wait for them 
Regarding the thumbnails: I use the panel from time to time. So this explains why they are being generated. Just a suggestion: An option to turn off thumbnail generation for the panel would be amazing (in my case just the file name without a little preview image would be enough).
Ben, you are right: an option to turn off thumbnail generation would be useful
I believe one main reason for duplicating media files in the media folder was more stable file URLs that aren’t affected by changing content folders’ sorting numbers or similar.
Hey everyone,
there are a bunch of reasons, why we went for this solution based on feedback from many users during v2.
In v2, direct URLs to files always included the sorting number of folders. Whenever you changed the sorting of a page the URL to all its files would break. This is less than ideal for SEO and consistent URLs in general. With the new media API you always get the same URL no matter how the pages are sorted. URLs to files only change when the file itself is being modified.
In v2 the content folder had to be within the document root and access had to be public in order to get file URLs working. This made it impossible to move the content folder above the document root to protect the content, which is now possible.
This also means that it’s now possible to write a plugin, which intercepts calls to files from the content folder to avoid accessing files based on permissions for example.
Such a plugin could also intercept calls in general to optimize images or other media files and resize them to a web-compatible size or run cli tools like imageoptim while you would still keep the original version in your content folder.
The hashes in URLs have been a popular request as well because they enable heavy caching configurations on the server with far-future expiry times. This wasn’t possible in v2 as well.
By proxying the calls to files in general it becomes also possible to write plugins that move the files entirely off the server (to S3 for example) and fetch them from there. Or use a service like Imgix or Cloudinary instead of our own media api. This is a huge step forward in our opinion.
If you are still worried about the additional storage space on your server you can quite easily roll back those changes by replacing our file::url component and return a direct link to the file in the content folder again.
A plugin for this would look like this:
<?php
Kirby::plugin('yourname/old-file-urls', [
'components' => [
'file::url' => function (Kirby $kirby, $file) {
return $kirby->url() . '/content/' . $file->parent()->diruri() . '/' . $file->filename();
},
]
]);
(I haven’t tested it but this should be working)
I hope this will help to understand the decision.
About the panel: turning off thumbnail generation is going to lead to quite some problems if you use bigger files. A list of a couple images, in which every image has something like 2000x2000 pixels for example renders horribly slow and also slows down the browser in general because it has to do a lot of manual resizing of those images. I wouldn’t recommend that at all.
Thanks a lot @bastianallgeier and @distantnative!
I now understand why the images get duplicated into the media folder. It makes sense to create consistent URLs, protect the content folder or move files off the server.
That being said, in my case I would like to return just the original URL inside the content folder. I’ve tried the plugin but it returns an error:
TypeError Argument 1 passed to Kirby\Cms\App::{closure}() must be an instance of App, instance of Kirby\Cms\App given, called in /var/www/virtual/(foldername)/html/kirby/src/Cms/File.php on line 722
(Not sure if this helps at all or if you need more details. To be honest, I don’t really understand the code or the error message.)
Regarding thumbnails for the panel: I understand that huge image files shouldn’t be used there. What I meant with “turning off thumbnails for the panel” was to not show an image at all but just the filename without a preview. This would not cause any problem and even speed up the panel.
Oh, you are right. There was a typo in the code example, I have fixed it above. 
As far as I know, that’s currently not possible. I have created an idea issue here.
Thanks @lukasbestle! The plugin works now and does exactly what I needed
Also thanks for creating an idea issue for disabling images in the panel. Let’s see if it gets implemented.