See also: File Gallery Revamp
Note: If a file is too big to upload via the web interface, site admin can upload manually, and then manage via Tiki (ex.: give it meta-data). Currently, the way to do this is Batch Upload.
We could enhance the File Gallery feature to have two modes per file gallery:
- Abstraction (the default)
- Direct mapping or pass-through / path preservation (a new mode to be added)
- We still need to be able to move files back and from the two file gallery types
- How would Tiki know there has been some changes to the files (additions / removals)?
- To update the meta data in the Tiki database and apply operations (ex.: Watch)
- If a file is renamed, how does Tiki know it was renamed, and not a deletion, and addition (which would lose any meta data about the file)
- How to deal with version history of files? (Perhaps use the same format as Syncthing)
- What happens when a folder is created? It should not be possible to have an "Abstraction" file gallery as a child of a "Direct mapping" file gallery.
- How is security handled? Permissions would have to be for whole folder? and folder should ideally be stored outside the web root.
- How to deal file content indexing?
- Kolab has an XML for each file, that has the meta data: https://wiki.kolab.org/Kolab_3.0_Storage_Format
- Tech background about File Galleries by Louis-Philippe
- To be future proof, perhaps we should add an abstraction layer like Flysystem, Gaufrette or others?
- Do only via elFinder (no legacy UI mode): https://github.com/Studio-42/elFinder/wiki/Connector-configuration-options-2.1#localfilesystem
- ClearOS Flexshares as part of WikiSuite
- http://elfinder.org/ Can also be used as a new front-end for the file gallery revamp
- http://ajaxplorer.info/ (AGPL)