TYPO3 Core

Fluid template paths should be defined in a global place, avoiding the tie-in with TS configuration, but preserving the ability to distinguish template paths for a certain extension and plugin.

This can be achieved with the following strategy:

1. Prepare $GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['paths'] to contain 1) ["global"] index for system-wide Fluid template paths, 2) [$extensionKey] index for extension-global paths, and 3) [$extensionKey][$pluginName] sub-index for plugin-specific paths
2. Prepare to consolidate template path configuration into TemplatePaths
3. Deprecate the ability to set view paths in TS - once removed, the consolidated template path configuration in TemplatePaths can take over directly
4. Deprecate the wrapper methods on ActionController that forcibly sets templateRootPaths etc.
5. Deprecate the distinguishing between FE and BE templates (to be removed when TS method to set paths is removed).

This facilitates the following quite significant features:

• First of all, system-wide Fluid template collections that can be dynamically extended and automatically available to any extension including overlay paths. For example, TYPO3 vanilla might ship with a VERY basic "Content.html" and "Page.html" layout file pair, then fluid_styled_content could add its own added-feature versions of those files. Those then finally are available by simply referencing <f:layout name="Content"> from any template that should wrap with FSC when FSC is installed, vanilla when not, or an override if you created a special Content.html layout file.
• Second, by no longer demanding that TS is used for configuring View paths we make the set of "folders where we expect Fluid templates" a PHP-level configuration in global array, meaning that things like warming up template files and caching manifests of every possible Fluid template in the system becomes possible, which would greatly reduce the time it takes to do things like resolve a template file.
• Third, by deprecating the TS method of setting views and not reproducing any context-sensitive (FE vs. BE) resolving, we homogenise the way template files are resolved in FE and BE to use only one expected set of template locations - but we still allow third-party code to make any and all modifications it wants, to these global path arrays, based on arbitrary ENV or other context.

We will then also be prepared for a future iteration of Fluid which consolidates template file locations to use a single set of paths for all resources, making the sub-folder structuring completely up to the framework. When that happens, a global array will be much easier to handle compared to DB-contingent sys_template records or static TS inclusions as we will already have deprecated the contexts that cause the most trouble when migrating.

This relates to the rumoured vision to remove all Extbase settings from TS context.