History: File Gallery - Direct Mapping
Source of version: 7 (current)
Copy to clipboard
New in ((Tiki25)): It is now possible to map a Tiki ((File Gallery)) to a local folder or remote folder via [https://packagist.org/packages/league/flysystem|league/flysystem], permitting (S)FTP, WebDAV, S3, etc. This is in contrast to the default mode, which is a virtual file system (File and folders and all their meta-data are fully managed within Tiki).
What are benefits of a virtual file system like Tiki File Galleries?
* Can manage files without the constraints of a traditional file system. Can have file versioning, a file can be in multiple categories, and it appears in various lists and reports, etc.
* Each file (including versions) had a unique ID, so no file collisions, and persistent URL (option to maintain URL for new versions of a file)
* Can store files in a database (or on file system)
* Security is better because file named can't be guessed (files on disk are named with a long alpha-numeric string)
This is the most efficient in most use cases. But it does have drawbacks if you need to interact with external systems, which typically don't know how to interact with Tiki.
So in some cases, we want to preserve original file names and filesystem structures so that relative paths are preserved in a group of related files where one file expects another one at a certain relative path.
* It could be files that are generated by an external system. Ex.: An HTML file with some images (need to maintain internal links)
We could also want the files to live on an external system accessible via FTP, SFTP, WebDAV, or the S3 protocol (which is widely used, not just with AWS).
It also permits the usage of file sync tools like [http://wikisuite.org/Syncthing|Syncthing])
We may have a traditional shared folder (Samba, etc.) and we want to provide web access with access controls.
Initial commit: https://gitlab.com/tikiwiki/tiki/-/merge_requests/1904/diffs