My idea is to provide a similar solution in TYPO3 core, which however is a little different. Instead of defining ignored override settings in TypoScript, I would define them in every FlexForm sheet in the T3DataStructure as shown below (naming is just an example).
This can then either be used in DataHandler to prevent to save empty field values to pi_flexform or in FrontendConfigurationManager to ignore affected settings when TypoScript and FlexForm settings are merged.
Pro for the DataHandler solution:
Plugin datastructure is already resolved and
Con for the DataHandler solution:
Plugin Settings have to be re-saved in TYPO3 backend in order to remove ignored and empty FlexForm field values
Pro for the FrontendConfoigurationManager solution:
Plugin settings do not need to be re-saved
Con for the FrontendConfoigurationManager solution:
FlexForm needs to be resolved and parsed while rendering a plugin. This may cost more time and may be error prone (e.g. if FlexForm is somehow invalid/can not be parsed)
My general question is, if such a solution is suitable (especially if the introduction of a new T3DataStructure node)?
I’d say this is currently Extbase/FrontendConfigurationManager territory.
It would actually be nice to have that override-TypoScript-defaults-by-editor for other content, too. This would do well as an API. Maybe as a DataProcessor?
IMHO: If we want to get that “right” forever, there is no way around adding a checkbox next to each flexform field with the label “use default value”, which defaults to true.
So Extbase is actually able to decide whether the flex-field’s value is to be considered or not.
That’s the only feasible way I can think of, which covers everything from textfield, select and group fields.
(and if we want to go nuts: one more checkbox: “merge with default” )
Torben, thanks for addressing this. I do not want to make this more complicated, but I agree with Markus Klein and think we need a solution that works long term and with edge cases also.
(1) People above and in the issue already mentioned the problem of
“what is empty”
you can’t override a non-empty default anymore in Flexform with the solution mentioned above.
what about other non-text fields which do not have an “empty” state, e.g. radio buttons, check boxes etc.
I think a solution needs an exact definition of what is empty and what should override what.
Or do we want a way to set a value explicitly or leave it alone (use default from TypoScript). Also, what if there is no TypoScript? Should set to default.
Implementation can be
a) checkbox (as mentioned above), in issue and used e.g. to override the FAL metadata
b) radio buttons (override vs. use default) as used in “Translation behaviour” allowLanguageSynchronization for translated fields where you can choose the value of the record in the default language or set to a custom value.
(2) minor naming nitpick: ignoredTypoScriptOverrideFlexFieldsIfEmptyValue is not clear to me. What is ignored, what is overriden? Maybe ignoreEmptyFlexFields (if you want to not mention TypoScript) or maybe doNotSaveEmptyFlexFields* (with datahandler solution) or flexFieldsWithEmptyValueDoNotOverrideTypoScript
(3) having a separate list makes it easy to overlook. I would prefer the setting in the respective field column, e.g. as additional “doNotOverrideIfEmpy” or whatever property (would then have to be defined in TCA), just looking what would be convenient as Extension developer).
(4) Is this Extbase specific? Why not make the functionality to combine TypoScript and Flexform (or TCA in general, see 5) a generic core functionality and add this along the way?
(5) suggestion from @jonaseberle1 is also interesting, might help to see some usecases though.
100% agree. This also is no new feature, this is already in use for file references where editors are able to use the inherited value from the file record itself. Same for translations.
“No new feature” is currently wrong here, since nullable values and the whole “checkbox” thing is not supported by FlexForm. I’m currently creating a POC on how we could integrate a solution with a checkbox (see screenshot)
From an admin perspective, this is exactly what is needed to prevent global TypoScript settings from being overridden. However, for editors, this checkbox has no real value and is confusing too (regardless of, if the checkbox show the global value or just a text), since it is not self explaining and an editor might not be aware of, what TypoScript is or that some plugin settings might be configured globally.
The checkbox-solution might also not be inline with the general wish to make to TYPO3 backend more clean/user friendly, but I’ll try to finish the POC so we have something to discuss on.
From an administrators perspective I see three scenarios:
the TypeScript value is a default and can be override via FlexForm
the TypeScript value cannot be overriden via FlexForm but is visible
the TypeScript value cannot be overriden via FlexForm but is invisible
From an editors perspective I wantto see any default value. A checkbox telling me to use the default is useless if i don’t know what is.
Furthermore if “use defaults” is checked the field must be rendered as non-editable showing the defaults. But the FlexForm should preserve whatever the editor has entered regardeless of te state of the checkbox. If the checkbox state is toggled the form must reflect this immediately or tell the user to save and reload it.
Checkboxes next to every single field will clutter up the form. So I propose that fields with TypeScript values are rendered as non-editable by default. Only if a checkbox is asked for in TypeScript (not the FlexForm) it should be rendered. Perhaps a config setting in the FlexForm will make a field with a TypeScript value non-rendered.
Remains the issue of empty strings and the number zero in TypeScript. IMHO both should be treated as distinct values different from empty.
)
