Project

General

Profile

Actions

Bug #77722

closed

absRefPrefix is not applied everywhere

Added by Robert Vock over 7 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2016-08-31
Due date:
% Done:

0%

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

Description

When I've set absRefPrefix, it is not set everywhere. One example is the srcset-attribute:

<img src="fileadmin/example.png" srcset="fileadmin/example.png 200w, fileadmin/example_400.png 400w">

gets converted to

<img src="/fileadmin/example.png" srcset="/fileadmin/example.png 200w, fileadmin/example_400.png 400w">

(only the first fileadmin in the srcset got replaced)

This happens because TypoScriptFrontendController::setAbsRefPrefix() just searches for "fileadmin as a simplification of finding attributes which start with a relative path.

One improvement would be to add the absRefPrefix in the getPublicUrl() method of ResourceStorage, if relativeToCurrentScript is false:
https://github.com/TYPO3/TYPO3.CMS/blob/84865ff97f567d412bf5b5cad4bc57aefaff3747/typo3/sysext/core/Classes/Resource/ResourceStorage.php#L1310

Then images which are used within srcset will already have the correct path. Of course this does not fix all missing prefixes, but at least all where FAL is used.


Related issues 3 (1 open2 closed)

Related to TYPO3 Core - Bug #72164: "absRefPrefix = auto" does not work if PageGenerator is not usedClosed2015-12-11

Actions
Related to TYPO3 Core - Bug #82486: IncludeJS* / includeCSS* (including compression / concatenation) ignoring absRefPrefixClosed2017-09-14

Actions
Related to TYPO3 Core - Bug #82574: Inconsistent support of config.absRefPrefix in fluid/extbaseNew2017-09-28

Actions
Actions #1

Updated by Benni Mack over 7 years ago

I would suggest that the fix is, that it searches for all local storages and takes their prefixes and searches through them in the same place - what do you think?

Actions #2

Updated by Robert Vock over 7 years ago

The method TypoScriptFrontendController::setAbsRefPrefix() already loops over the storages and sets the absRefPrefix for all folders:
https://github.com/TYPO3/TYPO3.CMS/blob/2ba08444c9cd7613c97e10b65fd53867565f205c/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php#L3884

There it performs a simple str_replace, where it takes the prefix of each storage and prepends a quote. So it searches for "fileadmin instead of only fileadmin. This works in most cases, when the path directly appears in an attribute, but not when it appears at other places.

It's not possible to perform a simple str_replace, when you leave the quote, because you would also replace fileadmin where it already is prepended by a prefix or a domain. I think this would quickly introduce new bugs. That's why I would only change the getPublicUrl()-method of ResourceStorage. If the introduces coupling between ResourceStorage and TSFE is undesired, there could be a hook like emitPostGeneratePublicUrlSignal and TSFE fixes the paths within the hook.

Actions #3

Updated by Ernesto Baschny over 7 years ago

  • Status changed from New to Needs Feedback

Robert Vock, the original css_styled_content implementation of responsive images uses the cImage method, which calls ContentObjectRenderer::getImageSourceCollection which will take care of adding the absRefPrefix before each link before rendering. I am not sure how you ended up with the srcset without the absRefPrefix. Maybe you are not using the cImage API? Could you elaborate on that?

Actions #4

Updated by Robert Vock over 7 years ago

I am using Smarty as template engine, and work directly with FileReference-Objects within the template and call their getPublicUrl-method ;)

But either way, it's not restricted to srcset. Anywhere, where an integrator uses the publicUrl, and it is not at the start of an attribute, absRefPrefix will not work.

Another example is a background image:


lib.backgroundImage = IMG_RESOURCE
lib.backgroundImage.file.import.data = levelmedia:-1, slide
lib.backgroundImage.file.import.listNum = 0
lib.backgroundImage.file.treatIdAsReference = 1
lib.backgroundImage.stdWrap.wrap (
  <div style="background-image:url('|');" class="page-background"></div>
)

page.20 < lib.backgroundImage

Here the publicUrl is not prefixed with the absRefPrefix.

Other examples might be, if you want to output a url within JavaScript, which gets generated by TypoScript.

Actions #5

Updated by Josef Glatz over 7 years ago

