Bug #85297
closed
Breaking: TypoScript setup is overwritten
Added by David Bruchmann almost 6 years ago.
Updated about 5 years ago.
Description
Having in setup two definitions to include anything, only one is accepted, the other one is overwritten if the variables are written nested:
page {
includeCSS{
jquery = ....
}
}
page {
includeCSS{
sortable = ....
}
}
In this notation only `sortable` is loaded, that means the notation is really handled like arrays, where a new `page {` is overwriting the whole page-configuration.
If I note it like this it's accepted:
page.includeCSS.jquery = ...
page.includeCSS.sortable = ...
I can't remember having had this behavior in earlier versions and I consider this as BUG and suppose it will corrupt many existing configurations.
btw: using the most recent version 9.3
you've got to be kidding me. thanks for finding this one!
will test ASAP.
- Status changed from New to Needs Feedback
can't reproduce.
This works for me:
page {
includeCSS {
jquery = https://code.jquery.com/jquery-3.3.1.js
}
}
page {
includeCSS {
backend = typo3/sysext/backend/Resources/Public/JavaScript/backend.js
}
}
Did you try to include one part by
<INCLUDE_TYPOSCRIPT: source="...">
?
My current scenario is that I've a sitepackage and I never use the setup-field in the BE-templates but include only my template from sitepackage.
In that file I include more files but have some setup too.
In that combination I get some values overwritten.
A similar fault has been discovered and is available here: https://typo3.slack.com/archives/C025BQLFA/p1529333764000650
I copy the text from there:
hello channel! I got something crazy with the includeJSLibs and includeJSFooterlibs:
Fontawesome-Include did'nt work:
includeJSLibs {
100 = {$settings.resources}/Public/3rdParty/jquery/jquery-3.2.1.min.js
150 = {$settings.resources}/Public/3rdParty/font-awesome/fontawesome-free-5.0.13/fontawesome-all.min.js
}
includeJSFooterlibs {
150 = {$settings.resources}/Public/3rdParty/popperjs/popper-1.12.3.min.js
200 = {$settings.resources}/Public/3rdParty/bootstrap/bootstrap-4.1.0-dist/js/bootstrap.min.js
}
Fontawesome-Include works:
includeJSLibs {
100 = {$settings.resources}/Public/3rdParty/jquery/jquery-3.2.1.min.js
151 = {$settings.resources}/Public/3rdParty/font-awesome/fontawesome-free-5.0.13/fontawesome-all.min.js
}
includeJSFooterlibs {
150 = {$settings.resources}/Public/3rdParty/popperjs/popper-1.12.3.min.js
200 = {$settings.resources}/Public/3rdParty/bootstrap/bootstrap-4.1.0-dist/js/bootstrap.min.js
}
[comment by me: look at the numbers in the array]
It looks like the array get an override by includeJSFooterlibs - Is someone able to reproduce this?
While I could not reproduce the initial error with the CSS, the JavaScript issue seems valid.
CSS issue:¶
I tested adding the CSS like you mentioned above, even with <INCLUDE_TYPOSCRIPT: source="DIR: ./lib" extensions="typoscript">
But in my case, all stylesheets were loaded in the frontend.
JavaScript issue:¶
This issue I was able to reproduce on current master:
page {
includeJSLibs {
100 = EXT:basetemplate8/Resources/Public/JavaScript/jquery.min.js
}
includeJSFooterlibs {
100 = EXT:basetemplate8/Resources/Public/JavaScript/three.min.js
}
}
The issue is not limited to using numbers for including the files.
As these issues are different from each other, I opened a new issue: #85353
- Related to Bug #85353: includeJSLibs gets overwritten by includeJSFooterlibs if same name is used added
JS (separate issue) is resolved now.
How about the CSS-issue mentioned here? Is that somehow reproducible? Any hints?
I think that this issue is solved on the latest master I tried the following test: on the latest master 9.5.1-dev:
1) create a couple of simple CSS files:
fileadmin/alpha.css
body{background:red;}
fileadmin/beta.css
body{font-size:50px;}
2) Write in TS Setup:
config.no_cache=1
page {
includeCSS{
alpha = fileadmin/alpha.css
}
}
page {
includeCSS{
beta = fileadmin/beta.css
}
}
Results: Both styles are applied¶
I also tried with:
config.no_cache=1
page {
includeCSS{
100 = fileadmin/alpha.css
}
}
page {
includeCSSLibs{
100 = fileadmin/beta.css
}
}
with the same results.
Do you think it is sufficient to consider this issue solved? Should I perform a different test?
still have it on my list.
Will test asap and give feedback.
I just tested it by myself because it got my attention....but so far everything works nice.
So I guess that's already fixed, I cannot reproduce it.
- Status changed from Needs Feedback to Closed
- Target version deleted (
Candidate for patchlevel)
@David Bruchmann I think that this issue could be safely closed now;
if you think that this is the wrong decision or experience the issue again, please reopen it or open a new issue with a reference to this one and a detailed step-by-step guide about how to reproduce it.
Thank you and best regards.
Also available in: Atom
PDF