[5.0] Unable to change default application paths

[TerrePorter]

I just wanted to make sure changing this was still on the to-do list.

The default app paths as they are hard coded as part of https://github.com/laravel/framework/blob/master/src/Illuminate/Foundation/Application.php#L187

My reasons are I personally don't want my public directory in my project directory so I move it. However, currently I have no way to update the public path in the app as it is hard coded to $this->basePath.'/public';

I'm happy to see if I can come up with a possible change, but if it is already in the works then it would just be me wasting my time.

Thanks for reading.

[crynobone]

As mention in some other discussion you should override Illuminate\Foundation\Application and update bootstrap/app.php

[TerrePorter]

@crynobone I understand anything can technically be extended but in this case to me it feels like a lame solution. I still think the core should allow that ability by default. Either way, thanks for the reply.

[GrahamCampbell]

I think the idea is most use cases don't require custom paths.

[euantorano]

So you remove a useful feature because most people don't use it? Sounds like a step back. We would certainly be changing the paths, and extending Illuminate\Foundation\Application seems a bit like a sledgehammer approach to me...

[GrahamCampbell]

We're basically saying we don't support it. If you really want it, you can hack a solution yourself.

[euantorano]

That's a pity. It was a useful feature in 4.x. We're using Laravel for a program to be distributed to many users that could run on a variety of hosts, some of which don't allow the changing of the public path.

[ghost]

I too have an issue with this as will quite a few other people imho. I for one have no way of knowing how apps are going to be deployed and I am aware that a number of my customers run on shared hosting with public being public_html for example. This would cause no end of support calls for basic installs. Couldn't the app paths be in the .env file as an option ie if they are there use them else use the defaults?

[mattstauffer]

Does this solve the issue @Phil-F, @euantorano, @TerrePorter?

http://mattstauffer.co/blog/extending-laravels-application

[euantorano]

Yes, that works. It just feels a little bit more hacks than it used to be.

On 25 Jan 2015, at 20:18, Matt Stauffer notifications@github.com wrote:

Does this solve the issue @Phil-F, @euantorano, @TerrePorter?

http://mattstauffer.co/blog/extending-laravels-application

— Reply to this email directly or view it on GitHub.

[ghost]

@mattstauffer Firstly thank you for taking the time to understand the issue and propose a solution. That is what I have basically already done but as @euantorano mentioned it seems hacky and not straight forward when using an install script to automate the config for a cms, ecommerce or blog application that is sold online for example.

---

My Proposal

I believe this could be solved in a cleaner far simpler way by allowing the paths to be configurable in the .env file. If they are set in the .env file use them else just use the defaults

---

Again thank you for the time you have spent on this @mattstauffer.

[GrahamCampbell]

I believe this could be solved in a cleaner far simpler way by allowing the paths to be configurable in the .env file. If they are set in the .env file use them else just use the defaults

Massive :-1: for that. That would be a total misuse of that file.

[ghost]

@GrahamCampbell Why?

Is it not supposed to be used to set any environment variables and configuration required for the application?

I can't believe it's just there for setting the environment and database config settings.

[GrahamCampbell]

Is it not supposed to be used to set any environment variables and configuration required for the application?

It's only purpose is to change config that affects different devs working on your project. You should not be setting config in there that's going to be the same for your whole team.

[ghost]

But you tell the dev/user what is missing in order to use your application don't you?

This keeps your dev across teams in a standard form so why would the path to the public folder not be a requirement for your application to run if that is what you have either chosen to change it to or have been forced to change it to.

It quite simply might be a requirement for the app so if you don't set it there to be called via $_ENV where do you set it?

The public folder is but one example.

[GrahamCampbell]

I have no idea what you mean, and as stated already, we don't encourage, or support changing the structure in this way.