I want to stop Kirby copying a particular folder to the media folder. I have done it like below in the past which worked fine but for some reason no longer does using Kirby 3.6.2:
<?php
Kirby::plugin('hashandsalt/kirby3-skip', [
'components' => [
'file::url' => function (Kirby $kirby, $file) {
$page = $file->parent();
if (preg_match('/tiles\/|tiles$/', $page->uri()) > 0) {
$path = $kirby->url() . '/content/' . $page->diruri() . '/' . $file->filename();
return $path;
} else {
return $file->mediaurl();
}
}
]
]);
basically i have thousands of images in folders like content/pagename/tiles
I want to serve images below that folder directly from the content folder rather then Kirby copying them to the media folder. If i let do that, then site will end up being 40gb!
How can i fix it?
Is the plugin properly registered? Is the condition correct?
I believe so, yes. the code above is the entire plugin. It looks for the word “tiles” in the full url to the file… atleast it did 
The folder structure is like this…
Hm, it should actually work then. Is your plugins index.php correctly placed in a folder inside the /site/plugins folder, e.g. /site/plugins/file-component/index.php?
Maybe test in a fresh Starterkit and without the condition first to see if this works as expected. Make sure you don’t have any caching enabled.
It doesnt work in the starter kit either, i tried this:
<?php
Kirby::plugin('hashandsalt/kirby3-skip', [
'components' => [
'file::url' => function (Kirby $kirby, $file) {
$page = $file->parent();
$path = $kirby->url() . '/content/' . $page->diruri() . '/' . $file->filename();
return $path;
}
],
]);
Just noticed something. It does work in the starter kit, but only if you are looking at the page the file belongs too. If i look at the home page, they come from the media folder. If i look at, for example, /photography/trees the images come from the content folder for that page.
Anyway to make it work site wide again?
I dont need to manipulate these files at all, they just need to be accessable. The site will double in size if they get copied to the media folder, which is just a waste of disk space and unneccasry.
If you use thumbs, the file::url component will not apply to those
Im not using thumbs at all. The images get read by an XML / Javascript viewer. They littlerally just need to be in the file system in the content folder for the page, and for kirby to completly ignore them. When i access the page in the browser, it all works except for Kirby copying them to media folder.
Im not actually calling those images at all in the templates etc.
It seems just because the page is there and the images are accessed, Kirby goes ahead and copies them over regardless. Is there another way to have it ignore the “tiles” folder and anything below it?
You could customize your .htaccess file. Something like:
# block all files in the content folder from being accessed directly,
# except for paths containing '/tiles/'
RewriteCond %{REQUEST_FILENAME} !(/tiles/)
RewriteRule ^content/(.*) index.php [L]
here: starterkit/.htaccess at main · getkirby/starterkit · GitHub
Hmm… i think id rather do it a kirby way if possible. I use Nginx locally and apache on the live server, I dont really want to mess around with different server configs.
I guess i could store them in the Assets folder instead but the end goal is to be able to upload them to the the panel as a zip file. Not sure i can move that to the assets folder after upload.
I have an upload hook that unpackes the tiles from a zip after upload.
Unpacking to another folder should be doable rather easy. But if you want “different sets” of tiles you’d have to keep stuff “in sync” between the content folder and the assets folder, like if the editor deletes a page containing tiles, he would probably expect those to be deleted too. So you also would need other hooks, at least for deletion.
edit: I wonder if it wouldn’t be better to unpack the zip into the media folder instead.
There is about 40 of these so yes, i would need hooks that clean up after if a page is deleted. But i dont think the client will actually delete any.
