Bug #16179

Fatal error with flexform fields in a database.

Added by Morten Hansen over 13 years ago. Updated over 11 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


I have been able to produce this fatal error:

Fatal error: Cannot use string offset as an array in /home/www/cms/typo3_src-4.0/t3lib/class.t3lib_tcemain.php on line 1950

And I think it is a bug in the way the typo3 core handles the flexforms.

I have some events with a flexform field used to link price categories with a specific price in the specific event.

The XML data saved in this field could be this:

<sheet index="sDEF">
<language index="lDEF">
<field index="field_pricingsection">
<el index="el">
<section index="1">
<itemType index="field_pricingcontainer">
<field index="field_category">
<value index="vDEF">13</value>
<field index="field_price">
<value index="vDEF">0</value>

Then if I delete this element (consisting of a price category and a price), it only deletes this element not the section called field_pricingsection.
I think this is quite logical since it can delete the section unless it knows that there is not any other elements left in the section. The resulting XML is this:

<sheet index="sDEF">
<language index="lDEF">
<field index="field_pricingsection">
<el index="el">

Now, the issue arises when I try to create a price category and price relation again (like the first shown XML)

The error arises because typo3 can see that there is a section (it was not deleted when the last element was deleted), and then it accesses the content of this without checking that there is some content there.

/home/www/cms/typo3_src-4.0/t3lib/class.t3lib_tcemain.php on line 1950

I am not an expert in flexforms handling, but one solution would be to include a check for existing elements in dataValues_current around line 1950 in tcemain class.

(issue imported from #M3552)

bug_3552.diff View (899 Bytes) Administrator Admin, 2007-07-07 00:50

Related issues

Related to TYPO3 Core - Bug #16381: DB Check cron produces errors Closed 2006-07-20
Duplicated by TYPO3 Core - Bug #17467: Fatal error with flexform fields in a database. Closed 2007-07-12

Associated revisions

Revision a2ce0382 (diff)
Added by Xavier Perseguers about 9 years ago

Fixed bug #16179: 1-2-3 install tool wizard does not let DBAL load early enough

git-svn-id: https://svn.typo3.org/TYPO3v4/Extensions/dbal/trunk@39699 735d13b6-9817-0410-8766-e36946ffe9aa


#1 Updated by Morten Hansen over 13 years ago

one quick solution would be to change line 1947 from:

if (is_array($dataValues[$key]['el'][$ik][$theKey]['el'])) {


if (is_array($dataValues[$key]['el'][$ik][$theKey]['el']) && is_array($dataValues_current[$key]['el']) && is_array($dataValues_current[$key]['el'][$ik][$theKey]['el'])) {

Does anybody know if this will be enough?

#2 Updated by Bernhard Kraft over 13 years ago

I will send the attached patch to the core list - It is enough to check for $key|el as when this one is an array all subkeys will be available.

#3 Updated by Ernesto Baschny over 13 years ago

Call me crazy, but isn't this related to the #3840 which a user complained that hasn't been resolved in 4.0.1-rc1, while already marked as resolved in the bug tracker?

#4 Updated by Dmitry Dulepov over 13 years ago

Ernesto, this is not related though appear similar. Cause of error is different: Tobias tried to delete/move container element outside of section.

#5 Updated by Jean-David Gadina over 12 years ago

Any news about this bug?
I've tested Morten's solution and it's working well...

#6 Updated by Nikolas Hagelstein about 12 years ago

Yes same over here solution works.

#7 Updated by Michael Stucki about 12 years ago

Fixed in TYPO3 4.1.3 and later.

#8 Updated by Kasper Skaarhoj almost 12 years ago

Faulty implementation

#9 Updated by Kasper Skaarhoj almost 12 years ago

This implementation makes editing of flexforms (the new drag'n'drop based one) fail seriously. However, it's just not that incompatibility, but generally that the fix is really poor conceptually.
What is done is, that you simply don't traverse the data of a new flexform just because some secondary data is not present. If you analyse the code you can see that the main driver of the traversal is the submitted content, not the current (which is of course non-existent in case of a new record) and why wouldn't you like to traverse all the submitted content? Thats the whole idea here.
I will remove the bad implementation and make a check like this instead:

is_array($dataValues_current[$key]['el'][$ik]) ? $dataValues_current[$key]['el'][$ik][$theKey]['el'] : array(),

a few lines further down. I don't know if that will solve this issue since I don't have it, but that is the only case where I can imagine that a PHP error would occur.

Also available in: Atom PDF