field.inline.fal causing errors in 7.6

[vickygr89]

When adding an image we got a 500 error on save. And then in the Error Log we see the following:

Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1446996319: Configuration retrieved from FlexForm is incomplete or not of type "inline". | UnexpectedValueException thrown in file /home/typo3_src/7.6latest/typo3/sysext/backend/Classes/Controller/FormInlineAjaxController.php in line 811. Requested URL: http://www.-------.stwdev.com/typo3/index.php?ajaxID=%2Fajax%2Frecord%2Finline%2Fcreate&ajaxToken=b1af04b81ba878c7cc40ba1dd13e8727b3ec8bbc

We pulled the latest flux from GIT and got same results.

[MajPay]

I can confirm that, to debug you can copy the ajax link as cURL, call it via cli and dump the values there, FormDataCompiler::compile (FormInlineAjaxController::90) does not return a correct array, if you dump its values php wont do anything.

Maybe some hook, that adds the flexform dynamically based on the fluidcontent template is not called anymore. The debug_backtrace got pretty simple, so the callstack reduced in 7.6

I guess you have to XCLASS FormInlineAjaxController to invoke the Flexform generation....

kind regards

[MajPay]

DynamicFlexForm Hook is invoked too late, so the flexform does not exist.

[MajPay]

Na, wrong - the hook gets invoked.

I think i found the issue here: https://forge.typo3.org/issues/70918

[stwsimon]

Had a look at the changeset produced in that issue, changes are already in place though (so issue still exists despite fix in that issue).

[cweiske]

This is either https://forge.typo3.org/issues/71436 or https://forge.typo3.org/issues/68045, which don't have working fixes yet.

[Marc-Bauer]

https://forge.typo3.org/issues/71564#change-286540

could that the problem?

[NamelessCoder]

Just a quick note:

https://forge.typo3.org/issues/71564#change-286540 is only related insofar the same structure expressed as an array also results in the same problem (which I don't think it does?)

https://forge.typo3.org/issues/71436 would be relevant in particular when combined with fluidcontent_core which adds a second flex type and thus a second DS. It would likely cause one of the fields to fail but I can't say which it would be (and that might depend on the TCA showitems listing order, too).

https://forge.typo3.org/issues/68045 I haven't investigated in detail but yes, it appears very relevant - and I'm afraid I have no suggested solutions since I don't know if this is an actual bug or intended changes to the API. There seems to be some of those in 7.6.

[MajPay]

Using that patch: https://review.typo3.org/#/c/44914/ I can use fal relations (IRRE) in other flexforms (without the patch IRRE in flexforms is generally broken). It still does not work with flux:field.inline.fal though.

[Torsten85]

I really hope that this issue is resolved soon. This is keeping me from using 7.6.

[MajPay]

Patch set 2 does not work neither, i think the error must be located in flux. The flexFormPath trying to be resolved is

sDEF/lDEF/{fieldName}/vDEF -> Looks correct

The FlexForm structure received by flux is kind of ds/sheets/sDEF/ROOT/el/info

It gets resolved until ds/sheets/sDEF, then the key wallpaper is missing and leads to NULL as configuration. Event if i assign the el key manually it fails because the type is not "linline" - its "user".

Is there some kind of abstraction in flux? That would have to be resolved earlier or maybe removed and the final flexform needs to be cached rendered.

When debugging DynamicFlexForm::getFlexFormDS_postProcessDS $dataStructArray in first line = empty pi_flexform config.

After processing Providers i can not debug the var anymore, php gives up upon recursion.

There is only one Provider -> FluidContent/ContentProvider that calls Flux/AbstractProvider::postProcessDataStructure

So okay, there the flexform is being built. At that point DataStructure needs to be adopted correctly - what does not happen at the moment (7 LTS) i guess.

When debugging Sheet:getFields only "info" is returned.

Confusing architecture, need a break.

[monosize]

I tested also patch https://review.typo3.org/#/c/44914/

The problem is that the correct 'config' is missing in $parentConfig. see at line 93 in typo3/sysext/backend/Classes/Controller/FormInlineAjaxController.php

 $parentData = $formDataCompiler->compile($formDataCompilerInputForParent);
 $parentConfig = $parentData['processedTca']['columns'][$parentFieldName]['config'];

The formDataCompiler can extended with dataProviders. May be we can do a workaround to overwrite the pi_flexform config field. The dataProviders are stored in:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']['formDataGroup']['inlineParentRecord']

look here: https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/backend/Classes/Form/FormDataGroup/InlineParentRecord.php#L37

Here is my workaround based on patch https://review.typo3.org/#/c/44914/:
I change in File typo3/sysext/backend/Classes/Controller/FormInlineAjaxController.php at line 106:

