Media folder – question & issue

I’m not entirely sure if I need to rename the media folder & set roots if I want to have a subpage called “Media” (K3.5). @texnixe posted this in 2019:

but then a year later:

(this has been my own thread, but I didn’t need a page called “Media” for that project after all. Now I do though.)

So I set up my “Media” content folder, blueprints and templates and did the following in index.php:

// index.php
$kirby = new Kirby([
    'roots' => [
        'media' => __DIR__ . '/files',
    ],
    'urls' => [
        'media' => url('files'),
    ],
]);

echo $kirby->render();

This setup however seems to crash my local server (valet on mac os). Not always immediately, mostly the site runs fine for a couple clicks, sometimes even for a couple hours, but then suddenly it’s stuck in an endless loading cycle, after which I have to restart the server. Sometimes this affects other local test sites as well.

Removing the above lines from my index.php and just rendering the site without any options seems to be working fine though. So I’m a bit confused… what’s the correct way to do this?

Tried setting up a “Media” page in a fresh starterkit and no issues so far, neither with a files media folder nor with a media media folder / out of the box. No idea what’s causing the issue with the other install…

I guess you don’t need to set a new name for the media folder in index.php then?

Hmm, nevermind, I just transfered the site to a new location and now it gives me ‘too many redirects’ for plugin stylesheets (kinda was to be expected i guess…)

Sorry to be talking to myself here, but I really don’t know what to do. The obvious solution would be to stop wanting to have a page called “media” but this is an explicit wish of my client.

The issue remains the following:

a) cannot have a subpage named “media” due to conflicts with the core media folder
b) renaming media folder to something else by setting roots and urls in index.php causes server to gateway timeout

I can’t reproduce this issue with a starterkit, so I thought this must be due to the plugins I have installed. So I deleted the cache folder, composer removed any plugins that generate assets and reinstalled them, and made sure there were no hardcoded links to these assets in my frontend code. Upon opening the site again after this, plugin assets were being correctly placed in the files folder and the site was correctly loaded. After a minute I got a gateway timeout again.

I’d appreciate a hint or an idea what else to try to debug, but I guess I’m just gonna have to tell my client that they can’t have a “media” subpage.

As a feature suggestion… would it make sense to rename Kirby’s default core “media” folder to something less likely for somebody to want to name a page? like, idk, kirbymedia or k-media or kfiles

I think having media in the url for served files makes the most sense, rather than something with kirby in the URL.

Don’t know why you get this gateway error, though and particularly, why only with your project but not with the Starterkit, so don’t really know how to test this.

Tried a starterkit with a custom media url on my live test server & example.com/media returned a permission error, even though it’s working on my local setup. So…just got off the phone with the client and our “media” subpage will now be called “watch”. Issue resolved, I guess…

I also had the following route set up:

[
    'pattern' => 'media/(:any)',
    'action'  => function($value) {
        $data = [
            'videoId' => $value,
        ];
        return page('media')->render($data);
    }
]

Thought this could have been it but also with this in place everything’s fine in the starterkit. I’ll be doing some more tests installing some plugins.

Here’s another interesting discovery: Snippets that are located in site/snippets/media and called with i.e <?= snippet('media/mysnippet'); ?> were not being output at all on the production server, although it’s working on localhost.

I renamed site/snippets/media to site/snippets/media-snippets and changed the snippet routes accordingly, now it’s working.

Sounds like some issue with the hosting provider.