Custom Fields from TCA fail on save

[createdwithlove]

For the standard FSC content elements, I added some fields and placed them in a new palette created with the following code:

(TCA/Overrides/tt_content.php)

ExtensionManagementUtility::addToAllTCAtypes(
    'tt_content',
    '--palette--;spacing and alignment;spacing,',
    '',
    'before:sectionIndex'
);

In the content blocks, the tab "Appearance" or the field "sectionIndex" does not exist by default, which is why the palette and contained fields are not displayed.

However, since I didn't want to have the whole basic TYPO3/Appearance tab in the content blocks, but wanted to display a custom tab instead, I added a yaml which creates a new tab with a new palette and the fields defined in the TCA.

Result: The fields are displayed in the content blocks as desired.
BUT: the selected values are not written to the database when saving, but revert to their default values.

When I investigated this problem further, I was able to narrow down the crucial point to 'before:sectionIndex' in the TCA.
Since this field is missing in standard content blocks, the TCA-defined fields won't show up. However, adding them with a content block definition .yaml obviously generates an error when it comes to saving the fields.

My workaround looks like this:

(Basics\Appearance.yaml)

identifier: package/appearance
fields:
  - identifier: appearance
    type: Tab
    label: LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:tabs.appearance
  - identifier: appearanceLinks
    type: Palette
    fields:
      - identifier: sectionIndex
        type: Select
        useExistingField: true
      - identifier: linkToTop
        type: Select
        useExistingField: true

Long story short:
In my opinion, this behavior is not an error, but perhaps it can be intercepted on the code side, since you do not get any feedback as to why saving does not work.
The use case described should be explained in the documentation. Currently, only the reuse of standard elements is explained here.

@nhovratov, let me know what you think about. I can write a text for the documentation if you like.
Is the problem also interesting for TYPO3 v13?

[nhovratov]

Hey, thanks for opening up this issue. Yes, this can be confusing and it's not the first time someone encountered this "field reset on save" error. This happens when a field is rendered two times by FormEngine causing the second field to always override the first one. This is however Core behaviour, which we can't change right now with Content Blocks.

Your approach by defining a custom Basic for the tab is the recommended one. I think the only downside is that your custom fields are then not included in the resolved data object, but are only available in the raw array. We still have no fallback to the raw values, so you probably need to add {data._raw.your_field} for them. Except if you only use them in the layout of fsc, then this doesn't matter.

@createdwithlove
I would love to see a part of the documentation explaining this behavior. It is also still relevant in v13.

Edit: You should restrict the addToAllTCAtypes call to the fsc types which you use, so it won't be applied for Content Blocks types. Then you can include everything in your Basics tab.

[createdwithlove]

Okay, i'll write the explanation and make a PR then.

[nhovratov]

@createdwithlove Hey, are you still up to write documention about this? Otherwise I will add a small section about using Core palettes and syncing them with Content Blocks Basics yaml.

[createdwithlove]

Sorry @nhovratov, I had to leave my last notes unfinished and didn't get it till now.