if ($parentConfig['type'] === 'flex') {
    // Workaround 'inline' error: if list_type is empty then we use the $parent['config']
    if (TRUE === empty($databaseRow['list_type'])) {
        $parentConfig = $parent['config'];
    } else {
        $parentConfig = $this->getParentConfigFromFlexForm($parentConfig, $domObjectId);
    }
}

It uses the config from the ajax arguments. Is that secure? For the moment it works for me ;-)

[NamelessCoder]

@monosize I think you're on the right track but we need to determine why getParentConfigFromFlexForm fails on this - that's the method that consults the data structure and for some reason considers the data structure we deliver, somehow invalid.

[monosize]

@NamelessCoder getParentConfigFromFlexFormfails, cause it fetches data from $parentConfig and $parentConig has wrong data.

What about the 'flexDataStructurePointers' in the ajax request stored in 'context',
there are only two parameters: see Screenshot:

Is here the field 'tx_fed_fcefile' missing?

['config']['ds']['meta']['dataStructurePointers']

[monosize]

@NamelessCoder the missing dataStructurPointers is definitely the problem!

I'm preparing a bugfix. ( works only with patch https://review.typo3.org/#/c/44914/)

[MajPay]

When doing something like this (attached files) it works for new and existing elements (based on patch 44914)

Sorry for the images, this is just a quick&dirty hotfix, that i need right now :-)

But the idea could be right... add the flux information to the field definition, it is added to the ajax request and can be evaluated in the Hook.... .

AbstractFormField::prepareConfiguration

DynamicFlexForm::getFlexFormDS_postProcessDS

kind regards

[NamelessCoder]

@MajPay Thanks for the examples - and yes that would indeed cheat its way around the issue. But what we really need is for the TYPO3 core to (re-)load records from the database when the $row or $result['databaseRow'] arrays only contain the UID. Flux is not the only feature having severe problems over this - anyone using IRRE in any FlexForm has trouble; DCE, Gridelements, etc.

[NamelessCoder]

Everyone: please don't misunderstand the apprehension in accepting any of the suggested patches just yet. The reason for that is:

