flexform ds remains even if the plugin changes
tt_content used as tt_news Plugin gets changed into some other Plugin. In this case the xml of the tt_news flexform remains in the flexform field and gets additional flexform xml of the new plugin.
Normaly no problem, it could happen, that if you render tt_news in your own plugin, tt_news gets old configurations of the former plugin.
Yes its a solution to delete the tt_content. But not every author is used to it, so it would be better to overwrite the flexform field on plugin change.
(issue imported from #M11170)
Updated by Sebastian Fischer over 7 years ago
The problem still exists in 4.5 AND in 6.0. So it's still a problem when you change a plugin to another and relay to much on values from flexform. The fields not present in the attached flexform are not removed while changing the plugin or even content type
Updated by Mathias Schreiber almost 6 years ago
- Status changed from New to Needs Feedback
- Assignee set to Mathias Schreiber
- Is Regression set to No
Would you consider this for Flexforms only?
The same principle applies for any type change.
So the value of the field "subheader" remains in the record after switching into a type that does not show the field.
Would you clear all fields not shown?
Updated by Sebastian Fischer almost 6 years ago
In general i would assume that changing the type removes the unwanted data too, but keeping performance in mind i dont know if its such a good idea to process every content element.
Some could argue to do so only on type change and i would be fine with this agrument.
If its an intentional change everything is good, and using the history its possible to restore the removed data too. So in general i would think its a good idea to clean everything that is not needed anymore.
Updated by Claus Due over 4 years ago
I don't agree.
Changing a record column like the content type or plugin type does not remove any values from other columns of that record. Removing the flexform "columns" therefore wouldn't make sense, at least to me.
See also https://forge.typo3.org/issues/73630