The current "problem" is that all the other viewhelpers operate in a manor, that first accepts the argument "absolute" from the Viewhelper, and then pass that on to a TypoScript-based parsing routine, interpreting it.
The Resource-ViewHelper is a bit different, because it does not rely on TypoScript, and uses other path resolving mechanisms unaware of TypoScript.
That means, this issue is probably better a feature request than a bug, because it breaks functionality if it were applied as is. Current usages may depend on that no absolute URL is ever returned, unless the parameter absolute=true is specifically set.
Now, if a TypoScript lookup were added to this (via $GLOBALS['TSFE']->config['config']['forceAbsoluteUrls']
), it would allow to infer the value from TypoScript.
HOWEVER, this creates a problem because if "absolute='false'" would be passed to the ViewHelper, it would NOT disable the absolute URL, because the TypoScript check would override it.
Sadly a viewHelper cannot decide if the absolute
argument is passed with "false" or NOT PASSED AT ALL, because a default value is already applied to the argument.
The ideal flow would be something like this:
if (isset($arguments['absolute'])) {
$absolute = $arguments['absolute'];
} else {
if (isset($GLOBALS['TSFE']) && isset($GLOBALS['TSFE']->config['config']['forceAbsoluteUrls'])) {
$absolute = $GLOBALS['TSFE']->config['config']['forceAbsoluteUrls'];
} else {
$absolute = false;
}
}
Main problem here being isset($arguments['absolute'])
will not work, because at the place of renderStatic()
it will always be set.
A way to deal with this probably would be a new argument like inheritAbsoluteFromTyposcript
that would be set to "false" by default to prevent a BC break.
Then these scenarios could apply:
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png">
--> Acts like before. Uses a relative URL.
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png" absolute="true">
--> Acts like before. Uses an absolute URL.
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png" absolute="false">
--> Acts like before. Uses a relative URL.
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png" inheritAbsoluteFromTyposcript="true">
--> New: Reads TSFE TypoScript. If available, the absolute configuration is utilized (setting absolute to true or false).
If TSFE is available, relative URLs will be used.
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png" inheritAbsoluteFromTyposcript="true" absolute="true">
--> New: Will IGNORE reading TSFE typoscript, because absolute=true. Returns absolute URL.
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png" inheritAbsoluteFromTyposcript="true" absolute="false">
--> New: Will IGNORE reading TSFE typoscript, because absolute=false. Returns relative URL.
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png" inheritAbsoluteFromTyposcript="false" absolute="true">
--> New: Acts just as if inheritAbsoluteFromTyposcript was not set. Returns absolute URL.
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png" inheritAbsoluteFromTyposcript="false" absolute="false">
--> New: Acts just as if inheritAbsoluteFromTyposcript was not set. Returns relative URL.
Totally easy, right? ;)
When having a new parameter though, people could also just simply set absolute="true|false", because they need to check all their usages, if they want a TypoScript fallback or not.
In that case I'd suggest to create a custom SiteSetting (maybe there already is one for forceAbsoluteUrls?) and then pass <f:uri.resource absolute="{settings.forceAbsoluteUrls}"/>
to it. This in turn could already be implemented now, and doesn't require a core feature patch / bugfix.