TYPO3 Core

Hi E.I.,

thanks for your report. When does this happen? Would be nice, if you could provide some steps to reproduce.

Could you please explain, what the values are? Do you call render() without any parameters? It sounds reasonable, that we might not access or even unset probably non-existant array keys..

Can you provide a patch? Think checking for key_exists around the usage of $conf['value'] should suffer.

Thanks
Steffen

I updated from a working TYPO3 4.5.0beta2 to beta3 and got the same error in my logfiles.

To me it seems that the error is related to the extension ttnewsgenericmarkers - I uninstalled the extension and the frontend output was rendered properly. Just without all the custom markers.

PHP Version used is 5.2.16.

Christian, could you add your IP address to the devIPmask in the Install Tool? Then you get a stack trace, which tells you, which exception called this method.

I did as you suggested but instead of a stack trace I still do get the completely blank output and the same errors in the logfile. Do you have any other suggestions how I could help finding the cause of this issue?

What's the value of displayErrors? Please change to 1

It happens, when there is no "value" key in a TEXT Element.

Attached patch fixes that.

I'm not a php developer but I tried the patch and it didn't solve the issue. tt_news generic markers seems to be the cause, everything works after removing that extension.

I can confirm that the attached patch did not solve the issue. Only removing ttnewsgenericmarkers does. I should not have been using it anyway since I already used tt_news 3.0.1.

Steffen, I followed all your instructions but did not get any hint on what was the cause for that fatal error.

The issue should be fixed though since many people might still be using older tt_news versions where there was a need of installing ttnewsgenericmarkers in order to get custom markers in news templates.

Can you give us the TS setup you hand over via ttnewsgenericmarkers?

There you go, Jo.

Got it now - This seems to be a bug in ttnewsgenericmarkers, since it does render each key twice.

foreach($conf as $key=>$value) {
$key2 = trim($key, '.');
$markerArray['###GENERIC_'.strtoupper($key2).'###'] = $pObj->cObj->cObjGetSingle($conf[$key2] , $conf[$key] );
}

This would result in two calls for a TEXT element like that:

news_title = TEXT
news_title {
field = generic_short // generic_title
wrap = |
}

First key is "news_title", so the function call would be:
cObjGetSingle('TEXT', 'TEXT')

Second key is "news_title.", so the function call would be:
cObjGetSingle('TEXT', array('field' => 'generic_short // generic_title','wrap' =>'|'))

The second call would be OK, but the first one would hand over a string as an array, which runs into problems with TEXT elements, because we are using unset() there.

So first of all, ttnewsgenericmarkers should change this behaviour.
Second someone should check current tt_news to avoid this kind of behaviour.
Third we should introduce an is_array() check to the TEXT element as well.

What do you think?

Since this might happen with other elements as well, maybe the is_array(check) should be introduced on a lower level, so that each Element class doesn't have to care about it.

That would be a good and backwards compatible solution, Joey.

Attached a patch that introduces type casting to the new tslib_content_xxx classes. The rest of the functions and classes stays untouched to stay backwards compatible.

Please test it and report the results here!

I've attached a v3, which is very similar to v1 and should not cause other side effects.

I guess this is still valid and needs to be resolved in 4.5.x?

Yes, I think so

A little workaround:

plugin.tt_news.genericmarkers {
link = COA
link.10 = TEXT
link.10 {
value = Important link
typolink.parameter = www.typo3.org
}
}

Committed to
trunk in rev. 10535 and
4-5 in rev 10534