Bug #16179
closedFatal error with flexform fields in a database.
0%
Description
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:
<T3FlexForms>
<data>
<sheet index="sDEF">
<language index="lDEF">
<field index="field_pricingsection">
<el index="el">
<section index="1">
<itemType index="field_pricingcontainer">
<el>
<field index="field_category">
<value index="vDEF">13</value>
</field>
<field index="field_price">
<value index="vDEF">0</value>
</field>
</el>
</itemType>
</section>
</el>
</field>
</language>
</sheet>
</data>
</T3FlexForms>
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:
<T3FlexForms>
<data>
<sheet index="sDEF">
<language index="lDEF">
<field index="field_pricingsection">
<el index="el">
</el>
</field>
</language>
</sheet>
</data>
</T3FlexForms>
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)
Files
Updated by Morten Hansen over 18 years ago
one quick solution would be to change line 1947 from:
if (is_array($dataValues[$key]['el'][$ik][$theKey]['el'])) {
to:
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?
Updated by Bernhard Kraft over 18 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.
Updated by Ernesto Baschny over 18 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?
Updated by Dmitry Dulepov over 18 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.
Updated by Jean-David Gadina over 17 years ago
Any news about this bug?
I've tested Morten's solution and it's working well...
Updated by Nikolas Hagelstein over 17 years ago
Yes same over here solution works.
Updated by Kasper Skårhøj almost 17 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.