[BUGFIX] Abuse of storage 0 for extension resources

[gilbertsoft]

This patch makes sure the virtual storage 0 is not longer abused by the
StaticFilesProcessor. Therefor the StaticFilesProcessor now returns URIs
of the provided files and not longer FILE objects.

All EXT: references are now properly resolved through
PathUtility::getPublicResourceWebPath() if available (TYPO3 11.4.0 and
higher) or by providing an absolute path to
PathUtility::getAbsoluteWebPath.

FAL resources are resolved using PathUtility::getAbsoluteWebPath also
by providing an absolute path.

The new behavior is disabled by default and can be enabled by setting
"compatibilityMode" to "false".

[benjaminkott]

This approach is totally off the track, we need to be able to generate file objects no matter where they are stored.
It must be possible that the core delivers file objects to handle assets no matter where stored. Otherwise, we cannot handle/process them at all. That the core builds fake storage for them is not our problem to solve nor to handle.

The only reason the static files processor exists is to get the file objects. Path resolving would also be possible in other ways.

[helhum]

It must be possible that the core delivers file objects to handle assets no matter where stored.

I agree. However, that core currently can't do that (without relying on a technology that is broken by design).

Otherwise, we cannot handle/process them at all. That the core builds fake storage for them is not our problem to solve nor to handle.

Well, it IS a problem to be handled here until the core is able to deliver what is needed in a clean and meaningful way.

I see two options: Deprecate the StaticFilesProcessor.php (because it currently can't hold to its promises) and introduce a new one to just resolve URLs, or introduce a new concept using objects here.

We can't just use technology that is broken by wishfully thinking it is not and (even worse) recommend other to do so as well (which is implicitly done as the official TYPO3 introduction package is based on the bootstrap package).

We can discuss the best options how this can be handled, but it MUST be handled anyway, latest, when FAL storage 0 is deprecated in the TYPO3 core.

[helhum]

I would say, that deprecating the StaticFilesProcessor is the only viable option here.

[gilbertsoft]

My change here is a draft for a good reason and it may change when the core delivers new options. For the moment the StaticFilesProcessor still works as long as no composer vendor installation is in place (TYPO3 and Extensions installed in vendor).

The default configuration currently has one issue here with the logo which also can be solved in another way, for all useful options to include the logo the processor is imho anyway superfluous and could be omited.

I will try to keep this PR up to date with the coming core changes to finally get a solution on which everybody can agree...

[gilbertsoft]

Oh and I'm currently dreaming of an API which makes it possible to address each file as a file object like done for FAL. But that's something which may come with v12...