Configurable Fileadmin with different file storage locations

TYPO3 Association Community Budget Ideas 2024 Q4
1

By Eike Drost

What is your idea about?
The fileadmin should be able to communicate with different storage providers so that services such as AWS, DO Block Storage, MinIO, etc. can be used instead of direct storage on the respective hard disk. Classic storage should still be available so as not to overburden older or smaller installations.
With such a storage option, CDN systems or similar could be used to deliver media faster and reduce the cost of the web service for the TYPO3 installation.
This would be an enormous benefit for web systems of large companies, as the costs for operating the web application can be reduced. Furthermore, such a solution helps with the operation of TYPO3 in environments such as a cloud or a Kubernetes infrastructure.

What do you want to achieve by the end of Q4 2024?
Creation of a fileadmin abstraction level with e.g. interfaces. (For modular expansion if a service cannot be offered directly)
Creation of corresponding own core extensions, which take care of the storage and processing of the media data records for the respective service provider.
Starting with an AWS implementation to connect the Block Storage MinIO and the AWS Storage Drivers directly.
Continuing with the respective providers, which can be prioritized from a survey.

What is the potential impact of your idea for the overall goal?
Greater compatibility with other systems
Improvement for cloud services and platforms such as Kubernetes
Cost reduction in terms of performance when loading media
Decoupling of code in Fileadmin, helpful for more individuality

Which budget do you need for your idea?
10.000 Euro

Please note: After the start of the voting we can not change the idea description nor the idea outcome. If this idea is selected by the members, it must be archived as described.

2 Likes
2

Maybe I’m missing here something but:

  • The TYPO3 Core already provides a File Abstraction Layer system (FAL) along with interfaces and the logic of Drivers and storages
  • Fileadmin is just a (default) created storage with the local driver
  • 3rd party extensions exists providing additional drivers, for example the AWS S3 driver (which may also work with minio but not tested)

Additional drivers can be implemented by the community and shared if needed. I’m not a fan of doing here a lot of stuff and adding specific paied services adoptons directly into the core. For that reason the exensibility already exists.

AWS S3 itself is not a CDN - that would involve an additional service, which could also implemented taking the current File Abstraction Layer API.

Doing a mix “within” a defined storage is something which should be avoided. One “storage mountpoint” one driver.

In the end, you can remove a generic filedamin storage and doing custom storages with custom driver.

Maybe you can make your idea more precise based on FAL instead of stating to create something duplicated (for which the budget would never be enough anyway).

https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Fal/Index.html

5 Likes
3

For TYPO3 v12 compatibility there is also the AWS S3 FAL driver FAL S3.
I’m no expert on S3 stuff but this driver is being used by several larger container based installations which don’t use the local filesystem for user files anymore.

If I look at the functionality for this idea it seems to me that a FAL driver is just what is needed. Perhaps I misunderstood it; maybe a different explanation could make it clear?