[TYPO3-english] COA always true when used in if.isTrue.cObject?

[tcrass]

Dear all,

I've observed some -- at least: to me -- quite puzzling behavior in my
Typo3 7.6 installation. Consider the following TypoScript:

lib.textWithContent = TEXT
lib.textWithContent.value = foo

lib.textWithoutContent = TEXT
lib.textWithoutContent.value =

lib.coaWithContent = COA_INT
lib.coaWithContent {
10 = TEXT
10.value = foo
}

lib.coaWithoutContent = COA_INT
lib.coaWithoutContent {
10 = TEXT
10.value =
}

page.10 = TEXT
page.10 {
value = This should be visible (TEXT)...
if.isTrue.cObject < lib.textWithContent
}

page.20 = TEXT
page.20 {
value = This should be invisible (TEXT)...
if.isTrue.cObject < lib.textWithoutContent
}

page.30 = TEXT
page.30 {
value = This should be visible (COA)...
if.isTrue.cObject < lib.coaWithContent
}

page.40 = TEXT
page.40 {
value = This should be invisible (COA)...
if.isTrue.cObject < lib.coaWithoutContent
}

I'd expect entries 20 and 40 of the page array to not show up in the
rendered page, but alas! here's what I get:

This should be visible (TEXT)...This should be visible (COA)...This
should be invisible (COA)...


Obviously, the empty COA object at lib.coaWithoutContent is considered
being not-empty in page.40.if.isTrue.cObject < lib.coaWithoutContent.

Any explanation?

Cheers --

Torsten

[Stephan Schuler]

Hey there!


tl;dr:

It's about caching.


The logical explanation:

TEXT is potentially cached, COA_INT is not.
Think about the second request. TEXT is supposed to not be recalculated but taken from cache. How can that depend on COA_INT, which might calculate differently compared to how it resulted during the previous request?


The technical explanation:

Wow, I'm old. Back in the days, there used to be something called the "TYPO3 Frontend Rendering Process".
Here it is:
https://buzz.typo3.org/uploads/media/TYPO3_Frontend_Rendering_Process_v1.5.pdf

TEXT is calculated on step 31 ("generate the page"), COA_INT as well as USER_INT are calculated on step 32 ("include non-cached objects").

Although that diagram is accurate for v4.1 and a lot of things have change since then, there's still a lot a lot of truth in that picture :).


The very technical explanation:

During step 31 of the previous diagram, all COA_INT and USER_INT sections are assumed as placeholder strings.
It's something like "<!--INT_SCRIPT.d41d8cd98f00b204e9800998ecf8427e--->"

See:
https://github.com/TYPO3/TYPO3.CMS/blob/7254650107f48732b963d5ef8c6838bdd02ff1bd/typo3/sysext/frontend/Classes/ContentObject/ContentObjectArrayInternalContentObject.php#L38

That's what goes to the cache: The string output of the cachable part of your website filled with a couple of those INT_SCRIPT placeholders.

During step 32, all INT scripts are finally executed and their placeholder are replaced by the per-request individual result.

So I assume the TypoScript "if" part just casts "<!--INT_SCRIPT.d41d8cd98f00b204e9800998ecf8427e--->" to true.


Regards,



Stephan Schuler
Softwareentwickler | netlogix Web Solutions

Telefon: [phone] - 0
E-Mail: ***@netlogix.de
Web: websolutions.netlogix.de



----------------------------
Case Study: 1&1-Vertriebspartnerportale – prämiertes Neos-Projekt
Lesen Sie, wie wir mit unseren Projektpartnern eine moderne, ausbaufähige Grundlage auf Basis von Neos CMS für den Betrieb der 1&1-Vertriebspartnerportale schaffen konnten und uns so den Neos Award Gold für herausragende Projekte sicherten. Mehr erfahren…https://websolutions.netlogix.de/referenzen/1und1
----------------------------




netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: [phone] - 0 | Fax: [phone] - 99
E-Mail: ***@netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Matthias Schmidt



________________________________________
Von: typo3-english-***@lists.typo3.org <typo3-english-***@lists.typo3.org> im Auftrag von tcrass <***@tcrass.de>
Gesendet: Dienstag, 6. März 2018 22:22
An: typo3-***@lists.typo3.org
Betreff: [TYPO3-english] COA always true when used in if.isTrue.cObject?

Dear all,

I've observed some -- at least: to me -- quite puzzling behavior in my
Typo3 7.6 installation. Consider the following TypoScript:

lib.textWithContent = TEXT
lib.textWithContent.value = foo

lib.textWithoutContent = TEXT
lib.textWithoutContent.value =

lib.coaWithContent = COA_INT
lib.coaWithContent {
10 = TEXT
10.value = foo
}

lib.coaWithoutContent = COA_INT
lib.coaWithoutContent {
10 = TEXT
10.value =
}

page.10 = TEXT
page.10 {
value = This should be visible (TEXT)...
if.isTrue.cObject < lib.textWithContent
}

page.20 = TEXT
page.20 {
value = This should be invisible (TEXT)...
if.isTrue.cObject < lib.textWithoutContent
}

page.30 = TEXT
page.30 {
value = This should be visible (COA)...
if.isTrue.cObject < lib.coaWithContent
}

page.40 = TEXT
page.40 {
value = This should be invisible (COA)...
if.isTrue.cObject < lib.coaWithoutContent
}

I'd expect entries 20 and 40 of the page array to not show up in the
rendered page, but alas! here's what I get:

This should be visible (TEXT)...This should be visible (COA)...This
should be invisible (COA)...


Obviously, the empty COA object at lib.coaWithoutContent is considered
being not-empty in page.40.if.isTrue.cObject < lib.coaWithoutContent.

Any explanation?

Cheers --

Torsten
_______________________________________________
TYPO3-english mailing list
TYPO3-***@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english

[tcrass]

Hi Stephan,

thank you for your detailed and instructive reply, in particular the
link to the rendering process chart. I'm sorry, though, you found my
example too long since I really tried to break down my actual problem
into a minimum working example, trying to use self-explaining object names.

Anyway, I'm not convinced that isTrue evaluates to true just due to some
placholder strings for non-cacheable objects since I get exactly the
same output when either

a) replacing the COA_INTs with plain COAs and/or
b) entirely removing the TEXT object from the supposedly empty COA(_INT).

(And yes, I did clear the cache after applying those changes... ;)

It seems that if.isTrue.cObject < some COA(_INT) always yields true, no
matter whether the content array is cacheable or not and/or does contain
anything at all.
So... is there any way to use COA(_INT)s in conditional typoscript
expressions and make decisions based on whether they render as empty or
non-empty string?

Cheers --

Torsten