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
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 ?
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Yes it’s better in some cases, but it might not be relevant to you, let me explain.
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.
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
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
public/storage so that the files are publicly accessible.
(Note: with the symlink in place it doesn’t matter to which path your write,
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
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.
from laravel documentation https://laravel.com/docs/5.4/filesystem:
movemethod 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
storemethod on an uploaded file instance.
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.