Project

General

Profile

Actions

Bug #100943

closed

TCA IRRE does not save, maybe if there are to many objects

Added by Johannes C. Schulz 9 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
Start date:
2023-06-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
8.1
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

After upgrading to TYPO3 11.5.x (from 9.x) my extension broke:

description:
A "year" can have "bands" (1:n) and "stages" (1:n) A "stage" can have "days" (1:n) A "day" can have "slots" (1:n) A "slot" can have a "band" (1:1)

After Update TYPO3 from 9.x to 11.5.x:

In TYPO3-Backend-List-View: If I create a "day" inside a "stage" inside a "year", the backend does not save. No errors shown. Creation of "stage" or "band" inside "year" works fine. If I created the "stage" and open it for itself, I can create "day" and save.

It might be related to the number of IRRE-objects inside the "year"-object. If there are just a few it works, if there are many it breaks.

I attached an example-extension.
For testing it:
+ create a "year" i.e. 2023
+ open 2023 and create some "bands" (maybe around 30)
+ open 2023 and create a "stage" i.e. "Mainstage"
+ open 2023, unfold the "Mainstage" and create a "date"
+ hit "Save" on top
-> new "date" is not saved

See also: https://stackoverflow.com/questions/76373108/typo3-irre-inside-irre-inside-irre-does-not-save


Files

billing.zip (73.2 KB) billing.zip example extension Johannes C. Schulz, 2023-06-01 11:05
Actions #1

Updated by Johannes C. Schulz 9 months ago

  • Subject changed from IRRE does not save, maybe if there are to many objects to TCA IRRE does not save, maybe if there are to many objects
Actions #2

Updated by Torben Hansen 9 months ago

  • Status changed from New to Needs Feedback

I'm not able to reproduce the problem. I created 41 bands and followed all other steps. I could save up to 5 dates and then did not test any more.

When you use inline elements so extensive/nested, a submit to the server will include a lot of fields in the POST request. Depending on the state of the inline elements (collapsed/expanded) and the amount of input fields of the different inline records, you may run into configured PHP limits in regards to maximum accepted input variables.

Please check the max_input_vars setting in your php.ini and try to increase the value. If this fixes your problem, I suggest to use 'expandSingle' => true for all inline elements to ensure, that you somehow have a limited amount of input variables submitted to the server when saving the record.

Actions #3

Updated by Johannes C. Schulz 9 months ago

I tested a lot.
I've cranked my php-settings max_input_vars from 1000 to 10000 and max_input_level from 64 to 128 with no effort.

Going down from 58 bands to 40 down to 30 down to 20, having 2 stages with 3 days each: cant't add another day
Having 30, 20 and 10 bands, adding two stages was possible. adding a day to a stage wasn't. deleting a stage also wasn't possible.

Maybe it's not the number of IRRE elements, maybe its something other:

+ create a year
+ open year and create some bands -> save
+ open year and create one stage -> save
+ open year, unfold the stage and create a date ->save
+ open year, create a second stage -> save
+ open year, unfold a stage, create a date -> nothing happens!

Looks like same issues as https://forge.typo3.org/issues/100937

Actions #4

Updated by Torben Hansen 9 months ago

OK, now I was able to reproduce the problem. However with just a few records. One year, one band and one stage. After I add a 2nd stage, no data is saved any more. Reason for this seems to be your custom form element runningorderoverview. As soon as I remove this from the TCA, it is possible to add additional data again.

Actions #5

Updated by Johannes C. Schulz 9 months ago

Thanks, Torben.
But I see no issues in my custom form element runningorderoverview . Compared to the documentation on docs.typo3.org it should work. And it worked in TYPO3 9.x .

Actions #6

Updated by Torben Hansen 9 months ago

You custom element creates invalid HTML. Since TYPO3 formengine also relies on JavaScript to evaluate several things in frontend (e.g. validation, evaluate if data should be saved), I suppose this somehow breaks if your custom formengine elemente does not create valid HTML. In this case, the POST parameter doSave is not set to 1 by TYPO3 formengine JavaScript when your formelement is active.

You currently have to many closing div elements, since you open the div before the foreach loop, but add a closing div inside your loop. Fix it by adding the closing div outside of the loop as shown below

    $resultTable .= '</tr></tbody></table>';
}
$resultTable .= '</div>';
return $resultTable;

Also make sure to use the none type for your custom formengine element, since all other custom types (e.g. user or passthrough) actually expect a database field to exist. So TCA for your element is:

'runningorderoverview' => array(
    'label' => 'RunningOrder',
    'config' => array(
        'type' => 'none',
        'renderType' => 'RunningorderOverview'
    )
),

With those modifications, new elements can be saved. Yes, I know this is somehow not really a satisfying experience, but the actual reason for the problem is however most likely custom code and not a TYPO3 core problem. No idea why this worked in TYPO3 9.

If you confirm, that this finally fixes your problem, I will update the formengine docs, so it is more clear, that custom elements must contain valid HTML.

Actions #7

Updated by Torben Hansen 9 months ago

I also suggest to add a composer.json (see https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/FileStructure/ComposerJson.html) and please see my message to you on TYPO3 slack.

Actions #8

Updated by Johannes C. Schulz 9 months ago

Thank you a lot. This resolves this issue!

Actions #9

Updated by Torben Hansen 9 months ago

  • Status changed from Needs Feedback to Closed
Actions

Also available in: Atom PDF