Grav-plugin-admin: Why can the admin plugin not be used with the built in server?

[piersroberts]

When running the admin plugin using PHP's built in server, the admin plugin throws an exception with the message,

The Admin Plugin cannot run on the PHP built-in webserver. It needs Apache, Nginx or another full-featured web server.
When the check is commented out in the plugin, the plugin continues to work as normal. What are the known issues with using the built in server? Obviously it's not advisable in a prod env, but this seems fine for dev use.

My php -v if that's of any interest;
PHP 5.6.17 (cli) (built: Jan 8 2016 10:27:48) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies

[flaviocopes]

There are some issues that are not spotted at a first glance, like handling media files and some other hidden issues that were more trouble for the user as things seemed broken.

Since this is due to a limitation of that web server, we decided to disallow using it. Also, some other plugins are known to have issues with that, so it's advisable to not use it beside simple testing.

[laszlokorte]

Is there some more in depth explanation of what's the problem with the cli-server?

[flaviocopes]

The issue is it does not support having URL parameters such as site.com/param1:something which are used in Admin, I found this issue reference https://github.com/getgrav/grav-plugin-admin/issues/167

[ralphschindler]

Hi, I realize this is a closed issue, but my initial 5 minute tour of getgrav was going ok until I tried to use this admin module (testing via the built-in webserver). It not working in that environment left has given me pause to give it a further look. Normally I would not post back to a project, but it did look promising in my initial 5 minutes up until the admin.

Consider this my vote that I hope y'all can prioritize making it work on the built-in webserver. :)

[rhukster]

The problem is that it's not something we can fix without fundamentally changing Grav to work without param style urls. The built in webserver has no support for this param format and it's a limitation of the webserver itself.

[laszlokorte]

Are you sure it's fundamental problem of the php web server?

If I create a index.php with the following content:

<?php
echo $_SERVER['REQUEST_URI'];

And then start up a server via php -S localhost:9000 and then visit http://localhost:9000/foo:bar/hello:world

I get /foo:bar/hello:world as output which is what I would expect.

(PHP 5.5.36 (cli) (built: May 29 2016 01:15:42))

[rhukster]

Hmm which version of PHP? I need to test again I think.

[ralphschindler]

IIRC, the problem is that if a path has a dot in it, the webserver assumes it is a static file. This can be circumvented by supplying a php script to act as a router, which can then decide which static files to route to, and which ones to serve dynamically. I can look into seeing how much work providing a router would be.

See the last 3 examples: http://php.net/manual/en/features.commandline.webserver.php

[rhukster]

Ah yes (the reason is coming back to me now), it's this bug: https://bugs.php.net/bug.php?id=61286

There is even a reference to a getgrav issue where this came up originally. It's related to how the built-in webserver automatically sends the page statically if there is a dot in the URL. There's nothing we can do to fix this as it's at too low a level for us to even intercept.

The PHP team sees no reason to fix this as the built-in webserver is meant for light local development only.

[rhukster]

btw try this:

http://localhost:8888/admin/pages/home.json/task:listmedia/nonce:jlk32393jklklj3

It returns a static 404 not found page, PHP is not even processed.

[laszlokorte]

Still works if the server is started via
php -S localhost:9000 index.php
instead of just
php -S localhost:9000

[rhukster]

Ok, I i have the admin working by doing this:

php -S localhost:9000 index.php

in index.php .. after namespace Grav; add:

// Special router logic for built-in PHP webserver
if (php_sapi_name() == 'cli-server') {
    if (preg_match('/\.(?:png|jpe?g|gif|js|css|svg|otf|woff|woff2|ttf|eot)(\?|$|\/)/', $_SERVER["REQUEST_URI"])) {
        return false;    // serve the requested resource as-is.
    }
}

Then comment out this chunk in the user/plugins/admin/admin.php file:

//            if (php_sapi_name() == 'cli-server') {
//                throw new \RuntimeException('The Admin Plugin cannot run on the PHP built-in webserver. It needs Apache, Nginx or another full-featured web server.',
//                    500);
//            }

CAVEAT:

Now this _appears_ to work for me.. the JSON that always tripped it up is now able to process. The concern I have is this requirement to force certain URLs with a hardcoded list of file types to be statically served.

This definitely will lead to issues with media that is served up via Grav routes. This is a powerful feature in Grav and it will just not work with this 'work-around'. Traditional webservers will serve files statically if the route is found in the webroot, else it falls back to the PHP. This functionality is critical for parts of how Grav is able to serve up media files via Grav routes (not just physical paths).

[laszlokorte]

couldn't the preg_match check be replaced with a file_exist check? Then it should work analog to the .htaccess behavior.

[rhukster]

Try it?

If you can get it working reliably, and submit a PR, i'll be happy to put support for it back. I think it's a very small group of people that find this PHP webserver support important, and I have other things I need to focus on right now.

While your at it, having that list of file types built from the system.yaml and media.yaml will make it much more reliable too.

[ralphschindler]

The preg_match seems to work for me. file_exists is not a perfect drop in replacement because $_SERVER['REQUEST_URI'] will include query parameters, which as you might suspect will throw off the file_exists check for some static asset requests (they would need to be stripped before the file_exists check. For example:

/user/plugins/admin/themes/grav/fonts/fontawesome-webfont.woff2?v=4.5.0
/user/plugins/markdown-notices/assets/notices.css?555c60a537

[laszlokorte]

@ralphschindler one could cut the path after the first ?. I will try that in the next days.