Rather than implementing a workaround that hides the issue, we sincerely think this has to be solved in the TYPO3 core (because it is both technically and in effect, a regression, although it isn't labeled as such). We do care that our users don't have TYPO3 explode in their faces when they upgrade to the most recent version and use Flux - but we also have to first of all maintain the solutions that get applied here, secondly make sure that they don't ruin things when TYPO3 fixes the regression. In this case we expect the problem to be solved in the very next version of TYPO3 LTS because it has the potential to affect so many users, has received great attention in the core bug tracker and is already under review.

Because you guys all use Flux you expose many more regressions and bugs than other users do. Part of that reason can be found in how difficult it actually is to create a proper FlexForm as XML and no less to have it contain an IRRE definition with all properties being valid. The TCA required is already quite big and expressed as XML it gets even worse. So while IRRE in FlexForms is pretty commonplace in Flux, it is quite rare in other extensions because of the crazy API w/o Flux. And this, unfortunately, leads to regressions being more likely to slip through - and reach you in something as vital as an LTS release.

That being said: please be patient with this one. It does not help to stress the TYPO3 contributors, nor does it help to complain to us in the team (which I should mention, nobody has done so far - you've all been very understanding and I appreciate that!). It helps to:

1. Vote on the reviews in the Gerrit system even if it is just a +1.
2. Help test the solutions submitted for review on Gerrit - it's not always easy to do but you should keep in mind that if the patch works, you've solved the problem locally and can use that (at your own risk) in any production sites.
3. Keep suggesting ways this can be hotfixed via Flux. Other users will benefit from that even if we choose not to merge any of them.
4. Keep calm, use master branch of TYPO3 - and git pull often.

Thanks - and keep being awesome ;)

[julianxhokaxhiu]

Any update on that? I'm still pulling from Typo3 git but it seems that it's still not working :\

Just did it right now and still 500 Internal server error on upload.

EDIT: Tested this pull request ( https://github.com/FluidTYPO3/fluidcontent/pull/321 ) and it's finally working! I think guys you should merge it.

[NamelessCoder]

@julianxhokaxhiu We absolutely want the core to fix this regression, we are not the only ones affected.

[julianxhokaxhiu]

Any idea on which other patch we have to follow until it's merged?

[NamelessCoder]

More information about the issue:

• http://p.cweiske.de/270 was suggested, confirmed to fix the problem - but was rejected; it was set to fix https://forge.typo3.org/issues/71436 which is currently marked as resolved but has had reports that indeed, the exact same problem exists on a completely vanilla flexform source. Morton writes he will be testing this tonight (Dec. 9th): https://forge.typo3.org/issues/71436#note-18.
• https://review.typo3.org/#/c/44914/ indicates it solves the Forge issue above, but I would disagree with that assessment - the ajax initiated controller instance clearly still receives an "uid-only" databaseRow. Additionally, I am not so sure that missing the "element type: array" attribute in the DS is relevant, but this could very well be yet-another-quirk of DS handling.

[jkphl]

We can confirm that the release of 7.6.1 fixes the issue for us at least with vanilla plugins / flexforms. However, with fluidcontent elements / flexforms we still don't have any luck (none of the patches and workarounds seriously work so far, at least not for us; FAL record can be added but get's lost when saved). So, is there an official TYPO3 bug report one could follow? Which one?

[MarkusBausK]

Same here (no error 500 but FAL is lost after saving) with 7.6.1, dev branch of fluidcontent and flux and using this fix on top: https://github.com/monosize/fluidcontent/blob/3556fe61f996fc0eec7e02e91b9c3a50071073b3/Classes/Provider/ContentProvider.php

[monosize]

@MarkusBausK you using the wrong fix

Test it with this one: monosize/fluidcontent@3556fe61f996fc0eec7e02e91b9c3a50071073b3 From branch dspointer : https://github.com/monosize/fluidcontent/commits/dspointer still working with 7.6.2 and the latest FluidTYPO3 extensions

[MarkusBausK]

With 7.6.1 and the new fix nothing changes. I guess I have to update to 7.6.2

[bastiwasni]

Sorry to say but, I downloaded the latest typo3 release (7.6.2) and installed the fluidcontent extension, which was provided by @monosize. Then I installed all other fluidtypo3 extensions via git (builder, fluidpages, flux, vhs). But in the end, I still get the "Error: 500 Internal Server Error". Did I miss something?

[monosize]

Here is an example of my working fluidcontent configuration.

<f:section name="Configuration">
    <flux:form id="test" options="{group: 'Element'}">
        <flux:form.sheet name="config" label="Config">
            <flux:field.inline.fal name="images" label="Images" minItems="1" maxItems="100" showThumbs="1" collapseAll="1" allowedExtensions="jpg,jpeg,png" foreignField="uid_foreign" foreignLabel="uid_local" foreignMatchFields="{fieldname:'image'}" foreignSelector="uid_local" foreignUnique="uid_local" foreignSortby="sorting_foreign" table="sys_file_reference" foreignTableField="tablenames"/>
        </flux:form.sheet>
    </flux:form>
</f:section>```

[julianxhokaxhiu]

Everyone that has a problem should merge this PR: https://github.com/FluidTYPO3/fluidcontent/pull/321 in their own Fluidcontent extension.

@NamelessCoder why cannot you just merge this MEANWHILE Typo3 core team fixes this bug definitely and later revert it if you consider this a dirty patch? I guess it's better than blocking everyone's work because Typo3 Core team still is not able to find a solution.

Here on Typo3 7.6 and 7.6.1 official releases, FAL Inline content elements are still working fine.

[monosize]

this commit in TYPO3/TYPO3.CMS@e6727c8e9ae4cb912bc2d59c79758fb32370641c resolves also the problem with described in #1033

[NamelessCoder]

Thanks @monosize for keeping track, testing, patching, reviewing, everything!

And thanks everyone for your patience.

[MajPay]

I just checked out the 7-6 branch (commit 2032a28929a30a17ee9054416ef85cd2945c0a98, so the change aa148716349692a8be100c5cd231aeff55e3d7b4 is included)

but i still fail when creating a new inline relation. (same error)

Can you really confirm this is working? My flux config:

<flux:form id="teasersSlide" options="{group: 'Slides', Fluidcontent: {sorting: 100}}">
    <m:field.inline
        name="teasers"
        useSortable="1"
        enabledControls="{dragdrop : '1', sort : '1'}"
        minItems="1"
        maxItems="20"
        table="tx_xxx_domain_model_teaserslideelement"
        />
</flux:form>

Other versions:

{
"fluidtypo3/fluidcontent" : "^4.4",
"fluidtypo3/fluidpages" : "^3.4",
"fluidtypo3/flux" : "^7.3"
}

[monosize]

~~It works only for flux:field.inline.fal and only with monosize/fluidcontent@3556fe6 Maybe I have time after Christmas to analyse the problem with other inline combinations. Please open new issue.~~

[monosize]

@MajPay Sorry, I have done a wrong test! It works with monosize/fluidcontent@3556fe6 ;-)

tested with

<flux:form id="test" label="Test" options="{group: 'Element'}">
    <flux:field.inline
        name="test"
        useSortable="1"
        enabledControls="{dragdrop : '1', sort : '1'}"
        minItems="1"
        maxItems="20"
        table="sys_note"/>
</flux:form>

[kersten]

I don't know if this has something todo with this issue, but after applying the patch, selecting an image works. But when I save the element, the fal element is empty again and the image was not saved.

[edrush]

Hi,

it's a core problem, right? The problem still exists within our TYPO3 7.6.2 installation. I also checked out master which gave me a blank backend, I did not not go deeper. I then took checked out TYPO3 _7-6-2 again and cherry-picked the mentioned https://github.com/TYPO3/TYPO3.CMS/commit/e6727c8e9ae4cb912bc2d59c79758fb32370641c, problem still exists.

Error message is still "Configuration retrieved from FlexForm is incomplete or not of type "inline". I confirm the debugging output as Felix: "$parentConfig in FormInlineAjaxController->getParentConfigFromFlexForm does not contain my actual flexform" (https://forge.typo3.org/issues/70918, seems to be the same problem, right?).

So it does not seem to depend on the Flexform content itself.

However, it works when I first save the new Grid element and then add a relation (in my case an image, popup appears, I select an image and it is added to my Grid element). see below

Any help would be very much appreciated!

[edrush]

Hi,

also checked out (instead of cherry-picking) https://github.com/TYPO3/TYPO3.CMS/commit/e6727c8e9ae4cb912bc2d59c79758fb32370641c - no luck...

[cweiske]

@edrush: For us it works with the patch by @monosize AND the typo3 core patch by andreas wolf.

[edrush]

@cweiske Thank you, but no luck for us, we do not use fluidcontent, and the core patch did not help, too. Still, the FormInlineAjaxController->createAction() has too little information.

Plus, if I create the grid element element and save it first as I mentioned before, I can then add relations, but the frontend shows the error: Supplied file object type TYPO3\CMS\Core\Resource\Folder must be File or FileReference.

As far as I understand this discussion is a Flux issue but concerns a core issue, right?

[NamelessCoder]

As far as I understand this discussion is a Flux issue but concerns a core issue, right?

Correct. This issue only exists because we (FluidTYPO3 features) are affected by this core regression. The discussed PR is a patch that would work around the regression but only does anything for the Fluidcontent extension. The core patch status I'm not sure about, but last I checked, it solves only half of the issue (makes resolving DS work after the row is complete, but does not fix that the row is incomplete).

[NamelessCoder]

The issue is caused by something similar or identical to this being done:

https://github.com/TYPO3/TYPO3.CMS/commit/e6727c8e9ae4cb912bc2d59c79758fb32370641c#diff-c82da26b54aaaa447251eb8a9d1e9bcfR238

But seems a bit risky to patch in any way because of things like:

https://github.com/TYPO3/TYPO3.CMS/commit/e6727c8e9ae4cb912bc2d59c79758fb32370641c#diff-c82da26b54aaaa447251eb8a9d1e9bcfR251

There are several todos in the classes responsible for these things and it's likely this same fake database row procedure gets applied in other FormEngine components. Hope this helps someone with the available time to create patches for TYPO3.

[DenisMir]

So to sum up there is no solution for FAL images with flux untill the core bug is fixed?

[NamelessCoder]

So to sum up there is no solution for FAL images with flux untill the core bug is fixed?

We could go as far as to say there is no solution for FAL images with any FlexForm until the core bug is fixed.

[neufeind]

Until which core-bug (forge-issue?) is fixed? the ones mentioned here seem to be reesolved already?

[NamelessCoder]

@neufeind I'm not sure if there is a current issue - I haven't had time to properly check the issue tracker. If a new issue and patch has to be made, I think the two source code links above should be a good place to start.

[htuscher]

I also have no idea about the issue that is related to, but after trying various things yesterday, I can tell you that by using this patch http://p.cweiske.de/270 and this patch https://github.com/FluidTYPO3/fluidcontent/pull/321/files I could get as far as the backend still loads, I can add FAL relations to my contentelement, but all fields inside this inline element are marked as required by the form engine and I was not able to store the content element.

[daCyberpunk]

For me also this worked: patch by @monosize AND the typo3 core patch by andreas wolf.

[bastiwasni]

Works for me aswell :+1: Is there any update that the core devs will use the patch by andreas wolf to become official?

[webdev2027]

Works! But I hope it will be fixed at TYPO3 7.6.3 or fluidcontent 4.4.1 ... or both. Thanks to all for your help! (my stackoverflow link

[uscreenFikret]

@daCyberpunk Works thanks! And i hope also it will be fixed, Thanks

[kimchristiansen]

Seems still not working in TYPO3 7.6.3.