Bug #97324
closed
CSS / JS files not referenced correctly when concatenation and compression are disabled
0%
Description
After updating a site from TYPO3 10.4 to 11.5.8 I encountered following problem:
The frontend of subpages from level 2 got messed up, because CSS and JS files were not referenced correctly (loading those files resulted in a 404 error).
Example TypoScript setup in order to reproduce the error:
config.minifyCSS = 0 config.concatenateCss = 0 config.compressCss = 0 config.minifyJs = 0 config.concatenateJs = 0 config.compressJs = 0 page.includeCSS.mycss = fileadmin/mycss.css page.includeJS.myjs = fileadmin/myjs.js
In TYPO3 11.5 the CSS and JS files are referenced like this:
<link rel="stylesheet" type="text/css" href="fileadmin/mycss.css">
<script src="fileadmin/myjs.js?1570519026"></script>
Whereas in TYPO3 10.4 they were referenced with a prepending slash:<link rel="stylesheet" type="text/css" href="/fileadmin/mycss.css">
<script src="/fileadmin/myjs.js?1570519026"></script>
So on subpages like https://www.domain.xy/page-1/subpage-1-1/ the references lead to a 404 error.
Setting config.absRefPrefix = / (or any other values) in TypoScript does not help.
However it works when config.baseURL is set, but that is deprecated.
Also, the problem does not exist as soon as config.concatenateCss = 1 or config.compressCSS = 1 are set (JS respectively), because in that case the references look like " /typo3temp/assets/compressed... "
Updated by Marco Kuprat over 2 years ago
- Project changed from 9 to TYPO3 Core
- TYPO3 Version set to 11
- PHP Version set to 7.4
Updated by Česlav Przywara over 2 years ago
A bit off topic: where did you get that config.baseURL is deprecated?
Looking at 11.5 docs, I don't see any deprecation being mentioned: https://docs.typo3.org/m/typo3/reference-typoscript/11.5/en-us/Setup/Config/Index.html#baseurl
Updated by Marco Kuprat over 2 years ago
That's right, "deprecated" is the wrong wording.
But with the possibility of site management since TYPO3 9 there's normally no need for config.baseURL anymore.
My frontend was OK without config.baseURL when the site was running TYPO3 10.4. But after the upgrade to TYPO3 11.5 it crashed and I regard setting config.baseURL as workaround.
Of course, you could also add preceding slashes to page.includeCSS and page.includeJS in order to solve the problem.
But on the other hand I don't see a requirement for that in the docs.
So, all in all I regard this as a bug or at least missing documentation.
Updated by Arne Bracht over 1 year ago
- Related to Bug #99135: page.includeCSS with resource from fileadmin, the beginning slash is missing TYPO3 11.5.19 added
Updated by Knut E. about 1 year ago
A bit off topic: where did you get that
config.baseURLis deprecated?
deprecated in TYPO3 Version 12.1
so the question for me what to do: the effect ist still in TYPO3 11.5.26: Add a Slash at the beginning of the files or is there another solution?
Updated by Knut E. about 1 year ago
a possible Solution via site:base from siteconfiguration
page = PAGE
page.headTag.append = TEXT
page.headTag.append.dataWrap = <base href="{site:base}">
Updated by Riccardo De Contardi 12 months ago
Knut E. wrote in #note-6:
so the question for me what to do: the effect ist still in TYPO3 11.5.26: Add a Slash at the beginning of the files or is there another solution?
Is there a reason not to write directly:
page.includeJS.myjs = /fileadmin/myjs.js
?
Updated by Riccardo De Contardi 12 months ago
- Related to Bug #82574: Inconsistent support of config.absRefPrefix in fluid/extbase added
Updated by Garvin Hicking about 3 hours ago
- Status changed from New to Closed
I'm closing this issue because with TYPO3v12 the asset locations changed to EXT:xxx notation, which resolve files differently. The old direct approach to including files then should utilize absolute paths from the document root to work properly, but it is recommended to use a sitepackage for containing assets and getting them referenced. Additionally, some other workarounds have been posted here which might work for others.
To foster this adoption, changing the "old" functionality is very unlikely at this point, so I hope you can understand for cleanup reasons that this issue got closed.