[5.0] Unable to change default application paths #7108

Closed
TerrePorter opened this Issue Jan 24, 2015 · 15 comments

Comments

Projects
None yet
5 participants
@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

This comment has been minimized.

Show comment
Hide comment
@crynobone

crynobone Jan 24, 2015

Contributor

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

Contributor

crynobone commented Jan 24, 2015

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

@TerrePorter

This comment has been minimized.

Show comment
Hide comment
@TerrePorter

TerrePorter Jan 24, 2015

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Jan 24, 2015

Member

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

Member

GrahamCampbell commented Jan 24, 2015

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

@euantorano

This comment has been minimized.

Show comment
Hide comment
@euantorano

euantorano Jan 24, 2015

Contributor

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...

Contributor

euantorano commented Jan 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Jan 24, 2015

Member

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

Member

GrahamCampbell commented Jan 24, 2015

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

@euantorano

This comment has been minimized.

Show comment
Hide comment
@euantorano

euantorano Jan 24, 2015

Contributor

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.

Contributor

euantorano commented Jan 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 25, 2015

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?

ghost commented Jan 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@euantorano

This comment has been minimized.

Show comment
Hide comment
@euantorano

euantorano Jan 25, 2015

Contributor

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.

Contributor

euantorano commented Jan 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 25, 2015

@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.

ghost commented Jan 25, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Jan 25, 2015

Member

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 👎 for that. That would be a total misuse of that file.

Member

GrahamCampbell commented Jan 25, 2015

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 👎 for that. That would be a total misuse of that file.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 25, 2015

@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.

ghost commented Jan 25, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Jan 25, 2015

Member

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.

Member

GrahamCampbell commented Jan 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 25, 2015

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.

ghost commented Jan 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Jan 25, 2015

Member

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

Member

GrahamCampbell commented Jan 25, 2015

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

@laravel laravel locked and limited conversation to collaborators Jan 25, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.