Feature/dev 978 volume fs subpaths

[i-just]

Description

• ability to use the same filesystem for multiple volumes
• ability to specify filesystem subpath (fsSubpath) on per-volume basis

Additional info:

• changing fsSubpath for volume doesn't automatically change the folder's name and it doesn't update child folder paths (just like changing FS base path doesn't do those things)
• volume fsSubpath is factored into creating/renaming subfolders in Assets and creating/editing Asset Fields
• ensures unique paths across all volumes that use the same FS

Related issues

DEV-978
#11044

[linear]

DEV-978 Volume FS subpaths

Volumes should be able to choose a subpath within their selected filesystem, so filesystems can be reused across multiple volumes.

This would also mean that multiple volumes should be able to select the same filesystem.

[brandonkelly]

@i-just The current implementation is dropping any inner slashes in the Filesystem Subpath. For example if you set it to foo/bar, it will end up getting normalized to foobar/.

I don’t think that the subpath should be stored within the volumefolders table; instead we should add a new fsSubpath column to the volumes table and store it there. (This will require adjusting the Install migration, as well as creating a new migration for existing installs + increasing the schemaVersion to 4.4.0.2 in config/app.php.)

Folder paths stored in volumefolders should not be affected by the selected subpath. They should continue to be relative to the volume root, not the filesystem root. So if a volume’s Filesystem Subpath is set to foo/bar, any folders (and assets) within the volume should have paths relative to foo/bar/.

[brandonkelly]

Also, it would be good if volume validation made sure you don’t have a subpath that will conflict with another volume.

For example, if Volume A uses $MY_FS and its subpath is set to foo/bar, and Volume B wishes to also use $MY_FS and its subpath is either empty, or set to foo, foo/bar, or foo/bar/baz, it should result in a validation error due to the conflict with Volume A. The only acceptable subpath for Volume B would be a value that starts with something besides foo/.

[i-just]

Thanks @brandonkelly!

• dropping inner slashes in the Filesystem Subpath => I got too eager with cleaning the path; it’s fixed now
• subpath should be stored in the volumes table in a new column called fsSubpath (not in the volumefolders table) => agreed; I started with that and then backed out of it; it’s now implemented
• there was already a per-volume subpath validation in place, but it was different to what you’re after, so I’ve adjusted to:
  • always require a fsSubpath if there’s already a volume using the same FS and that volume has a fsSubpath defined (otherwise, FS won’t show on the dropdown list)
  • make sure volumes using the same FS don’t have the fsSubpath that starts with the same directory

Another thing to point out is that the transform location doesn’t take the fsSubpath into consideration (intentionally). For example, if your FS base is uploads and the volume using that FS has a fsSubpath of images and transformSubpath is empty, then assets will be stored under uploads/images, but transforms will be under just uploads. It felt like it has more sense this way as you can specify the same dir for fsSubpath and transformSubpath rather than wonder how to get out of fsSubpath if it was automatically included in the transformSubpath.

[brandonkelly]

Similar to my previous comment – asset paths should be relative to the root of the volume (like folder paths), not to the root of the filesystem.

[brandonkelly]

Basically, nothing about working with assets should reveal anything about the fact that a filesystem subpath was specified on the volume settings. All of the filesystem subpath logic should be completely contained to the volume itself.

[i-just]

Closing this PR as I’ll be opening 2 new ones for this work. One for C4 (Volume to use FsInterface) and one for C5 where we actually add support for fsSubpath.