When uploading images I realize FIRST I can use store method which saves images in the storage/app/public by default then I'll have to create a symbolic link from public/storage to storage/app/public to access the image.

SECOND, I can still use move method and have the image saved in the public/images directly.

I feel like the first way is longer for no reason, is there scenarios of when to use one over the other or it's just a matter of preference ?

CodePudding user response：

from laravel documentation https://laravel.com/docs/5.4/filesystem:

move method may be used to rename or move an existing file to a new location

Laravel makes it very easy to store uploaded files using the store method on an uploaded file instance.

So, use storeAs() or store() when you are working with a file that has been uploaded (i.e. within a controller), and move() only when you've already got a file in the disk to move it from one location to another.

CodePudding user response：

Yes it's better in some cases, but it might not be relevant to you, let me explain.

The storage folder is usually considered a "shared" folder. What I'm trying to say with that is that the contents usually should not change when you deploy your application and most of it contents are usually even ignored in git (to prevent your uploads to end up in your git repository).

So storing your uploads in this case inside the storage/app/public directory means the contents are not in git and the storage folder can be shared between deployments.

This is useful when you are using tools like Envoyer, Envoy or other "zero downtime" deployment tools.

Most (if not all) zero downtime deployment tools work by cloning your application to a fresh directory and running composer install and other setup commands before promoting that fresh directory to the current directory which is used by your webserver to serve your app. Changing a symlink over to a new directory is instant and thus you have zero downtime deployments since all setup (installing dependencies etc.) were done in a folder not yet serving traffic to your users.

And since each deployment start with a fresh clone of your repository that also means that your public and storage folder are empty again... which is not what you want because you of course want to retain uploads between deployments. A way to work around that is that those deployment tools will have the storage folder stored in another folder and every deployment it clones your git repo and symlinks the storage folder to that shared storage folder so all your deployments share the same storage directory making sure uploads (but depending on the drivers you use also sessions, caches and logs) are the same for every deployment.

And from there you can use php artisan link to symlink the storage/app/public to public/storage so that the files are publicly accessible.

(Note: with the symlink in place it doesn't matter to which path your write, storage/app/public or public/storage because they point to the same folder on the disk).

So this seemingly overcomplicated symlink dance is to make deployments easier and having all your "storage" in a single place, the storage dir.

But when you are not using those zero downtime deployment tools this all seems like a lot of nonsense. But even there it still might be useful to have a single place where all your app storage lives for backups for example instead of having to backup multiple directories.