Ambiguous FlexForm properties generic.redirect vs. generic.redirect.pid

[ohader]

When previewing content, \TYPO3\CMS\Core\Service\FlexFormService::convertFlexFormContentToArray is used to create a hierarchical representation of FlexForm values. Properties containing a dot . are organized in this structure. For instance property values a.b=1, a.c=2 are converted to an array like ['a' => ['b' => 1, 'c' => 2]].

Using ambiguous names in different hierarchy levels leads to problems when processing the FlexForm data. In this particular case properties generic.redirect and generic.redirect.pid cannot be represented in mentioned structure. The corresponding error message in the TYPo3 backend looks like the following.

Core: Exception handler (WEB): Uncaught TYPO3 Exception: Cannot create references to/from string offsets | Error thrown in file /var/www/html/www/typo3/sysext/core/Classes/Service/FlexFormService.php in line 54. (TYPO3 v10)

(side note: TYPO3 core uses a `try/catch` block when invoking `FlexFormService`, the screenshot above is triggered by `ext:solr` which does not apply `try/catch` - anyway, the problem is caused by `ext:mkforms`)

---

I'd suggest to rename FlexForm property generic.redirect to generic.redirect.enable in https://github.com/DMKEBUSINESSGMBH/typo3-mkforms/blob/v10.1.3/flexform_main.xml#L100-L108

[hannesbochmann]

@ohader Thanks for the report. We are aware of this problem but just haven't got time to deal with it as we need to keep backwards compatibility. So it's not just this simple change. Furthermore there are similar problems with EXT:mksearch and it's Flexform when some extbase domain model/repository is used somewhere in the plugin. The root cause is EXT:rn_base and it's internal configuration parsing which we leveraged in the past and is now in conflict with the core.
We will have a look at it.

[hannesbochmann]

@ohader Could you please check if the problem still persists with the latest version of the 11.5 branch?

[ohader]

The mentioned problem occurred in a project using TYPO3 v10, ext:mkforms was added as dependency by https://packagist.org/packages/oliverklee/seminars#v4.4.0. Newer versions of ext:seminars dropped the requirement to ext:mkforms - which I did in mentioned project. Thus, unfortunately, I don't have a test scenario anymore.

[ohader]

However, commit 78899e7 looks good to me as it gets rid of mentioned ambiguity in the names of the FlexForm structure.