BUG: flux.field.file can not be cleared / removed in the backend (configuration)

[JarekYaro]

I have checked that the bug exists in the dev-development branch
Yes
I have checked that there are no already open issues or recently closed issues about this bug
Yes

Describe the bug
There is no "x" Symbol or any other option to clear the previous chosen image or icon in backend using the <flux:field.file .../>. Even the backspace key doesn't work. After clicking on an eye-icon, the whole field disappears.

To Reproduce
Under <f:section name="Configuration"> use flux:form, then flux:form.section and flux:form.object to use <flux:field.file name="buttonIcon" label="Icon für den Button" allowed="svg" useFalRelation="1" showThumbnails="1" maxItems="1"></flux:field.file>

Expected behavior
On click on the input field a x-symbol should appear. On click on the x-symbol you should be able to clear the chosen file.

Screenshots

[JarekYaro]

I have found the reason for this behaviour and (probably) the right line of code.
TYPO3 11 = No problem detected
TYPO3 12 = Problem detected

The visible-icon set on trigger set one (read-only) input field to hidden and the other (the one with the x button) to active. This should be done by adding and removing the css class "hidden" in

-> <input type="text" id="formengine-input-67360dbd585db275569720" class="form-control t3js-clearable t3js-form-field-inputlink-input hasDefaultValue hidden" data-formengine-validation-rules="(...)" data-formengine-input-params="(...)
not by setting the html attribute to hidden. The class stays after you press the visible button and set the display of the input field to none !important.

Here we go:

flux/Classes/Integration/FormEngine/ProtectValueWizard.php

Line 30 in a167840

$result['html'] = '<input type="hidden" name="' . $fieldName . '" value="0" />';

Please, can you fix this for the TYPO3 12 version?

[NamelessCoder]

I'm not sure I understand the problem here. It looks like a couple of things are being mixed together:

• The behavior or TYPO3 when you click the eye/link split icon is not handled or affected by Flux. What happens when you click this icon is completely vanilla TYPO3 - if that hides the field, then that sounds like a TYPO3 core bug (which may be isolated to fields within FlexForm context) or a usage that isn't handled (which is what I think is going on: link fields pointing to files should not support and will not handle file paths like this, even if you can see the field value in "edit" mode).
• The Flux class that you are referencing does not get included automatically, and would not be included based on the settings of your flux:field.file field. The purpose of that class is to render a checkbox as field wizard which when you check it, protects the value from being cleared out of the XML that gets saved to DB if it matches the value that would be inherited from a parent. It has to do only with value inheritance (so, only applies to pages) and the HTML it contains will only if 1) you've enabled inheritance for the field, and 2) you've added protect="1" on the field. It doesn't seem relevant at all in this context.

From my perspective this looks like it's an unsupported usage with a field value that's only rendered as fallback. Flux simply does not hook into this field to modify CSS, JS or HTML that it produces. All Flux does is hand over a TCA field configuration - the TYPO3 core is then responsible for rendering and handling it. You would be seeing the same problem if you used a totally vanilla FlexForm with this field type, without Flux installed.

You should also be aware that every field dealing with file relations is notoriously broken in v12 except for IRRE FAL (flux:field.inline.fal). The core team has made multiple changes trying to remove file support from non-IRRE FAL fields. While some field types may still render the markup that allows you to see the saved values, it is likely that this is only possible either as fallback or by accident (leftover not yet removed by the core team) or because you're using some other kind of custom field modification (e.g. JS or FormEngine override that makes it possible to render this type of field with a link to a file). And this field composition / this type of field value is not expected to be functional at all.

Whatever the cause is: I would strongly recommend simply not relying on any field type other than flux:field.inline.fal (which supports transform="filereference" to convert the template variable to a FAL FileReference object automatically) when dealing with file relations. Sadly, this isn't supported within section objects, so you'll have to find another way to structure this (suggested: substitute section objects for child content elements in a nested content area).