404 for asset routes with PHP dev server (v2.2 beta)

[mzur]

When I'm running the Panel v2.2 locally on the PHP dev server (php -S) I get a 404 for some asset routes:

[404]: /panel/assets/js/form.js?v=2.2.0 - No such file or directory
[404]: /panel/assets/fonts/fontawesome-webfont.woff2?v=4.4.0 - No such file or directory

These are not the actual files but routes like these that should return the files. I assume the dev server doesn't handle these routes correctly and looks for the actual files. Can anybody reproduce this issue?

[distantnative]

These are not the actual files but routes like these that should return the files. I assume the dev server doesn't handle these routes correctly and looks for the actual files. Can anybody reproduce this issue?

I would assume that your .htaccess then is not properly redirecting these "fake" file requests to the panel/index.php which would need to route them. Are you using the most recent version of the .htaccess file: https://github.com/getkirby/starterkit/blob/develop/.htaccess ?

[medienbaecker]

I don't think the .htaccess is the problem here. I get the same 404 errors, not only for the panel assets but also when I click on an image in the panel. Also using the local PHP server on OS X El Capitan.

[mzur]

I do think the .htaccess is the problem here because the PHP dev server ignores it. As far as I know, it tries either to serve the requested file or an index.{php,html}, otherwise it will return a 404. The question is, why did it work before and why doesn't it now? Maybe it looks for a file as soon as there is a file extension like .jpg or .js involved in the URL, but I'm not sure.

The dev server is an extremely useful tool for developing and works flawlessly even with big frameworks like Laravel. It should definitely be supported by Kirby, too, if you ask me.

[distantnative]

And you are using the newest version of the htaccess? It changed quite a bit recently.

[medienbaecker]

I attached a screenshot with the file open. I suppose mzur also uses the newest version of the .htaccess file. (That's what I meant by "the .htaccess is not the problem").

Maybe some functionality is deactivated on OS X by default in the httpd.conf? And this is required for the routes or something?

[lukasbestle]

Maybe some functionality is deactivated on OS X by default in the httpd.conf?

The httpd.conf file is an Apache configuration file. Apache is not involved at all with the PHP built-in server, so it can't be the problem.

As @mzur wrote, the PHP server completely ignores .htaccess files, as they are also Apache configuration files and won't be parsed by PHP. I guess Kirby will need a router script as described in the PHP manual.

[mzur]

I guess Kirby will need a router script

Yep. Apparently the dev server handles all URIs with a dot as a static file request. While one could argue why it's necessary to use routes for panel assets like form.js or fontawesome-webfont.woff2, it's definitely a problem that routes like /panel/pages/home/file/xy.jpg/edit don't work.

[lukasbestle]

Hm, that's very strange. This "bug"/"intended behavior" basically means that users won't be able to use the PHP server for the Panel, only for the core.

[bastianallgeier]

That's fucked up!! I will try to fix it :(

[bastianallgeier]

Ok, I think I fixed all related issues. I'm not 100% happy with it, but dots in filenames are now replaced with a dash. I.e.:

panel/pages/projects/project-a/file/foerrest-jpg/edit

I think this is the best compromise between readability and functionality. I also moved the fake assets (plugins.css and plugins.js) to different routes to fix this as well.

Could you please give it a last try and see if you run into any additional issues?

[bastianallgeier]

Ah, I also fixed the woff2 error by actually adding woff2 files facepalm :)

[lukasbestle]

But what happens with files that contain more than one dot? Or with files that contain dashes?

[bastianallgeier]

You are too smart :) The additional dashes are no problem, but the dots could be. I will check that.

[mzur]

The assets and the edit page are now loading correctly 👍

[bastianallgeier]

In the meantime I found a cool way to get around the dots issue in filenames.

There's a unicode character called "one dot leader":

․

It looks like a dot, but is no dot. Whenever PHP detects the built-in cli server it will now replace dots in filenames with that unicode character. The cool part about it is that it's unique enough to be able to encode and decode it again that way. For the user the result is invisible and additionally rawurlencode will pick it up and encode it correctly for the URL which is another plus.

I made some tests and it works great. It's also just a tiny unobtrusive "hack" that affects the cli server. I like it :) I hope you like it too.

[bastianallgeier]

BTW that one dot leader thingy does actually never land on the filesystem in filenames. It only appears in URLs.

[lukasbestle]

So it will encode to %E2%80%A4? I think that can be a bit confusing for users. But anyway, cool idea!

[bastianallgeier]

Technically yes, but at least Firefox and Chrome are smart enough to display the dot in the URL bar.

[lukasbestle]

Oh, that's awesome!