Bug #102193
open
Introduce a CONFIG: import for TypoScript imports
0%
Description
Since TYPO3 12, it is not possible to load TypoScript files via backpathing anymore.
We have a use case, where we place TypoScript configuration files in the config-folder in the project root. These files can no longer be reached by @import since it is only accepting relative paths from the location of the script, that has the @import, an EXT: path, an absolute path with the full path of the system, as provided by Environment::getProjectPath, or a relative path inside the public folder (that can never be left because backpathing is forbidden).
It would be nice to have some key locations of the system as variables, the same way the EXT: prefix is working.
For example:
`CONFIG:my-config/additionalSetup.typoscript` would lead to `/path/to/project/config/my-config/additionalSetup.typoscript`.
Files
Updated by Garvin Hicking 6 months ago
Hi!
That's an interesting idea. Can I ask what is the reasoning to put the file in there instead of a "usual" sitepackage extension?
Currently, a lot of places in TYPO3 conceptually require a sitepackage extension. Possibly in the "future" the config/ directory will be able to act as a sitepackage. In that case, the notation will probably change to already be relative to the config directory itself. So I'm not too sure that introducing such a central alternative may be establised (speaking for myself, not for the "TYPO3 Core").
Also, it may lead to people trying to use CONFIG: as a notation on other places where only EXT: is allowed (i.e. symlinking public assets), where we would need to explain people, when they can use CONFIG: and when not.
Maybe if we can talk more about the requirement why you put the file there, we can find an alternate approach that has less of an impact?
Updated by Kevin Ditscheid 6 months ago
Sure,
we have an extension that acts as a configurator of some sorts for the website frontend. It has a backend module, where you can change certain aspects of the frontend on the fly and it will save this configuration inside the config-folder, because saving config in the ext-folder isn't update-save and generally not the right place to hold dynamic configuration.
Also we are versioning this generated configuration, so simply putting it into the database also isn't the right way for our use case.
The config-folder was the ideal place, because the site-configuration already lives there and also can be generated dynamically by a backend module.
This worked flawlessly until the recent change in v12, where include paths are checked against certain patterns and backpaths where forbidden.
Updated by Christian Kuhn 6 months ago
- Related to Feature #97816: New TypoScript parser added
Updated by Garvin Hicking 6 months ago
Hi Kevin!
Thanks for elaborating on this.
V13 has some improvements on allowing i.e. TSConfig/PageTS in the config/ directory already. Having a feature that allows to utilize config to act somewhat like a sitepackage will probably come. First some include_typoscript options would need to be deprecated+removed to tidy this up in all areas. Deprecating+removal of allowing arbitrary file locations (specifically fileadmin) for TS-storage was the first step to create a base for cleaning this up. Adding a "CONFIG:" approach to this might create double migration pain, if the route for v13 will be properly evaluated.
My suggestion for you, as an intermediate solution, would be to either:
- Apply your patch as a composer-patch to the installation for your own usage (since you know where you can use CONFIG: and where not, and some edge cases of directory/file traversal in composer and non-composer modes won't affect you).
- Maybe you could place a symlink to your file in config/ inside your EXT:sitepackage, and then include that symlink via normal means. This way you could still generate and version your file within config/, but make that file accessible for inclusion through EXT: syntax on other places...?
Best regards,
Garvin