Task #97002
openSimplify flexform behavior and stop saving old settings in flexforms (+ get rid of the then no more necessary flexform cli command + scheduler task)
0%
Description
When working with the forms framework I did come over some pretty nasty core behavior in the flexform context.
I did find parts in the flexforms like:
(...)
<sheet index="ea4ca6637d2b7dbe41c867c14d43ef95">
<language index="lDEF">
<field index="settings.finishers.Redirect.pageUid">
<value index="vDEF">59</value>
</field>
<field index="settings.finishers.Redirect.additionalParameters">
<value index="vDEF"></value>
</field>
</language>
</sheet>
<sheet index="9cc4c6a803d8627cf0c4aca3161f4314">
<language index="lDEF">
<field index="settings.finishers.Redirect.pageUid">
<value index="vDEF">59</value>
</field>
<field index="settings.finishers.Redirect.additionalParameters">
<value index="vDEF"></value>
</field>
</language>
</sheet>
(...)
So duplicated settings values just because the core flexform behavior doesn't get rid of old settings when saving a flexform. (in this case the "persistenceIdentifier" changed)
I asked myself what is the purpose of saving old settings to the flexform fields? Why not only saving the current state? I don't see a valid use case for keeping old settings values. (please switching plugins and restoring settings is NOT a use case)
In the end simplifying this would also make it possible to get rid of the "cleanup:flexforms" cli job. Which is just another maintenance task that should not be necessary.
Updated by Christian Kuhn 6 months ago
- Related to Bug #73630: flexform data is not deleted when changing plugin added