Provide a standard place to store uploaded and other volatile files

[lcharette]

UserFrosting requires a file storage service to handle saving user uploaded files (like avatars), or other type of volatile files to the Filesystem and across sprinkles. This of course should be built on top of Laravel Filesystem component. The file storage should also support third party provider if one wants to store file in a AWS instance or Dropbox account for example, but the base structure of the "storage unit" still need to be decided.

The first question is where to store user uploaded files ? We need to gitignore this location, but provides an easy way for dev to backup this data. Do we create a centralized location (ex public/storage or app/storage ) or should each sprinkle has it's own storage/ dir?

Second question is how do we structure the file inside that location. Do we require one dir per sprinkle?

I think if we wants sprinkles to interact with other sprinkle files and make it easy to backup, they should be store in a centralized place and optionally be sorted by sprinkles. For example:

Storage/
    Foo.png
    Core/
        Bar.pdf
    Account/
        Avatar/
            Malou.png
            Alex.png
    Admin/
    non-sprinkle-dir/
        blah.txt

Sorting by sprinkle avoid one sprinkle overwriting vital file from another one. Making it optional means two or more sprinkles can interact with the same file. For example, if one handle uploading and one handle dynamic creation, the sprinkle that handle displaying the file don't need to know which sprinkle store the file first place.

I also think such a feature should be in a new sprinkle included in the base install.

This needs to be fixed/decided/implemented before #620 can be implemented.

[lcharette]

Of course, storing files in public/ means we can't access control those file ;)

[archey347]

I've started a new sprinkle called uf-files.

I've put a breif plan in the wiki about how I intend to structure it.

[lcharette]

I've been thinking about this recently. I think build in support for file storage should probably be minimalistic and flexible. I think in some case, it make sense for many sprinkle to put stuff in a shared directory. In other situation might be critical one sprinkle file's can't be overwritten by another one and so on. And renaming files with DB support like @archey347 propose might also be suitable for specific function, but overkill for others (in my project, I want to retain the same file name in the filesystem so I can easily download them via sftp).

The best approach for a Core UF functionality might be to provides simple ways to manage files across a centralized location ( app/storage ) while providing a standard method to access or store files in a specific sprinkle storage box . For example :

$file->store(); // stores in app/storage/shared/
$file->store()->inSprinkle('foo'); // stores in app/storage/sprinkles/Foo/
$file->store()->inSprinkle('bar'); // stores in app/storage/sprinkles/Bar/

$fileFoo = $storageService->getFile('MyReport.pdf')->fromSprinkle('foo');
$fileBar = $storageService->getFile('MyReport.pdf')->fromSprinkle('bar');

As for the public/storage vs app/storage, I prefer storing files in app/, as (1) it will allows to control the access to the file and (2) be a writable directory at the same level as app/sessions, app/logs, etc.

[lcharette]

I've stared implementing centralized storage in UF in the feature-develop| storage branch. After much research and tests, I decided to work with Laravel Storage system. Main reason for this, over a pure Flysystem integration, is their use of disks.

Instead of using a per sprinkle or shared storage, UserFrosting will bundle by default a shared "disk", located in /app/storage. If a sprinkle requires to sandbox is files (so another Sprinkle can't accidentally overwrite them), this sprinkle will be able to define a new "disk". Same goes if a dev want to save default/basic stuff to the filesystem, while saving his custom sprinkle data to a S3 instance for example, all using the new filesystem service.

Other benefit is Laravel documentation will be directly applied to UF. One downside is maintaining this integration, but so far it's not that much of a problem. Only thing requires for it to work is to map out the config file correctly.

I'll add next the necessary controller methods to access (and probably upload) files to this default storage space. Might as well include #620 in the mix ;)

[lcharette]

The filesystem service has been added to develop for 4.2 release and documented on the develop branch of learn !