PHP Warning: Illegal string offset 'data' in EXT:flux/Classes/Provider/AbstractProvider.php line 522

[ecentral-mk]

Hi,

i have a strange behaviour of my typo3 6.2.3 system after the update from flux (version 7.1.2) to flux (version 7.2.0).
If i try to copy and paste any page the following error message accoured:
#1: PHP Warning: Illegal string offset 'data' in EXT:flux/Classes/Provider/AbstractProvider.php line 522

On a fresh typo3 install the error dont exist.
Anyone else have problems like this?

---

I figured out a small patch, which works for me.
I changed the following lines in the function preProcessRecord in the file AbstractProvider.php:

    public function preProcessRecord(array &$row, $id, DataHandler $reference) {
        $fieldName = $this->getFieldName($row);
        $tableName = $this->getTableName($row);
        $fieldNameData = isset($row[$fieldName]['data'])?$row[$fieldName]['data']:false;
        $fieldNameDataOptions = isset($row[$fieldName]['data']['options']['lDEF'])?$row[$fieldName]['data']['options']['lDEF']:false;
        if (TRUE === is_array($fieldNameData) && TRUE === is_array($fieldNameDataOptions)) {
            foreach ($row[$fieldName]['data']['options']['lDEF'] as $key => $value) {
                if (0 === strpos($key, $tableName)) {
                    $realKey = array_pop(explode('.', $key));
                    if (TRUE === isset($row[$realKey])) {
                        $row[$realKey] = $value['vDEF'];
                    }
                }
            }
        }
    }

[ecentral-mk]

This issue only affected one system and couldn't be reproduce on an other system

[NamelessCoder]

Hi @ecentral - I think this one was fixed a few weeks back, we just never caught this issue as related. Thanks for reporting!

[b3nkai]

Hi,

the issue is not fixed. It can only be reproduce after flux update (in my case from 7.1.2 to 7.2.1). The problem is localized in tx_fed_page_flexform field. in 7.1.2, an empty flexform was save as a string. In 7.2.1, it's save as a NULL value.

So to reproduce the problem after a fresh install (and some created pages)

1. execute these queries :
   UPDATE pages set tx_fed_page_flexform = '' where tx_fed_page_flexform = null;
   UPDATE pages set tx_fed_page_flexform_sub = '' where tx_fed_page_flexform = null;
2. try to copy a page (created before execting step 1)

To fix the problem you should add an update script to execute these queries :

UPDATE pages set tx_fed_page_flexform = null where tx_fed_page_flexform = '';
UPDATE pages set tx_fed_page_flexform_sub = null where tx_fed_page_flexform_sub = '';

Or you can use the patch provided by @ecentral. I didn't test it be I suppose this works.

Regards

[b3nkai]

Humm, the SQL update solution fix the problem when copying pages but not for t3d import, which is currently broken.

The @ecentral patch do the job in both cases.

[NamelessCoder]

@b3nkai Would you mind confirming this using the development branch of Flux?

[b3nkai]

Yes, I was using the TER version (7.2.1). I tried to checkout the developement branch from github and the problem is the same.

You can try to make a t3d export of a page, import the t3d and you should see the error.

[bjo3rnf]

This is not related to #836 which was introduced much later, right? Or is it?

[NamelessCoder]

I'm afraid #836 is the most likely cause for this one. Before that point we returned an empty string. You may not be experiencing it due to SQL modes or manual schema changes to that field. Summa summarum: looks like we should return an empty string here or at the very least cast the return value to string when re-assigning the property in the record array.

[bjo3rnf]

We didn't return an empty string but an incomplete FlexForm. An empty string seems to be more appropriate though. But the original issue has been opened in March long before this patch?

[NamelessCoder]

TBH, not sure, just going from the only possible null value saved to DB. They may not be the same issue, but #836 would be able to cause a DB value that causes this. The original problem could simply be made worse/more frequent by the return-NULL patch. I'm thinking that to avoid this completely, casting the possibly NULL value to string in AbstractProvider right after doing cleanFlexFormXML should do the trick.

[bjo3rnf]

Agreed.

[bjo3rnf]

I directly pushed a commit to development branch. @b3nkai mind giving it a spin please? Thanks.

[b3nkai]

The PHP Warning is still present.

as before :

• copying a new page works fine
• copying an old page (created with flux 7.1.2) display the error
• importing a t3d display the error

[GuidoJansen]

I've got the same problem.
I updated Flux from a version I can't remembet while developing a site

I fetched development branch, which includes Björns's patch (c10359e..ff25425)

The problem still persists.
If I take ecentral's patch, the problem is fixed.

[sboettger]

NamelessCoder which commit fixes this issue? Having a look into the code I don't think it's fixed, if the problem belongs to non empty fields in the database ('' instead of null).

[bjo3rnf]

Hm. The return '';-patch seems to be no longer present? Has it been reverted?

Edit: nvm. There's something wrong with my local repo :/

[bjo3rnf]

The above bugfix is actually an adaption of @ecentral's patch. It shouldn't matter if the db value is NULL or an empty string in this case.

[sboettger]

confirmed. thanks :)