Exception "...could not be loaded"

[infabo]

Uncaught TYPO3 Exception: #1225709595: The Fluid template files "/application/private/typo3/sysext/scheduler/Resources/Private/Partials/TaskList.html", "/application/private/typo3/sysext/scheduler/Resources/Private/Partials/TaskList" could not be loaded. | TYPO3Fluid\Fluid\View\Exception\InvalidTemplateResourceException thrown in file /application/vendor/typo3fluid/fluid/src/View/TemplatePaths.php in line 730

[infabo]

ls -la typo3/sysext/scheduler/Resources/Private/Partials/TaskList.html

ls: cannot access 'typo3/sysext/scheduler/Resources/Private/Partials/TaskList.html': No such file or directory

[infabo]

The path is actually:

-> typo3/sysext/scheduler/Resources/Private/Partials/Backend/SchedulerModule/TaskList.html

[NamelessCoder]

Are you using the most recent bugfix release of whichever TYPO3 version you use - and if you use composer, have you tried composer update to get Fluid at 2.5.4? This template file resolving issue should already be solved.

[infabo]

According to my composer.lock:

 {
            "name": "typo3fluid/fluid",
            "version": "2.5.4",

TYPO3 9.5.0 here.

[NamelessCoder]

It turns out this may not be easy to actually solve - instead, it may be necessary to catch and swallow exceptions about unresolvable files and simply skip those files. That does however mean that neither the template calling the "missing but not missing" partial, nor that partial itself, will be compiled. To be precise: the partial does get compiled but not with the correct identifier since it has a different path when detecting files.

The problem being that partial root paths are nested in the standard path but overridden to use a folder inside the default root path. In that context, partial identifiers are not the same as they would be starting from the default root path.

This further has a tangent to how TYPO3 CMS currently defines Fluid template paths. I've suggested and plan to make a proof of concept that moves Fluid template paths to PHP-based and global configuration (TYPO3_CONF_VARS) which would allow these paths to be registered correctly without having to parse TS.

TL;DR: if anyone wants to take a look at catching and suppressing the InvalidTemplateResourceException then that is a solution I would accept. It might have to be done in namelesscoder/typo3-cms-fluid-precompiler, though...