I also discovered the problem in TYPO3 8.4.0-dev (master) within the `f:uri.resource` view helper. Is this intentionally, or even a relevant error?

Actions #6

Updated by Christian Toffolo over 7 years ago

I also encountered this bug setting in a Fluid partial:

style="background-image: url('{f:cObject(typoscriptObjectPath: 'lib.imagePlaceholderFluid', data: {image: item.backgroundImage.0.uid})}');" 

The single quote after
url(
make function setAbsRefPrefix() to fail to add the absRefPrefix.

Actions #7

Updated by Alexander Opitz about 7 years ago

  • Status changed from Needs Feedback to New
  • Target version set to Candidate for patchlevel
  • TYPO3 Version changed from 8 to 6.2
Actions #8

Updated by David Bruchmann almost 7 years ago

Depending on need the usage of absRefPrefix might be wrong here.
IMO there should be either a parameter if absRefPrefix shall be prepended or a second variable including the merged path.
As the usage is in different places perhaps the parameter solution is easier in realization and usage.
So a general approach to change the paths without options is wrong in my opinion.

Actions #9

Updated by Rémy DANIEL over 6 years ago

  • Related to Bug #82486: IncludeJS* / includeCSS* (including compression / concatenation) ignoring absRefPrefix added
Actions #10

Updated by Riccardo De Contardi about 6 years ago

  • Related to Bug #83630: Config.absRefPrefix not working anymore for includeCSS, includeJs, includeJSLibs, includeCSSLibs after update to 8.7.9 added
Actions #11

Updated by Oliver Hader about 6 years ago

  • Related to deleted (Bug #83630: Config.absRefPrefix not working anymore for includeCSS, includeJs, includeJSLibs, includeCSSLibs after update to 8.7.9)
Actions #12

Updated by Riccardo De Contardi over 4 years ago

I tried to repeat the test reported on #82486 on a 9.5.10 TYPO3 installation, i.e.

1) TS Setup

config {
  absRefPrefix = /foo/
  compressJs = 1
}

page = PAGE
page {
  10 = TEXT
  10.value = HELLO WORLD!
  # setting a link to test if absRefPrefix works
  10.typolink.parameter = 1

  includeJSLibs.js1 = fileadmin/js1.js
  includeJSLibs.js2 = fileadmin/js2.js

  includeCSS.css1 = fileadmin/css1.css
  includeCSSLibs.css1 = fileadmin/css1.css
}

Results:

The files are prepended with the /foo prefix:

<link rel="stylesheet" type="text/css" href="/foo/fileadmin/css1.css?1571951025" media="all">
<link rel="stylesheet" type="text/css" href="/foo/fileadmin/css1.css?1571951025" media="all">

<script src="/foo/typo3temp/assets/compressed/js1-073ad306084932e4f6f8cc94ecc220df.js?1571951083" type="text/javascript"></script>
<script src="/foo/typo3temp/assets/compressed/js2-5902d8a0726c46b4d9e425058757d08c.js?1571951083" type="text/javascript"></script>

while the HELLO WORLD! link is not (ID=1 is my homepage, but the result does not change with choosing another page):

<a href="/">HELLO WORLD!</a>
Actions #13

Updated by Riccardo De Contardi over 4 years ago

  • Related to Bug #82574: Inconsistent support of config.absRefPrefix in fluid/extbase added
Actions #14

Updated by Marc Hirdes over 3 years ago

Any workaround? I really need this. A customer imports the HTML and needs absolute paths.

Actions #15

Updated by Benni Mack over 2 years ago

  • Status changed from New to Needs Feedback

The original issue is solved with TYPO3 v11.5, as we use a PSR-14 to apply absRefPrefix to all FAL objects directly. Anything else here?

Actions #16

Updated by Riccardo De Contardi over 1 year ago

  • Status changed from Needs Feedback to Closed

No feedback since the more than 90 days => closing this issue.

If you think that this is the wrong decision or experience the issue again and have more information about how to reproduce your problem, please reopen it or open a new issue with a reference to this one.

Thank you and best regards

Actions #17

Updated by Riccardo De Contardi over 1 year ago

  • Target version deleted (Candidate for patchlevel)
Actions

Also available in: Atom PDF