Add baseUrl to support sub-directory setups

[lukasgeiter]

I know this has been discussed here and here but I think I've found a quite nice solution to make it possible to run Lumen in a sub directory. Especially for something that provides a micro-service I think it would be quite nice to have this flexibility.

Instead trying to figure out the base URL or rely on the symfony request class for this I thought why not just make it configurable. So I've added a method that can be easily used from bootstrap/app.php to set a base URL if necessary. Like this:

$app->baseUrl('api');

[taylorotwell]

I'm not a big fan of this.

[lukasgeiter]

Are you not a big fan of this implementation or rather the general idea of being able to run Lumen in a sub-directory?

[GrahamCampbell]

Lumen does not support being run in a subdirectory, this has already been said so many times.

[lukasgeiter]

Then this should be mentioned prominently in the docs, because otherwise people will keep wondering why their installation of Lumen isn't working and questions like this one will keep popping up...
If you don't mind I'd like to know what the reason for this decision is.

[electrickite]

I agree with @lukasgeiter that the inability to host in a subdirectory should either be fixed or prominently documented. This is a fairly large departure from other frameworks and may prevent potential users from deploying their applications.

[alexrussell]

Is the not-supported-in-a-subdir thing actually documented anywhere? I understand the reasoning for the choice (though seriously disagree) but it really needs to be front page of installation instructions flashing 72pt text that it's not supported out of the box (and, ideally, the suggested workaround).

Unless I'm mistaken, I can't see anywhere on the installation or routing pages of the docs where this is mentioned.

[lukasgeiter]

I made a PR to add a note to the documentation, which got rejected: laravel/lumen-docs#22

@taylorotwell I think it's time you make a decision here. Either fix it (with this PR or some other way) or add a note to the docs so it's clear that sub directories are not supported.

[alexrussell]

Agreed. You can't not support the feature people expect and also not tell people about it. (Also being somewhat rude in closing all the PRs that add support in isn't great community outreach - maybe it's old news to you and you're sick of hearing people complain about it, but to us it's new and just plain wrong. Also if that many people complain, it usually means you're doing something wrong.)

Lumen literally looked broken to me when I tried it out for the first time earlier. In fact it wasted at least good hour of my time trying to work out if maybe the Lumen installer had got stuck on a broken build and so I did a composer create-project, when that failed too I re-scoured the installation docs and then had a look through the Lumen project commits to see what was going on. Nothing gave anything away (as, indeed, it wasn't an accidentally-introduced bug). Searching on SO was a last resort and when I saw the answer I was speechless!

I also considered making a PR on the Lumen docs, I'm glad I didn't bother now, knowing you tried and failed. (I couldn't work out where was best to put it and how best to word it without being somewhat critical of the framework anyway.)

[alexrussell]

Something else I didn't see documented is that the installation instructions say about using the .env file, but, by default, the reading of the file is disabled (unless I'm mistaken) and the docs don't mention "to get this to actually work, you need to uncomment the line..." but anyway this is going offtopic so I'll stop.

[CSCG]

I'm finding this difficult to understand, given the simplicity of Laravel and the rest of Lumen. Four hours of constant googling on partial answers to this issue led me here - documentation NEEDS to be fixed or this needs to be sorted another way. Laravel? Sure, doc root only. Lumen? ehhhhhh....

EDIT: the reason this is such a huge wall of entry is the fact that many of us, myself included, have laravel IN the doc root or a different custom solution. I've been using a cloud VPS with application.net/dev/ as my root for new things, such as coding an implementation in Lumen. Many developers use subdirs for dev versus docroot on localhost, yet that's not a configuration supported via Lumen as of yet.

[alexrussell]

My use-case is that I just run MAMP on my mac and shove a new Laravel/Lumen project in htdocs and refer to them as http://localhost/project-name/public/.

Yes I know, using vagrant will solve all my problems. Blah.

[crynobone]

And technically allowing anyone to access http://domain/project-name/.env.

[alexrussell]

Yes well, luckily for me, no-one's going to my localhost!

[CSCG]

@crynobone So am I correct in thinking the major point of contention we've got on this issue is scope of file? As in, the pushback is due to not wanting to expose potential .env files to public?

If that's the ONLY worry in terms of this -- a fork providing subdirectory support with a .hta protected .env could work for some of us. I definitely do understand the implications of a public facing .env, but I wanted to verify if that's all.

[electrickite]

@crynobone There are many ways of securely hosting an application at a nested path. Both symlinks and reverse proxy setups can be used to expose only the public directory, keeping sensitive files safe. I'll also point out that .env files should not be used in production anyway, those settings should be read from environment variables set by the web server.

[electrickite]

A simple use case (probably the one the OP had in mind) for hosting Lumen at a nested path is to provide a back end API for a front end framework. In my world, I would simply symlink (for example) /www/public_html/api to /www/lumen_api_project/public Now Lumen is available at /api and the front end of my site is available at other paths.

Problem is that Lumen is unaware it is operating at a non-root path and so any generated URLs in the API for other API endpoints will be incorrect.

I recognize that this might not be the primary way the developers intend lumen to be deployed, but this design choice should still be documented. (If a note has made its way into the docs since this issue was opened, I apologize)

[CSCG]

@electrickite No, I agree with you entirely -- I'm still not sold that this should be fixed by 'documentation notation of the predicament', if you will - I still maintain that nested paths are pretty important, especially since Lumen is so attractive for micro-APIs that many devs probably WILL stick into a sub path.

If Lumen is the micro and Laravel is the macro, why would Lumen have an arbitrary requirement to live in the doc root? In that case, Lumen isn't a micro at all, rather it's attempting to be the main framework used in the application held in that document root.

@GrahamCampbell @taylorotwell beyond .env exposure and anticipated work in terms of code changes, what are the major qualms with allowing Lumen to live in a sub folder? I'm going to be testing a Lumen implementation with the changes from this PR this weekend myself, I can't say I've investigated fully.

[alexrussell]

@CSCG I bet one major qualm is that it makes it slower. Unfortunately, being the fastest microframework in the known universe is one of the big things that Lumen likes to advertise, usability be damned!

[crynobone]

Luckily nobody is doing this https://www.google.com/search?q=intext%3Adb_password+ext%3Aenv&rlz=1Y3YCBW_enMY580MY580&oq=intext%3Adb_password+ext%3Aenv&aqs=chrome..69i57j69i58.1874j0j4&sourceid=chrome-mobile&ie=UTF-8

And even if Laravel allow subdirectory, nobody is crazy enough to blame Laravel for allowing such security risk.

[Andre741]

You definitely need to document it, I wasted half an hour now! Thanks for nothing