-
Notifications
You must be signed in to change notification settings - Fork 11k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[5.3] Use 'url_root' config value to generate disk url #16281
Conversation
Using the same technique, |
If you already know the full URL, why even use the filesystem to generate it at all? Why not write your own helper to generate it? |
Since the purpose of Also it's not always true that the files are being stored directly under Also consider someone with this config 'disks' => [
'public' => [
'driver' => 'local',
'root' => storage_path('app/public/some_directory/'),
'visibility' => 'public'
]
] In this case the To fix this, we can then add the config Another use case is when the files are stored directly in 'disks' => [
'public' => [
'driver' => 'local',
'root' => public_path('/uploads'),
'visibility' => 'public',
]
] Using In addition we could use the same technique to generate urls with the FTP driver. Laravel, is well know for flexibility and being able to customize parts of the framework. After all adding one key of config is a lot better then making a new helper to generate urls. |
But I'm saying you just shouldn't do either of those things. What's the point? It's just change for change's sake it seems like to me unless there is more information you have? Storing them in storage/public works fine. Storing them directly in public is a legitimate problem I don't even want to encourage because it breaks things in many types of deployment setups. |
It's not changing the directory name for fun. Have two real world use cases: First use caseIn the first case i'm forced not to use symbolic links (uploads stored directly in the public), and use a folder other then I have a legacy application, that is going to be upgraded to laravel. The legacy application uploads are stored within The intial domain will point the the Second use caseLike i demonstrated in my initial message i have a multi tenant application. Each tenant has his own disk. The disk path is In this case the disk doesn't point directly to The reason for using a disk per tenant, is that it will make my code better. But if i use a single disk with this path This is two uses cases that i'm dealing with right now, and maybe others could have similar or different ones in the future. The PR allow for more flexibility without changing the default behavior. (so no harm is done) On top of all that, the framework allows to set the default folder for storing |
Should this be mentioned in the docs? |
Add the ability to set a custom url for a disk. This feature has landed on laravel 5.3, and this commit allows to use it on any compatible version. See laravel/framework#16281 for details and use cases.
Add the ability to set a custom url for a disk. This feature has landed on laravel 5.3, and this commit allows to use it on any compatible version. See laravel/framework#16281 for details and use cases.
@taylorotwell I actually need it now for the same reasons @shadoWalker89 presented you. So have no regrets, this is useful for people. |
The value of
url_root
will be used instead of/storage/
This is very useful in multi tenant applications, where each tenant should have it's own subdomain for serving files.