Bug #37988
closed
COA_INT in Fluid-Templates
Added by Alexander Wende almost 12 years ago.
Updated about 1 year ago.
Sprint Focus:
Stabilization Sprint
Description
I think this is a related bug to http://forge.typo3.org/issues/36820
Passing a coa_int object to a fluidtemplate cause
an <!--INT_SCRIPT output like wrapping a coa_int in another coa_int.
atm the fluid template has no partials...
Can anybody confirm?
10 = FLUIDTEMPLATE
10 {
file = {$filepaths.templatePath}{$filepaths.templatefile}
partialRootPath = {$filepaths.partialPath}
layoutRootPath = {$filepaths.layoutPath}
variables{
username = COA_INT
username.10 = TEXT
username.10.value = some username
}
}
Typo3 4.6.9
- Status changed from New to Needs Feedback
@Alexander: We've have a nifty patch in this area for TYPO3 CMS 6.0. Is this still reproducible for you with this core version?
No feedback for over 90 days.
- Status changed from Needs Feedback to Closed
I can confirm this in TYPO3 6.1.3 when using the cObject viewhelper.
lib.test = COA_INT
lib.test {
10 = TEXT
10.value = test
}
{f:cObject(typoscriptObjectPath: 'lib.test')}
leads to output like this:
@@
This is also happening in 6.1.5!
- Status changed from Closed to Accepted
- Target version set to 6.2.14
- Is Regression set to No
- Sprint Focus set to Stabilization Sprint
Can reproduce the problem. Should get fixed finally :)
- Status changed from Accepted to Needs Feedback
Christian Eßl wrote:
I can confirm this in TYPO3 6.1.3 when using the cObject viewhelper.
lib.test = COA_INT
lib.test {
10 = TEXT
10.value = test
}
{f:cObject(typoscriptObjectPath: 'lib.test')}
I cannot confirm this. Using the cObject view helper works like expected
It is important to not htmlencode the output of a COA_INT or USER_INT
The following code could be used in case the COA_INT is used as Fluid variable in TS
<f:format.raw>{username}</f:format.raw>
With that, everything works like expected.
- Status changed from Needs Feedback to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
- TYPO3 Version changed from 4.6 to 9
- PHP Version changed from 5.3 to 5.5
This issue not resolved for me...
in TS
lib.currentUidUserInt = COA_INT
lib.currentUidUserInt {
10 = TEXT
10.data = TSFE:fe_user|user|uid
}
In FLUID
{f:cObject(typoscriptObjectPath:'lib.currentUidUserInt') -> v:variable.set(name:'foo')}
here I get `UID` and it is works
{foo -> f:format.raw()}
But here I get problem
<f:if condition="{0:'{newsFeUser.0.uid}'} == {0:'{foo -> f:format.raw()}'}">
I get...
<!--INT_SCRIPT.747d1dced8da2c172a57e825026c429b-->
- % Done changed from 100 to 0
This is not resolved! The problem still exists in version 9.5.14
I also get INT_SCRIPT tags when I try to render content (RECORDS) via PageRenderer->addJsInline()..
TYPO3 9.5.19
This leads to stuff like:
"data":"{"foo":"bar"} after eventually being replaced (notice the quote after the colon as ot gets rendered as "<!-- INT_SCRIPT.." string first and then replaced while still being within quotes......
There were reports about v9.
I cannot reproduce in v9, v10 and current master with this snippet:
lib.coaInt = COA_INT
lib.coaInt {
10 = TEXT
10.data = date:U
}
page.1234 = FLUIDTEMPLATE
page.1234 {
template = TEXT
template.value (
coaInt: <f:cObject typoscriptObjectPath="lib.coaInt" />
)
}
It seems to depend on when Fluid allows the COA_INT-cObject to be rendered, i.e. when it still exists as "" and when the timestamp is in it.
Snippet:
page.1234 = FLUIDTEMPLATE
page.1234 {
variables {
timestamp = TEXT
timestamp.data = date:U
}
template = COA
template {
5 = TEXT
5.value (
timestamp: {timestamp}<br />
)
10 = TEXT
10.value (
coaInt: <f:cObject typoscriptObjectPath="lib.coaInt" /><br />
)
15 = TEXT
15.value (
"{f:cObject(typoscriptObjectPath:'lib.coaInt')}=={timestamp}" is
<f:if condition="{f:cObject(typoscriptObjectPath:'lib.coaInt')}=={timestamp}"><f:then>true</f:then><f:else><strong>false</strong></f:else></f:if>
)
}
Result:
timestamp: 1614173785
coaInt: 1614173785
"1614173785==1614173785" is false
(Tested with TYPO3 v10.4.13)
Hey.
Discussing on an issue that has been closed long ago does not raise much awareness to others.
If the issue still exists one way or the other, could you please open a fresh issue, maybe re-describing the issue and link to this issue as well?
Had the same issue with TYPO3 10.4 and used this to prevent Fluid from destroying the INT_SCRIPT marker:
{username -> f:format.raw()}
Kudos to TYPO3 legend @Ernesto Baschny!
Also available in: Atom
PDF