rte_transform "db" is not applied to RTE-fields defined via "foreign_types" / palettes
I needed an RTE-field for sys_file_reference, so i created one the usual way (defaultExtras, softref ...).
Then i created a custom palette for sys_file_reference and added the fields i needed to it. This palette is used via ExtensionManagementUtility::getFileFieldTCAConfig() and "foreign_types" in a tt_content FAL-relation field.
Visually there are no problems while editing the FAL elements within the tt_content elements. The text added to the RTE field is visible in frontend, but the rte_transform stuff with direction "db" was never applied to the RTE field before saving the data to DB - which leads e.g. to the very messy problem, that all links created with the link wizard will be stored as "a" elements with absolute URLs and not as internal "link" elements.
Way to a solution:
To hotfix this i found out that BackendUtility::getTCAtypes() used in
DataHandler->fillInFieldArray() does not return useful field information. It returns the showitem definition of the original "types" array of the sys_file_reference TCA, which contains no fields at all.
My hotfix just checks "$incomingFieldArrayKeys" in DataHandler->fillInFieldArray() for "_TRANSFORM_"-fields and adds the required field definition to "$types_fieldConfig" if it´s missing there.
For a cleaner solution the "foreign_types" have to be considered and there fields extracted - but i was not able to spot logic that does s.th. like this.
Updated by Christian Weiske almost 6 years ago
This bug was observed in 2013 already; see the forum entry: http://forum.typo3.org/index.php/t/198527/
The problem happens on any TCA RTE field that is inside a palette.
The bug seems to be in
Updated by Romain Seignez over 5 years ago
I had the same problem. I fixed it by adding: 'defaultExtras' => 'richtext:rte_transform[mode=ts_links]' to the field TCA config.
You must declare a mode to the "rte_transform" array. The funny thing is you can ask the ts_css mode, the ts_links work also...
Updated by Philipp Kitzberger over 4 years ago
We ran into the same bug and were able to create a patch that fixes this issue. Thanks to Robert for pre-debugging ;-)
The patch works for our scenario but needs further testing and possibly refactoring.
Any chance this might still be included into the 6 and 7 LTS?