Project

General

Profile

Actions

Bug #87617

open

Change of flexform definition leads to duplicate data

Added by Michael Stopp almost 6 years ago. Updated over 1 year ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
-
Start date:
2019-02-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:
On Location Sprint

Description

We made some rearrangements in a fairly large flexform with several tabs. The main change was that some fields were moved into different tabs for improved usability.

It was clear that this would be problematic for existing content elements as the data for the moved fields would be lost. But after manually updating + saving such existing flexforms, it turned out that old data for the moved fields would remain in its original location, while also being saved to the new location.

So let's say field 'xyz' was moved from tab 'A' to tab 'B'. After opening and saving an existing flexform, you would now have data for 'xyz' in tab 'A' AND in tab 'B'.

I guess in real life this will probably not cause many problems as you would fetch data for a particular field from the location you'd expect it to be according to the flexform definition. But still: I don't see a legitimate reason why this should be the intended behaviour. The saved data should reflect the current definition of a flexform and not be a mixture of old and new, with zombie data floating around in your data structure.


Related issues 1 (1 open0 closed)

Related to TYPO3 Core - Bug #73630: flexform data is not deleted when changing pluginAccepted2016-02-23

Actions
Actions #1

Updated by Riccardo De Contardi about 5 years ago

I guess it is related to #73630 ? Am I wrong?

Actions #2

Updated by Michael Stopp about 5 years ago

Related yes, but not the same thing. In #73630 it's about whether there should be flexform data or not, while in this issue it's about the inner consistency of such data. But they are certainly related, because they both deal with flexform data, that doesn't accurately reflect the current configuration of a plugin.

Actions #3

Updated by Riccardo De Contardi about 5 years ago

  • Related to Bug #73630: flexform data is not deleted when changing plugin added
Actions #4

Updated by Jonas Eberle almost 4 years ago

There is a CLI command to clean up "zombie" data:

[typo3/sysext/core/bin/|vendor/bin]typo3 cleanup:flexforms

Does that meet your requirement?

Keeping or removing data from old data structures is also a question with "CType switching" (https://decisions.typo3.org/t/switchable-ctypes-how-to-solve-consistency-issues/660) - there are different oppinions if it is useful or harmful...

Actions #5

Updated by Michael Stopp over 3 years ago

@Jonas Eberle: sorry for taking so long to answer your question. Yes, in a (somewhat limited) test I just ran, the cleanup:flexforms command did correctly clean up flexform data that contained an inconsistency as described in my original issue description.

Actions #6

Updated by Benni Mack over 1 year ago

  • Sprint Focus set to On Location Sprint
Actions

Also available in: Atom PDF