verbb / formie

The most user-friendly forms plugin for Craft CMS.
Other
95 stars 73 forks source link

Hidden field twig values aren't rendered on the front end #957

Open andypullen opened 2 years ago

andypullen commented 2 years ago

Description When a hidden field is included and given a default value with a Twig variable (such as {siteName}), the value is not rendered on the front end. The data is saved correctly in the submission, but where this causes problems is if another field is conditionally shown/hidden based on the value of the hidden field, the condition doesn't trigger. It seems though that the conditional value works for validation, though (for example, if the conditionally shown field is required, the form won't validate even though the conditionally shown to the user).

Here's an example of the markup produced by the hidden field: <input type="hidden" id="fields-formie-form-71152262bb3ae64feda-campus" name="fields[campus]" value="{siteName}" data-fui-id="prayer-requests-campus"> The "value" attribute should display the rendered Twig output of the site name.

Steps to reproduce

  1. Create a form with a hidden field, and set the default value to Site Name
  2. Create another field that is shown when the Site Name is an expected value (whatever the site name is)
  3. Make the conditionally shown field required
  4. Load the form on a page where the site name matches what was set in step 2

Form settings

Please pick from the options below.

Additional info

Additional context

engram-design commented 2 years ago

So firstly, general Twig functionality isn't supported for a Hidden field at the moment (and probably never will), but you can indeed select some things like other field values or global settings like "Site Name" using the variable/token-picker.

As you've found out though, that these aren't evaluated at render time or in real-time. For static, global values like siteName they don't change once rendered is easy, but what if the field contained "First Name" - "Last Name" - where those were two different text fields being referenced. Because these reference fields that are yet to have a value, we evaluate them on server-side submission when we do have those values. Otherwise, we'd need to use JS to evaluate and add those values in real-time, as the user types on the front-end. This is similar to how the Calculations field works, which relies on that real-time input.

Even if we decided to evaluate Twig when rendering the field, it gets tricky with combining static and field variables, like "Site Name" - "Email" which would be in Twig-terms {siteName} - {email} - we have to parse just {siteName} and leave {email} untouched so that it's evaluated upon final submission (or via JS if we decide to go down that route).

For this reason, where hidden field values are evaluated via JS, we probably won't be able to support Twig functionality in a field.

I'll have to give this some further thought for how to address this.

andypullen commented 2 years ago

Helpful explanation, and I had a suspicion that the token-pickers weren't really ever rendered on the front-end. Interestingly, I had a form that I believe we may have imported from SproutForms that had a hidden field with a default value of {{ siteName }}. We also had a conditionally shown field based on the value of the site name, and as far as I can tell it both saved the siteName value and displayed the conditional field fine until we updated to 1.6.1. I found out by hearing that the form was no longer validating because the conditional field (which is also required), was no longer showing up. I changed the value to the Site Name token picker, and it (understandably) didn't fix it. The only resolution I can figure out is to make the conditional fields un-required. It seems like the fact that it was working was a bit of a fluke. I hope that helps some!

engram-design commented 2 years ago

So we did change this behaviour in 1.6.1 to fix another issue (which I mentioned, some people wanted to use {firstName} {lastName} in hidden fields), but I'm going to have to come up with a better solution than this!