Closed ChristopheB closed 10 years ago
This would need to have an implementation for packages too.
:+1:
I think that an implementation for packages is out of this scope.
Not really. This sort of change would create an inconsistency with package design.
Packages follow the recommended directory structure proposed by Laravel, so they can be shared and parsed correctly. This is fine to me, and doesn't directly relate to the app structure folder (except for the fact that, yes, it wouldn't be the same structure).
What would you suggest ?
Honestly I don't think we need this level of configuration. Most people do not care and just want a convention.
As you want, though I wished we could have discussed it a bit more :)
I hear your concern about making official the possibility of changing the directory structure. But I still think that removing the hardcoding paths from the framework and keeping them all in one place is a good thing.
It can be done with this proposal, simply by letting the bootstrap/paths.php
as it is today, without the new keys. The install path fallback getDefaultInstallPaths()
would then populate the keys.
For the record, here are the proposed changes (I updated my first post) :
Not directly related, but here is an interesting discussion about the directory structure of Symfony Standard : https://github.com/symfony/symfony-standard/issues/584
really need to be able to change the config directory at least.
:+1:
+1000000000000000000 for this, i think I've mentioned the config folder before.
i know "most" people wont even care about this, but there will always those that do. And the solution provided means people who don't care wont even have to know about it.
its a few lines of code to please quite a few people.
i get convention over configuration, but to me flat refusing this is more of a law than convention.
The reason i love laravel is because i can swap out the view factory, or i can extend different classes and bind them back into the brilliant container.
As it stands i can fundamentally change the way the core application works, or what providers are loaded, or what view engine i want to use, but can't even change a directory name for my config files as it will break everything?????????
This is fixed in 4.3.
On August 21, 2014 at 4:31:10 PM, Lee Mason (notifications@github.com) wrote:
+1000000000000000000 for this, i think I've mentioned the config folder before.
i know "most" people wont even care about this, but there will always those that do. And the solution provided means people who don't care wont even have to know about it.
its a few lines of code to please quite a few people.
i get convention over configuration, but to me flat refusing this is more of a law than convention.
The reason i love laravel is because i can swap out the view factory, or i can extend different classes and bind them back into the brilliant container.
As it stands i can fundamentally change the way the core application works, or what providers are loaded, or what view engine i want to use, but can't even change a directory name for my config files as it will break everything?????????
— Reply to this email directly or view it on GitHub.
perfect, once again taylor you come through for us.
just had a quick look at dev and love the new structure. funnily enough its very similar to how i was trying to get app before we could.
i assume all these changes will be detailed when 4.3 is out (november right?)
Yes.
I will be discussing it all at Laracon EU next week.
looks like ill be busy reading up on it then. thanks again taylor for all your work.
Glad to hear that ! :+1:
it's very important for us also, is this possible with Laravel 5.1
I'm also interested if this can be achieved in L5 too.
yes, is this already possible?
yes our R&D team has change the directories structure and it work very well but each time you need to upgrade the framwork you need to make all this changes manually,
for us we are using LTS version so we don't need to upgrade the framwork and we have build a lot of application over this new structre
So, there is no way to set the paths when instantiating
$app = new Illuminate\Foundation\Application(
??
It would be very nice if we can set the path in the bootstrap script.
On Fri, Jan 6, 2017 at 3:46 PM, Foxmedo notifications@github.com wrote:
yes our R&D team has change the directories structure and it work very well but each time you need to upgrade the framwork you need to make all this changes manually,
for us we are using LTS version so we don't need to upgrade the framwork and we have build a lot of application over this new structre
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/laravel/framework/issues/3984#issuecomment-270917433, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPP1V_udlyHLgMXJ-EM2ABjwoiTXkl_ks5rPlPegaJpZM4BsSHz .
--
[image: --] Roy de Kleijn [image: http://]about.me/roydekleijn http://about.me/roydekleijn?promo=email_sig
On my view, I love the previous Laravel 4 paths definition, all files related with "app" environment into "app" folder (config, storage, resources, etc...). It was easy to create multiple environments (isolated) into a unique Laravel installation, now you can't do it. Main project folders are common and others are into app folder, why?
Now it's difficult to start/share projects from a common "app". Even is worst to text editor project definition (like Sublime Text), now you have more folders that you need.
Previously, all outside "app" and "public" folders was a Laravel domain, and inside "app" and "public" was a developer domain, now is all mixed.
I hope that my comment will be taken as constructive :)
@foxmedo Please can you help me to achieve this. what tutorial, what precaution ...
I want to have a modular laravel structure where all the (controller, views, ... ) can be regrouped by module. thank in advance.
@noyessie Google "laravel modular structure". There are lots of options available, like this one.
thank you
2018-02-20 15:15 GMT+01:00 Clayton Stone notifications@github.com:
@noyessie https://github.com/noyessie Google "laravel modular structure". There are lots of options available, like this one https://nicolaswidart.com/blog/writing-modular-applications-with-laravel-modules .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/laravel/framework/issues/3984#issuecomment-366989913, or mute the thread https://github.com/notifications/unsubscribe-auth/AJH_U_MsBLKgK-SVI8OjPNPdM95TAZSDks5tWtOCgaJpZM4BsSHz .
-- Hubert Noyessie ----------------------------------- Ingénieur Polytechnicien, Génie Informatique, Promotion 2017 Tel : +237 <+237%206%2090%2023%2082%2030>695749759 / +237 683375353 Email : hubertnoyessie@gmail.com rostandyoba2014@gmail.com
unfortunate but we have stopped working with laravel a few months ago, we have returned to our old platform based on CodeIgniter, packages in laravel doesn't follow laravel updates, and laravel create each time new structure which disrupts our work. we are working on large scale application and we need stable framwork
This proposal suggests to:
The changes required to reach these goals are few and simple.
The 14 associated pull requests are ready to be submitted, waiting for approval of this proposal. If it can help on making the good decision, I would be really pleased to submit these pull requests before approval.
On a personal note, I think that suggesting and not enforcing a directory structure conforms well with the Laravel philosophy.
New Configurable Paths
The goal is to remove the hardcoded app paths from laravel/framework and replace them with configurable values, defined in the
bootstrap/paths.php
config file (except for logs and cache views). Here is the proposed new bootstrap/paths.php. Here are the new configurable paths with their associated keys and proposals :/commands (path.commands)
Only the Artisan command
command:make
explicitly refers to thecommands
path. Though that path could be overridden using the--path
option, I think that it would be interesting to remove the hardcoded path for the sake of completeness./config (path.config)
The reference to the
config
folder inFoundation/Application.php
,PublisherServiceProvider
, and thekey:generate
command could be removed and replaced with the new keypath.config
./controllers (path.controllers)
As for the
commands
folder, the change is not really necessary ; only Artisan commands refer to that folder, and the hardcodedcontrollers
can be overridden using the--path
option./lang (path.lang)
Only the
TranslationServiceProvider
uses that path, which could be changed to the new keypath.lang
./database/migrations (path.migrations)
Various commands refer to that path ; it could be easily replaced with the new key
path.migrations
./start (path.start)
Why shouldn't the start path be configurable ?
Foundation/start.php
andConsole/Application
could be updated to use the newpath.start
key./storage/logs (log.file on framework and laravel)
Not really sure about this one. The log file is specified in 3 places : in
start/global.php
, which is fine, and twice in theTailCommand
, once for local tailing and once for remote tailing. TheTailCommand
allows to choose the file to tail using the--path
option, so the hardcoded path can be bypassed.Anyway, to replace the 3 occurrences, a new configuration file could be created
config/log.php
, which would contain afile
key specifying the path to the log file (maybe the key should be named path ?). To avoid a BC, the old hardcoded path can be kept in theTailCommand
code :/storage/views (view.cache on framework and laravel)
The cache used by the view compiler engine is pointing to that path. A new key
cache
could be created inconfig/view.php
to remove the dependency to that folder. Also, to avoid a BC, the hardcoded value can be kept in the code as a fallback :/views (path.views on framework and laravel)
This is a tricky one, as the view paths are configured in config/view.php. A solution could be to move the main view path to
bootstrap/paths.php
, and to specify only the additional paths inconfig/view.php
.PublisherServiceProvider
,ServiceProvider
andViewServiceProvider
could be changed to use the new keypath.views
.Breaking Change
The addition of a new method
getDefaultInstallPaths
can avoid a BC, This method could return an array containing the default paths. This array could then be merged with thebootstrap/paths.php
array, so that all the expected keys exist.Here is the install path fallback proposal.
Helper functions
I don't think that helper functions such as
app_path
,base_path
,public_path
andstorage_path
are needed for these new configurable paths, as they are kind of underground. Though, it would make sense that all the keys from paths.php have their helper functions. Any comment on this is really welcome.