Project

General

Profile

Actions

Bug #16179

closed

Fatal error with flexform fields in a database.

Added by Morten Hansen almost 18 years ago. Updated almost 16 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2006-05-24
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.0
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

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

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #16381: DB Check cron produces errorsClosedDmitry Dulepov2006-07-20

Actions
Has duplicate TYPO3 Core - Bug #17467: Fatal error with flexform fields in a database.ClosedOliver Hader2007-07-12

Actions
Actions #1

Updated by Morten Hansen almost 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?

Actions #2

Updated by Bernhard Kraft almost 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.

Actions #3

Updated by Ernesto Baschny almost 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?

Actions #4

Updated by Dmitry Dulepov almost 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.

Actions #5

Updated by Jean-David Gadina almost 17 years ago

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

Actions #6

Updated by Nikolas Hagelstein over 16 years ago

Yes same over here solution works.

Actions #7

Updated by Michael Stucki over 16 years ago

Fixed in TYPO3 4.1.3 and later.

Actions #8

Updated by Kasper Skårhøj about 16 years ago

Faulty implementation

Actions #9

Updated by Kasper Skårhøj about 16 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.

Actions

Also available in: Atom PDF