Adjust resource identifier in PageRenderer asset registration in backend module template

[chrrynobaka]

This pull request fixes an issue related to how a CSS asset is registered in the backend PageRenderer.

Explanation of why this should be changed:

As of right now, the affected file Index.html calls the <f:be.pageRenderer>-ViewHelper to register some some assets to be used in the backend Solr Info view. The CSS file is included by passing it into the ViewHelper through the includeCssFiles-attribute -- more specifically, the CSS resource is first processed by the <f:uri.resource>-ViewHelper and the return value of that is passed into the PageRenderer.

As can be seen in the TYPO3 Docs for version 11.4 , the example they list includes it this exact same way: First processing the relative resource path and passing the return value into the PageRenderer.

Since TYPO3 12, this piece of Documentation has been changed to reflect the proper way of handling the attribute value:
Pass a relative file path based on the extension itself using EXT:<extension_key>/<filepath> and let the PageRenderer resolve the path for us. You already use a relative file path, which is great.

The URI-related ViewHelper that has been used here 'processes' the CSS file immediately, copies it to a public and most importantly linkable directory, to e.g. allow this resource to be referenced in the frontend directly.
This is still the go-to way of including resources in Partials and Templates in many cases, but in this specific case, it is highly suboptimal:

In essence, we process a resource and pass it into the PageRenderer, where it would be processed once more.
A basic TYPO3 installation - and really, most advanced installations as well - will be able to handle this just fine. TYPO3 will simply not process this file again, as it recognizes that it is located in the public directory already and will just include it as-is, meaning that using the ViewHelper is pretty much redundant.

I have a more special setup in the sitepackage I develop at my job though where I do additional processing of all assets including in BOTH the PageRenderer AND the AssetCollector. There can be a number of reasons for why a developer (or user) might be doing this, including but not limited to minification, pre-/post-processing, compression or any other potential additional kind of resource handling.

Any existing TYPO3 installation will still work just fine with this change as TYPO3 is able to resolve these paths itself. While this will fix a 'bug' for me, I'm writing this PR mainly because this is the more proper way of handling things in accordance to what the TYPO3 Documentation recommends today.

Even though TYPO3 once did it this way in their own documentation examples in the past - they don't do so today and neither should we 'pre-process' (resolve the resource path) for the PageRenderer here.

[dkd-kaehm]

Thanks for fixing that issue.

[dkd-kaehm]

@chrrynobaka
Is that patch for EXT:solr 12.0.x backportable?