Initiate overzealous issue title sequence.

Liam Morland and I maintain Webform Tokens. It was initially created because Webform did not provide tokens consumable by other modules. It does now, so there isn't much point in it continuing to exist.

We have come up with a plan A and a plan B for its future.

Plan A is to check if you support merging the two. If so, we can start submitting patches (or one big patch) to bring in the Webform Tokens tokens, and we could clean up strings and the interface from there.

Plan B is to switch to using hook_token_info_alter() and hook_tokens_alter() and extend Webform's submission namespace. I don't think there are any that currently conflict, although there would probably be duplicates, which we would remove.

Either way, other modules using Webform tokens would benefit since they wouldn't have to do anything special to support the Webform Tokens tokens; both modules now specify 'needs_data' => 'webform-submission' and take a submission in the same format.

So let me know your thoughts. Also see:
#1606970: [Meta] Future of Webform Tokens
#1934636: Create 7.x-4.x branch
#1717934: Support Webform 4.x

#1612270: Support Webform 4.x tokens

Comments

quicksketch’s picture

quicksketch
he/him
commented

Plan A is to check if you support merging the two. If so, we can start submitting patches (or one big patch) to bring in the Webform Tokens tokens, and we could clean up strings and the interface from there.

Could you give an overview of what new tokens are necessary? I imagine for most tokens, we simply need to convert them from the Webform Token format to the Webform 4.x format. I would think that most tokens are provided natively by Webform at this point.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

My off-the-top-of-my-head answer is such (I don't have the Webform-provided tokens in front of me, so apologies if I am mis-remembering what they provide):

Webform Tokens has better support for select-type Webform fields. You can use a token for a specific option, which is useful with multiple-select checkbox fields. You either get the value or a blank if that specific checkbox isn't selected.

It also provides tokens to get component labels. The use case for this is from Fill PDF. A user needed a way to change both the questions and answers on a New Lead-type PDF. The same template was used for several different Webforms.

Webform Tokens is more descriptive about what each token does. Most of time, you can use the click-select functionality in Token. I'm not sure if you kept them to a more general format to reduce UI noise, though. We list them per-Webform, which makes it easier to figure out which one you want without checking the Webform manually.

I think the meta-tokens are the same. I don't recall if you chain the Webform Nid to node tokens, though, but we do some explicit token chaining which can be useful.

Let me know if you need more information. Fill PDF is the only module I'm aware of that implements Webform Tokens tokens (Webform Rules uses their own...). Fill PDF 7.x-2.x also consumes regular Webform tokens now.

quicksketch’s picture

quicksketch
he/him
commented
Category: feature » support
Status: Active » Fixed

Webform Tokens has better support for select-type Webform fields. You can use a token for a specific option, which is useful with multiple-select checkbox fields. You either get the value or a blank if that specific checkbox isn't selected.

Let's make a new issue for this feature request.

It also provides tokens to get component labels. The use case for this is from Fill PDF. A user needed a way to change both the questions and answers on a New Lead-type PDF. The same template was used for several different Webforms.

This has been added in #2038371: Create a better naming scheme for our tokens [submission:values:x].

Most of time, you can use the click-select functionality in Token. I'm not sure if you kept them to a more general format to reduce UI noise, though. We list them per-Webform, which makes it easier to figure out which one you want without checking the Webform manually.

There is a feature request for this here: #1037828: Expand token list for [submission:values:x] in token browser

I think the meta-tokens are the same. I don't recall if you chain the Webform Nid to node tokens, though, but we do some explicit token chaining which can be useful.

I'm not really sure what this request means. You can use the [node] token directly in Webform's current tokens, so you have access to all the node information. [submission:user] chains currently too. So I'm not sure if there's anything else needed here.

Overall, I'm marking this a fixed support request, since we've already got issues for the main concerns. Let's open specific issues for anything remaining.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.