Project

General

Profile

Actions

Bug #102211

open

Uri.ResourceViewHelper not respecting config.forceAbsoluteUrls

Added by Sebastian Fischer about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Fluid
Target version:
Start date:
2023-10-20
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

According to feature #87919 "all links, references to images or assets" should be rendered with "site prefix / current domain" if config.forceAbsoluteUrls is set to one.

This does not work for

<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png"/>

The result is

/_assets/5a5aaa267f0a773867727fec1920f9af/Images/icon-home.png

Only if the optional viewhelper argument absolute is set to true, the domain gets prefixed and the result is as expected

https://dev.arpa/_assets/5a5aaa267f0a773867727fec1920f9af/Images/icon-home.png

Actions #1

Updated by Garvin Hicking about 1 year ago

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.

Actions #2

Updated by Sebastian Fischer about 1 year ago

While i understand the problem with fetching the TypoScript, i disagree with the agrument about the $arguments['absolute'] problem.

If config.forceAbsoluteUrls is set, it does not matter if $arguments['absolute'] it not set or false, it should always be result in an absolute url.

Hence the name FORCE absolute urls.

So if config.forceAbsoluteUrls is set, i would expect:
<f:uri.resource path="EXT:sitepackage/Resources/Public/Images/icon-home.png" absolute="false">
--> Uses an absolute URL.

So this would result in

$absolute = $arguments['absolute'] ?: (bool)($GLOBALS['TSFE']->config['config']['forceAbsoluteUrls'] ?? false);

Actions #3

Updated by Garvin Hicking about 1 year ago

How about the idea of a site setting?

Both typoscript and the viewhelper could access it, you'd have a central place. The two things you'd have to do is adapt site settings plus add the absolute={settings.absolute} attribute to the calls of the viewhelper...?

Otherwise, since it would be a breaking change (even though it'd be part bugfix too), it can only get added to v13. I could offer to create a patch implementing it, but I'm still undecided as you can see 😅

Actions

Also available in: Atom PDF