TYPO3 Core

You can set renderingOptions._isHiddenFormElement to control this behavior.
https://docs.typo3.org/typo3cms/extensions/form/latest/Config/proto/formElements/formElementTypes/Hidden.html?highlight=_ishiddenformelement#renderingoptions-ishiddenformelement

It is a regression as it worked as intended for our customers. It is not up to you to decide if a hidden variable should be sent with the email.

I found out about renderingOptions._isHiddenFormElement. But it means that the integrator has to change any form created by an administrator manually.

If you set this within the form setup, it rules for all forms.

I'm sorry, I had a rather bad day until now (I defeated an unwilling VPN client program). Back to normal mode now.

When I wrote notifciation mail I didn't mean the one sent to the frontend user (form sender), but the one to the site owner (form receiver). That's why I wrote that an editor who sets up a hidden field, expects it's value to be set back to him.

For my customer this was a breaking issue as he has lost vital information about the forms content (the products name/id the customer was inquiring). We have been called in to do a hotfix. So even if you think that it is the right behaviour, the changelog of TYPO3 should have had a waning about a breaking change.

I didn't investigate the issue completely, but I noticed that read-only fields are also exempt from rendering. This makes me wonder wether the same class is used for rendering in different contexts. They being "form sender" and "form receiver". IMHO all fields should be rendered in the latter context.

I had the same issue, trying to display a hidden field in a confirmation mail. I believe this is currently not possible to solve because a hidden field has a BaseSetup yaml setting saying that it should not be rendered in confirmation mails.

This variant can not be overridden, so even if you add your own variant with "renderingOptions->enabled->true" based on a finisher condition it will not work.

Here is the base setup of the form extension for the hidden field type:

            Hidden:
              __inheritances:
                10: 'TYPO3.CMS.Form.mixins.formElementMixins.FormElementMixin'
              variants:
                -
                  identifier: hide-1
                  renderingOptions:
                    enabled: false
                  condition: 'stepType == "SummaryPage" || finisherIdentifier in ["EmailToSender", "EmailToReceiver"]'

A non-working attempt at overriding it in a form yaml file would look like this:

-
        type: Hidden
        identifier: someIdentifier
        defaultValue: ''
        variants:
          -
            identifier: in-email
            renderingOptions:
              enabled: true
            condition: 'finisherIdentifier in ["EmailToReceiver"]'

My solution was to create a new custom hidden field in my base setup file like this (you need the HiddenCustom.html partial as well):

            HiddenCustom:
              __inheritances:
                10: 'TYPO3.CMS.Form.mixins.formElementMixins.FormElementMixin'

and now using type "HiddenCustom" instead of type "Hidden" I can render the value in emails.

TL:DR: Variants can't be overridden as far as I can tell.

@Ralf I was not able to override it in a form definition yaml file, I see you are testing in the form prototype settings. Are you able to make it work in a form definition file? Besides that your first condition "hide-1" only states "finisherIdentifier in ["EmailToSender"]" and not "EmailToReceiver" so it would make sense that your example works as shown.

While I understand the reason for #81770 I don't like the way it has been resolved. Nice to see that with variants a workaround may be possible, but it is awkard and not user-friendly. Anyway, this is no solution for v8.

Was there really no other way then to make hidden fields magically disappear by forcing the rendering flag to false? Like using a different property for use in finishers instead of the rendering option (for steps).

@Jarvis please see #87615

Ralf Zimmermann wrote:

@Jarvis please see #87615

Ah cool, thanks for taking care of that issue :-)