It is possible to use webform submission token values in elements on single page webforms? Looking at a the quick example below, I am attempting to combine the values from elements a and b in a third hidden element, c. When the webform is submitted, the final value for c is empty. Implementing a solution in code is pretty straightforward, but I am curious if this can be achieved in pure a YAML/UI solution.

a:
  '#type': textfield
  '#title': 'Textfield A'
  '#required': true
b:
  '#type': textfield
  '#title': 'Textfield B'
  '#required': true
c:
  '#type': hidden
  '#value': '[webform_submission:values:a][webform_submission:values:b]'

When using a multipage webform, the token values are replaced as expected for emelnts on both the first and second pages -- both c and d are populated as expected with the combined values of a and b.

first_page:
  '#type': wizard_page
  '#title': 'Page one'
  a:
    '#type': textfield
    '#title': 'Textfield A'
    '#required': true
  b:
    '#type': textfield
    '#title': 'Textfield B'
    '#required': true
  c:
    '#type': hidden
    '#value': '[webform_submission:values:a][webform_submission:values:b]'
second_page:
  '#type': wizard_page
  '#title': 'Page two'
  d:
    '#type': hidden
    '#value': '[webform_submission:values:a][webform_submission:values:b]'
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bonus created an issue. See original summary.

jrockowitz’s picture

jrockowitz’s picture

The attached patch removes the token 'clear' option. Let's see how many test break.

gg4’s picture

Category: Support request » Bug report
Priority: Minor » Normal
Status: Active » Needs review

Looks like you are seeing this as a bug. Moving to needs review to kick the test bot.

jrockowitz’s picture

Not a bug but a bad decision. I think clearing tokens is bad idea and is hindering implementing computed fields, like the one that you included in your example.

  • jrockowitz committed 439e4d7 on 8.x-5.x
    Issue #2861976 by jrockowitz: Token replacement on single page webforms
    
jrockowitz’s picture

Status: Needs review » Fixed

I committed the patch.

gg4’s picture

Thanks for the quick response and resolution!

jrockowitz’s picture

There is a minor regression that I will fix where the [webform-authenticated-user] are visible on the contact form.

jrockowitz’s picture

Status: Fixed » Needs review
FileSize
647 bytes

  • jrockowitz committed 596081b on 8.x-5.x
    Issue #2861976 by jrockowitz: Token replacement on single page webforms
    
jrockowitz’s picture

Status: Needs review » Fixed
gg4’s picture

Status: Fixed » Needs work

@jrockowitz I am still not seeing tokens populate correctly per the original issues report when using the latest dev.

jrockowitz’s picture

FileSize
2.55 KB

This is going to be a lot harder than it seems. We are probably going to need to create a 'computed_value' element.

The immediate problem that I am running into, is that the WebformElement's 'format' methods are not aware of the Webform's submission.

For example the WebformElement::buildText(array $element, $value, array $options = []) does not get passed the WebformSubmission entity which would contain the submission values.

We also need to decide if using tokens or inline Twig templates (like Views) for the computed value.

Attached is the original example converted to a (broken) test form.

jrockowitz’s picture

BTW, there might be some temporary patch that could get the token replaced on a single page form when a form is validated. I just could not get it to work.

The long term benefit of a computed element is that the result could be dynamic or saved to the database.

gg4’s picture

Yea this is tricky. I started to look into this as well and will keep digging a bit.

We might want to make sure we are clear on the exceptions around how to deal with empty tokens (#2758695). Seems like ideal state is that they are cleared if empty on form render/display and re-evaluated post-submission for potential replacement according to whether they are #default_value or #value. I don't this current result is desirable. On the current dev, the literal token strings are rendered in visible fields.

a:
  '#type': textfield
  '#title': 'Textfield A'
  '#required': true
b:
  '#type': textfield
  '#title': 'Textfield B'
  '#required': true
c:
  '#type': textfield
  '#title': 'Texfield A + B'
  '#value': '[webform_submission:values:a][webform_submission:values:b]'
jrockowitz’s picture

The primary use case for tokens is to allow information from the environment, current user, and source entity to passed into a form element or email.

The specific use case that you need is definitely a computed element/value. I think your immediate solution/work-around would be to user a form alter to populate element C.

I also think we need to revert the patch that removed the clearing of tokens.

gg4’s picture

Agreed on the revert, and the form_alter will likely be fine for my actual use case. I opened this issues originally as a support request because I was unclear if the scenario I outlined was expected behavior or not. If we consider the current functionality expected, I am wondering if it would be helpful to document which tokens users can expect to populate successfully on a single page form and other caveats around their use in #value and #default_value properties. Thanks again for your time digging into this issue.

jrockowitz’s picture

Status: Needs work » Needs review

I am rerunning the tests. I think the current functionality make sense but may not be expected. That is why a computed element would solve a lot of confusion because the behavior would be that you enter the tokens or twig variables and the result is always displayed when the element is rendered.

Big picture, tokens need better documentation, especially when it comes to source entity tokens which allow webform nodes to pass field values to embedded webforms.

  • jrockowitz committed 252f332 on 8.x-5.x
    Issue #2861976 by jrockowitz, bonus: Token replacement on single page...
gg4’s picture

Do we want a new issue for the new computed element or should we use this one?

jrockowitz’s picture

Yes, the computed element needs a dedicated ticket.

jrockowitz’s picture

Status: Needs review » Closed (outdated)

Now that computed elements are supported I am going to close this ticket.