Task #105993
openEpic #103035: Handle EXT syntax more flexible
Resource API and Unified File System Access
0%
Description
I think we should unify File System Access in v14.
TYPO3 v14 should follow these goals:
1. Introduce a folder called "resources/" on the top-level project that contains templates, labels, css, svgs, javascript... all files that are needed to render a "frontend". In Classic Mode, this folder will be in "typo3conf/resources".
This is all an effort to reduce the necessity to store per-application specific files in site extensions. We've identified that setting up site extensions (and via composer, path repositories) are neither best practices nor standarized. This way, we introduce the "System Resources" API.
For this to work, we need to
- introduce a new method "Environment::getResourcesPath()"
- Ensure TYPO3 understands to load files relative to the resources path and not the public path anymore.
2. We need a PHP API to access such "system resources", as they can also be split into private and public, similar to Extensions. With extensions we have EXT: as prefix, with the local project-specific files we also need to either have a OO API or a syntax to access them in TYPO3 Core as well.
I suggest to introduce a new "ResourceLocator API" which returns a ResourceInterface (knowing the full real location, the requested location).
3. In this regard, we should actually introduce a new API in various extension places to deal with Resources as objects and not just "strings". If have an object resolved from "EXT:my_site/Resources/Public/Icons/Extension.png" it should be the same object as from "typo3conf/ext/my_site/Resources/Public/Icons/Extension.png". This way, we finally remove the necessity to juggle with "versionNumberedFileName", absRefPrefix and other options where TYPO3 usually needs to guess if these features have been applied or a file actually exists.
This should work the same for system resources and extension resources.
At the end of this step, we can safely deprecate PathUtility::getAbsoluteWebPath(), GeneralUtility::getAbsFileExtPath()
Ideally, these system resource objects and extension resource objects can then solve the additional problems:
- we never work from the public root anymore
- FAL: fallback storage 0 does not exist anymore
- In an ideal world we can use the Resource API and FAL API next to each other and can properly document how this works side by side.
Open Questions:
- Should the "resources" folder be read-only or writable by the system?
- How to "process" such resources (image resizing / cropping or concatenation of JS/CSS files)
- How to deal with system resources vs. FAL references?
- Should this also be the new default place for XLF files and form.yaml files?
- Do we need some kind of permission system for them?
- How should the folder underneath be structured? per-site basis? or per-type basis (e.g. content blocks)
- how do we deal with "publishing" of such files in the public/web/htdocs folder?
- how to deal with fluid templates (bigger topic)?
- hot to deal with the content blocks approach of having a single directory that contains 'everything'?