On Wed, 08 Feb 2017 at 02:33:48, Mark Weiman wrote:
On Tue, 2017-02-07 at 21:43 +0100, Lukas Fleischer wrote:
I am not 100% convinced that this is a good idea. If somebody wants to setup a "proper" web server running aurweb, this workaround makes it harder to figure out what went wrong if PATH_INFO is unset due to some misconfiguration. On the other hand, being able to run a quick test using `php -S` is quite nice. Would you might adding a notice to the commit message that this is specifically for `php -S`?
If PATH_INFO is unset, then it will always return "/", so it would be fairly obvious that something's wrong if you are only getting the root page when you visit other pages.
True, it would be obvious that something is wrong. However, it would be harder to pinpoint the actual issue. Right now, if the server does not set PATH_INFO, the user gets a warning explicitly stating that. After your patch, there won't be such a notice and the user does not get any hint. Maybe it's not too bad, though. And I cannot think of a way to make the notice disappear when using `php -S` while keeping it for "real" web servers. Or maybe there is an option to php which tells it to redirect everything to index.php unconditionally and always specify PATH_INFO?
I also think that a note on how to test aurweb patches with `php -S` should be added to the documentation. Maybe in INSTALL, before the "real" setup instructions? Something like:
For testing aurweb patches before submission, you can use [...]
Note that you can only do limited testing using the PHP built-in web server. In particular, the SSH/Git interface will be unusable. For a detailed description on how to setup a full aurweb server, read the instructions below.
Opinions?
That second paragraph is not entirely true, you can still set up an SSH/Git interface separate from the web interface. There's nothing too special about the web interface that the SSH/Git interface depends on.
True, let's replace "SSH/Git interface" with "cgit interface" then.
I think that while we are talking about testing installations, perhaps some information on how to populate a database using sqlite instead of MySQL should be added.
Good idea, maybe some TESTING document in addition to INSTALL (and a reference to TESTING before the actual instructions in INSTALL)? Regards, Lukas