So now that we've got the snazzy new and improved Token API in D7 core, I think it would be a good time to re-evaluate and see if we can simplify some of the code that webform is doing and use what core and/or Token module provides.

Part 1: Let's make sure all of webform's tokens have "real token" replacements:

Basic variables

%username - Core provides the [current-user:name] token
%useremail - Core provides the [current-user:mail] token
%ip_address - Token module provides [current-user:ip-address]
%site - Core provides [site:name]
%date - Core provides [date:*] (Token module renames these to [current-date:*])

Special variables

%profile[key] - Token module provides [current-user:profile*]
%server[key] - Not yet provided by anything, but could easily be added in Token module as [current-page:session:*]
%session[key] - Not yet provided by anything, but could easily be added in Token module as [current-user:session:*]
%get[key] - Issue open in token module to provide as [current-page:query:*] or [current-page:get:*] with #550164: Query string tokens
%post[key] - Not yet provided by anything, but could easily be added in Token module as [current-page:post:*]
%request[key] - Not yet provided by anything, but could easily be added in Token module as [current-page:request:*]

Possibly the get/post/request/sever tokens should be located into a [current-request:*] token type since they really don't have anything to do with the current page. Or [current-page] should be renamed to [current-request], hrm.

Other benefits of integrating with Token module

- You can use token validation (e.g. $form_element['#element_validate'] = array('token_element_validate')) to make sure users aren't entering invalid tokens.
- Re-usable token UI so less work you have to do yourself
- We can allow users to also use the node tokens for the webform node

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

I was just looking at the tokens available for the form elements, when looking at the email template found a few more tokens that should probably require a new 'webform-submission' token type.

%email_values - should probably be [webform-submission:email-values]
%submission_url - should probably be [webform-submission:url]
%email[*] - should be [webform-submission:email-value:*] dynamic token
%value[*] - should be [webform-submission:value:*] dynamic token

Dave Reid’s picture

Assigned: Unassigned » Dave Reid
Category: task » feature
Status: Active » Needs work
FileSize
8.45 KB

Here's my initial work with creating webform submission tokens, not really integrated at all yet.

Dave Reid’s picture

Issue tags: +token
quicksketch’s picture

I agree that using the core token system would definitely help with consistency. Though, it looks to me like these new tokens are significantly more verbose and more difficult to remember/type-out than the previous ones. I believe it's possible to "scope" our tokens a little bit, there's no reason to include "webform-" before our tokens if Webform is going to be the only module utilizing these tokens (no other module would pass in a $submission object). So instead of something like [webform-submission:value:*] we could just use [submission:value:*]. Regarding %email vs. %value I'd love to have a better name for that token anyway. %email[key] isn't actually a "value" at all, it's actually an entire label and the submitted value all together.

quicksketch’s picture

Title: Really use token integration » Rewrite token replacement system to use D7 tokens
Dave Reid’s picture

Well the problem is that that token name could result in namespace collisions, since no other module could define $info['types']['submission'] if webform module was installed. That's why I initially went with using the webform- namespace in the token types.

quicksketch’s picture

Aren't tokens provided on a per-object basis? The "submission" token would only be valid in contexts where a Webform $submission object were passed in.

skhot’s picture

subscribing.

Shawn DeArmond’s picture

Joining this conversation because of #428982: New hooks for additional token replacements.

Weaver’s picture

Sorry, after posting that I started digging around in webform.module and found the "* @param $allow_anonymous"
Im sure im now in the wrong place for this question but is there a way to set this to TRUE from the site administration or do i need to hard code it in the module?
Thanks

%ip_address doesnt work in WebForm 7.x-3.9 (2011-Mar-06)
Is this something that will naturally be address through this topic, if so can anyone suggest an ETA?
If its not, is there anyone who could help debug the issue, I can provide any information/testing required.
Thanks

bradjones1’s picture

Subscribe.

BrightBold’s picture

Subscribe. I would really like to be able to pull Profile2 and RealName fields into Webform, but I'm reluctant to use a forked version of the module.

jeffschuler’s picture

Subscribing.

@Dave Reid: this is assigned to you and marked Needs Work. We should assume you're not looking for review of your patch in #2?

Torenware’s picture

Status: Needs work » Needs review
FileSize
6.91 KB

I need to integrate webform with some custom token work I already did, so I've updated Dave's patch.

The new patch:
* is against 7.x-3.11
* adds a call to token_replace so that your tokens actually get substituted in.

For some reason, the new custom tokens for webform itself are not appearing in the new token help (although the regular system tokens and any other custom tokens I have *are* appearing).

This may be useful to somebody, since it's useful for me. I haven't tried to debug what's up with the new tokens, but for now, here's what I have.

BTW: not sure what I should be patching against. I pulled the full git repository and checked out the tag for 3.11, which seems to work.

Torenware’s picture

FileSize
6.99 KB

Found where the new webform-submission type needs to be integrated. The help will appear only on email related fields. It's possible that node tokens need to be made available in addition to user and webform-submission tokens, but since this is a feature I haven't needed yet, someone who does use this feature should test this new patch.

Torenware’s picture

Quicksketch --

I've just posted a couple of patches that extend Dave Reid's patch from #2. It still uses "webform-submission", but invokes the standard tokens ("standard" as in: supplied via the Token API) in the same places that the legacy tokens are replaced.

There's UI issues with how to document the both the old tokens and the new tokens. The current implementation loses your in-form documentation of the old tokens, but continues to expand them as before. It might be possible to do all of these tokens together, but not as the old tokens are currently implemented.

miro_dietiker’s picture

Subscribing, Reviewing.

s_leu’s picture

In the attachement i added a patch that covers both previous patches in this issue and adds a dependency to token module to the info file. Please review and commit.

Dave Reid’s picture

Status: Needs review » Needs work
+++ webform.moduleundefined
@@ -2593,6 +2593,19 @@ function _webform_filter_values($string, $node = NULL, $submission = NULL, $emai
+  $token_data = array(
+    'user' => $user,

If $user is just global $user, then do not include in token data as the 'current user' is already handled by [current-user:*] tokens.

+++ webform.tokens.incundefined
@@ -0,0 +1,124 @@
+  $info['tokens']['webform-submission']['path'] = array(
+    'name' => t('URL'),
+    'description' => t('The URL alias to view the webform result.'),
+  );
+  $info['tokens']['webform-submission']['url'] = array(
+    'name' => t('URL'),
+    'description' => t('The URL to view the webform result.'),

Just make one token that is [webform-submission:url] that should use the 'url' token type. See http://drupalcontrib.org/api/drupal/contributions--token--token.tokens.i... on how to make the url token chained.

Powered by Dreditor.

s_leu’s picture

FileSize
9.46 KB

Corrected the patch to support the 'url' token type. Please review.

miro_dietiker’s picture

Looks very nice!

The readme however does not refer to the dependencies: For the example provided you'll need to explain the exact modules that need to be enabled as a first step.

Please set the issue back to "need review" again.

s_leu’s picture

Status: Needs work » Needs review

changing status

thijsvdanker’s picture

can't get the patch to apply properly.. against which version did you make it?

s_leu’s picture

Regarding the D7 port:
We finally saw that submission tokens are not really tokens for the values of a submission, instead they were tokens for the webform node itself and we were missing the actual webform submission tokens (a token per component in the current webform). This has now been fixed so it's possible to include submission value tokens in the mail body.

In addition we're about to implement a backport for Drupal 6.

Would you add this feature for the 6.x-3.x release?

Using contrib token.module as a full replacement for the token system, we'll need to update all current webforms (nodes) with their components / default values and the mail contents to make sure nothing breaks.

s_leu’s picture

FileSize
10.27 KB

Here's the new patch

Hydra’s picture

Subscribing

quicksketch’s picture

Status: Needs review » Needs work

If someone can work out an upgrade path that renames all our existing tokens I'll review this patch. Right now still seems like a daunting task. Unrelated, current patch includes a dsm().

Murz’s picture

I can't apply the patch from #25 to current webform 7.x-3.11, for which version it must work?

At now on current webform version 7.x-3.11 any tokens for field default values without this patch must works normally or not? I try many of them, but nothing works: neither of %nid, %title, %username, %get['param']....

miro_dietiker’s picture

Murz, patches are ALWAYS against current dev version.

miro_dietiker’s picture

DUPLICATE, sorry.

miro_dietiker’s picture

Discussed the dynamic token issue with davereid - token UI maintainer:
#1222978: Support dynamic tokens for e.g. webform submissions

Note that the dynamic token needs a "dynamic => TRUE"...

To have a fully dynamic UI that shows the dynamic tokens in concrete (better usability) we would need to extend/patch token UI as it doesn't support such a thing currently.

s_leu’s picture

new patch including changes discussed in #1222978:

Note that there is no update path yet. This patch will not replace texts with already existing %tokenname tokens within the system. So it's only useful for new installations yet.

miro_dietiker’s picture

Seems fine to me. So we need an upgrade path to merge. :-)

gfpk’s picture

Sorry, for asking, but I'm newbe - how do i imply those patches, could somebody recommend a tutorial or post mini explenation I would be really grateful

BrightBold’s picture

@gfilipek:

Beginner's guide to patching a Drupal module: http://drupal.org/node/620014
How to apply a patch on Mac OS: http://drupal.org/node/60180
How to apply a patch on Windows: http://drupal.org/node/60179
Applying a patch manually: http://drupal.org/node/534548
Applying a patch using Git (which I assume is not what you need to do, but this seems to be the new recommended document so I'm including it): http://drupal.org/node/707484

Hope one of these is helpful.

gfpk’s picture

thank you for your help, very useful stuff.

thijsvdanker’s picture

Is there something I can do to speedup getting this comitted?

miro_dietiker’s picture

If you can implement the upgrade path, please do so.
You'll need to upgrade all present forms and replace old tokens with new tokens to make sure nothing breaks.

tic2000’s picture

Status: Needs work » Needs review
FileSize
13.18 KB

Changes from the last patch

  1. Added the [webform-submission:email:?] token to replace the old %email
  2. Added the [webform-submission:email-values] token to replace the old %email_values
  3. Fixed the [webform-submission:submission:?] token which did not work unless the form key was the same as the label (rarely the case)
  4. Made the Token module a dependency and added instructions in the README to install that first
  5. Added an upgrade path

Note that the code that handled the tokens in the original form is not yet removed, so both work with this patch.

Things to be discussed:

  • What do we do with the tokens that Dave Reid suggested it's easy to be added in the Token module but that are not provided yet (%post, %server, %session, %request, %profie)? The options are:
    • we provide them and remove them when the token module will add them
    • we keep the current code in place and open a new issue to change them when the token module provides them

Another thing to be noted is that the tokens (in the old or new form) do not work on the confirmation page, but that's for another issue.

tic2000’s picture

About the token name, I would suggest to use just "webform". "submission" is more prone to namespace collisions and "webform-submission" seems too long and the [webform-submission:submission:?] token accentuates that.

rikki_iki’s picture

subscribing.

Does this include Profile2 tokens?

Alan D.’s picture

@quicksketch in relation to #27
Could the upgrade process be dropped if the module branched to 7.x-4.x? That was the approach that Drupal core took between D6 and D7 with the user tokens, so mark wasn't set that high in this regards. I can not speak for others, but for myself, the benefits would greatly outweigh the negatives here.

quicksketch’s picture

Could the upgrade process be dropped if the module branched to 7.x-4.x?

No. Even in the D6 to D7 upgrade, tokens are migrated for Drupal core, such as the user welcome e-mails. See user_update_7017(). We can't leave users out in the cold with potentially thousands of old tokens to clean up. We have a limited data-set to work with, we should be able to do the conversion.

Alan D.’s picture

Never looked at the code, but these never got updated on our sites! I assumed that it was a thing that wasn't covered in the update! So maybe we have hit a core bug :(

bgilhome’s picture

FileSize
13.18 KB

Couple of small bugfixes for patching 7.x-3x-dev (21 Dec 11).

emarchak’s picture

It looks like this patch allows you to insert tokens, but it doesn't remove custom tokens if they are empty. So for example, [current-user:user_custom] displays correctly when the there is a replacement value, but just displays "[current-user:user_custom]" if the user hasn't inserted anything in the custom field or if they're anon.

patcon’s picture

Can anyone give a summary of how this is preferable over webform_tokens (or vice versa)?
http://drupal.org/project/webform_tokens

Also, here's a patch against 3.15 that should work as a drush patch

haydeniv’s picture

@patcon
Webform Tokens are for other modules to have access to tokens created by web form. This patch is about replacing the custom webform token system with the token module.

patcon’s picture

gotcha. thanks @haydeniv!

quicksketch’s picture

Status: Needs review » Needs work

@tic2000's patch in #39 is looking pretty good and I'd still really like to see this move forward. A few comments:

- This update code isn't going to work since the table name is wrong (has a trailing "1" for some reason):

+  $result = db_select('webform_component1', 'wc', array('fetch' => PDO::FETCH_ASSOC));

- The upgrade path leaves out updating the following:

  • Select component options
  • The variables for 'webform_default_subject', 'webform_default_from_address', and 'webform_default_from_name'. These variable defaults should be updated in the webform_variable_get() function as well as in the database through variable_get/variable_set.
  • The confirmation redirect URL
  • E-mail configuration's address, from name, and subject fields

- Minor code formatting in this comment (needs a space and a period):

+  //First, let the token api have at it

- The patch currently leaves in the existing token system, which I'd prefer to kill entirely in preference of the new system. One of my chief complaints in #428982: New hooks for additional token replacements was the ugliness of having two completely different yet mostly redundant token handling systems. As I also said in the other issue, the token system in D6 is so wildly inefficient, it's not suitable for use in the ways Webform utilizes tokens. Thus this patch will probably be a D7 only feature and we don't need a backport.

Regarding how to handle upgrading %get, %post, and other server tokens, I agree it's strange to have Webform define these tokens. However we can provide these tokens specifically only for Webform by using the "callback" option in token_replace(). User.module does the same thing for its specialty tokens in the user registration/notification e-mails. See _user_mail_text() (down at the very bottom of the function) and the callback function itself, user_mail_tokens(). Token module has to do some somewhat odd backflips to get this into the UI though... I'm not sure yet how to handle that. Perhaps we can merely include help text (similar to what we have already) to describe how to use those tokens. The token UI is not particularly helpful in this situation anyway because there's no way to know what %get (or [get] tokens as they will probably be in the future) are available.

quicksketch’s picture

Profile (user) tokens are also not currently updated.

flightrisk’s picture

I just downloaded the Feb 27 build and I can't get tokens to work. How do I insert the current users first name and last name into a field as in putting this in the default for that field: "[current-user:field-fname] [current-user:field-lname]"

quicksketch’s picture

I just downloaded the Feb 27 build and I can't get tokens to work.

The tokens described in this issue are not yet implemented. There is no way to use field-based tokens currently. There's a separate issue over in #1023918: Add support for user Field module fields e.g. %profile[field_name] (which you also found) hoping to make the existing token system support fields, but this patch would supersede that approach by converting the entire token system to use the D7-style (real) tokens instead of a custom token solution.

flightrisk’s picture

Thank you. I've had a hard time understanding the threads to see what is happening. So what is the status of the new version that is supposed to use the D7 tokens? That is what was listed as "pretty good", but then didn't properly handle updating because there was a 1 at the end of the database name. Is it usuable/testable now to see if I can get the tokes for first name, last name, address,etc? And can you concatenate the new tokens as in "[first_name] [last_name]?

quicksketch’s picture

The biggest problem right now is that the token system doesn't adequately get upgraded for existing forms. But since this patch leaves in place the old token system *in addition* to the new token system, that's not much of a problem for end-users. My guess is that enthusiasm may have fizzled out because the patch in #47 probably works perfectly fine, but it's not suitable to be included because it doesn't handle the upgrade path properly and it doesn't remove the old token system.

magnusk’s picture

@quicksketch, would you agree to having two step issues: one to introduce the regular D7 token system, and another one to convert old tokens to the new ones?

quicksketch’s picture

@magnusk: No, because then it would never get done. Once the half-solution is in place, the maintainers will be left with the cleanup.

flightrisk’s picture

So who are the maintainers? And is there a way to see that by looking at the main page of the module somewhere, or do you have to sift through the commits and get an idea who is able to post changes?

And what IS the solution then? I keep hearing what can't or won't be done and what is broken, but how and who can fix it? ;) I've been trying to learn PHP and the Drupal API, etc, etc, but the learning curve is just too steep and at the moment I only maintain one website. If this were written in Delphi or VB.NET I would gladly help, but after weeks of sifting through docs and trying to look at module code, it just seems too complex for a part-timer. I'll need a lot more time to get up to speed. I was able to help fix one or two minor bugs with other modules where the fix was obvious to me and didn't include a lot of the more deep API functions, so I'm not a forum vampire.

You say the patch leaves the old token system in place in addition to the old. So is it responsible for the new token system? I don't care about upgrades at this point, I'll redo every form if I have to, there aren't many. What will allow me to have a default that picks our the users first and last name and sticks them in a name field? Are patches cumulative? In other words, if I take the current dev version and apply the patch in #47, does that give me what I need, or do I have to add the previous patches, I think one was in #35?

Your list of changes to a possible upgrade solution didn't look like much for someone proficient. It looks relatively close to a permanent fix, no?

quicksketch’s picture

And is there a way to see that by looking at the main page of the module somewhere

Yes, in the upper-right of the module page.

So is it responsible for the new token system?

My hope is that people interested in this feature will write a complete patch, instead of the half-baked one we have here. Now don't get me wrong, I'm quite appreciative of the work everyone has done here already, especially tic2000, bgilhome, s_leu, Torenware, patcon, and Dave Reid; who have updated the patch or given it some review. But this patch isn't complete, the upgrade path is partial and broken, and the old token system needs to be removed.

I don't care about upgrades at this point, I'll redo every form if I have to, there aren't many.

Yes, that's the attitude of most people, which is why there isn't an upgrade path that works and why if I committed this as-is, I wouldn't expect one to ever be written except by the maintainers.

magnusk’s picture

I understand the reasoning but I don't expect that this patch evolution can happen as hoped by the maintainers. For instance, I have no interest in nor time for doing it, because I never used the old-style webform tokens. On the other hand, I'm more than happy to focus effort on the new, in-core tokens if needs be.

So, if nobody writes code to transition old-webform-tokens to in-core tokens, should we expect to still be manually patching each new webform release by the time D8 is released? to put things in a somewhat more provocative way, how can we consider webform to be fully D7-adapted while it is not using the tokens that are now in core?

vernond’s picture

I guess it boils down to priorities. As things stands right this minute, there are bigger fish to fry. Between day jobs, a busy issues queue, other contrib modules and various sundry commitments, who has the time to try be top of everybody's favourites list? The fact that you do not have the time or interest for fixing it does not immediately confer sufficient time and interest upon anyone else.

We try to get the really important stuff as quick as we can, the not-quite-as-important stuff needs a little more patience. I think Webform is fairly functional despite this outstanding issue. The D7 adaption is also quite a bit more complete than some other contrib modules I have seen.

This issue will be addressed when someone has sufficient time and interest and to tackle this properly and completely, just as quicksketch said.

miro_dietiker’s picture

magnusk, you'll need to accept this.

Maintainers responsibilities is for maintenance, quality assurance and clean solutions. An upgrade path is something CRITICAL and we cannot drop it just because you think things aren't going on too fast.

If you want a feature to go in, you'll need to support that the upgrade path happens with everything you have. Really. The ecosystem around drupal would break if maintainers wouldn't assume responsibility. I'm pretty sure you would be the first to complain, once your upgrade pathes are broken for a module you use and upgrade.

We tried pushing this issue with s_leu and tic2000 from our team. However our time is also limited and i also count on other peoples interest in completing this stuff.... anyone? Feel free to complete yourself or fund a developer to do so. But don't complain.

Please stop this resource wasting discussion and start to work on it...

Shawn DeArmond’s picture

Attached is a re-rolled patch based off of today's git checkout of 7.x-3.x. It seems to be pretty feature-complete, including a rather decent update function that converts old-style tokens to the new-style tokens. I tried all of them except for %profile[key] tokens, which the update function doesn't seem to support. (And whose life seems to be limited anyway. Does anyone know if Profile module even HAS Token support at all?)

I also added some code to enable the Token module, if available, or a warning message to download and install it, if it isn't.

So, my question to @quicksketch, et al. is: What still needs to be done? Profile module support, I guess, unless we don't care about that anymore. What else?

quicksketch’s picture

And whose life seems to be limited anyway. Does anyone know if Profile module even HAS Token support at all?

The %profile token has always been misleading. It's actually a %user token, so things like %profile[uid] should be converted to [user:uid]. It only supports a direct mapping of immediate properties, so anything that is in $user->foo was %user[foo]. I think that means all %profile tokens can be converted directly to [user:foo] tokens, which would at least handle the most common properties of UID and name. I agree that we don't need to worry about profile.module tokens (if they even exist).

quicksketch’s picture

What still needs to be done?

- %profile tokens (as covered in #64)
- The old token system also still needs to be removed.
- We need to support the old %get, %request, %server, etc. tokens. See my post in #50 for how to handle this, or on further thought even a str_replace() would be fine, we don't necessarily need to use a token callback.
- I don't think we need to introduce a dependency on Token module. We just shouldn't output the help text for tokens if it's not available. As I understand it, tokens still work just fine without it, but they're more limited.

Shawn DeArmond’s picture

Attached is a new patch. It converts the %profile tokens to [current-user:*] tokens, and it works.

I don't think we need to introduce a dependency on Token module.

It appears that several tokens don't resolve unless the Token module is enabled. For example: [current-user:ip-address], [current-date:long], [current-user:status], and [current-page:query:*] don't resolve. There are probably more, but these are the ones that I found. This is odd, because [current-user:name], [current-user:mail], and others do resolve. As soon as I enabled the Token module, they all worked... except [current-user:status], curiously enough.

We need to support the old %get, %request, %server, etc. tokens.

%get is already in the Token module (not core). It's [current-page:query:*] and it's already supported in the upgrade path.

I created #1475926: Add more global tokens, such as session, server, cookie, post, and request as a feature request to add %request, %server, %post, and %session tokens. I added it to the Core issue queue, though; now that I think about it, it probably should go into the Token module issue queue instead.

The old token system also still needs to be removed.

Once we're happy with the upgrade path, the old token system can be removed.

Shawn DeArmond’s picture

It should be noted that I upgraded %profile tokens to [current-user:*] tokens because I assumed that [user:*] would be the same as [node:author:*]. It appears to not be the case. [user:*] and [current-user:*] appear to be equivalent, so I'm not sure it matters one way or another. Opinions?

quicksketch’s picture

Hey Shawn, thanks again for the reroll and further progress on this issue!

%get is already in the Token module (not core). It's [current-page:query:*] and it's already supported in the upgrade path.

Great, thanks. By my unscientific estimates (based on support requests), the %get tokens are the most commonly used tokens, though they probably have close competition from remote_address, http_referrer, and user tokens. By comparison, I think [current-page:query:*] is awfully verbose. Combined with a lack of support for POST, SESSION, SERVER, etc tokens, I wonder if we wouldn't be better off with tokens added specifically for the use of Webform in our own hook_token* implementations (or by using the str_replace() approach). In the past we've also had multiple requests for handling nested access to session variables too, so perhaps that's getting more messy than Webform would support itself. What's your take?

quicksketch’s picture

I wonder if we wouldn't be better off with tokens added specifically for the use of Webform in our own hook_token* implementations

And by this, I mean tokens that are shortened up like [get:key] and [session:key].

Alan D.’s picture

I wonder if Dave would add the shorter versions into Token, as these would be useful all over the place.

overtune’s picture

@Shawn DeArmond: I applyed the patch in #66 and it seems to be working. I found one problem though, if I use a token for a field in the user-account, and that field is empty for current user, the webform form prints the Token-replacement code instead. E.g. this is what I get in the input field: [current-user:field_user_company]

ngbranitsky’s picture

I installed the patch from #66.
I have added a field to my user account profile called Surname (field_surname) and set the value to "Smith".
I installed the Profile2 module and in profile-main created a field called Former Surname (field_former_surname) and set the value to "Johnson".

In the Surname field in my webform, I clicked on the Default value field and opened the Tokens Values list.
Under "Current user" I see 2 fields called Surname:
NAME TOKEN DESCRIPTION
Surname [current-user:field-surname] Field "field_surname"
Surname [current-user:field_surname] Text Field.

In the Former Surname field in my webform, I clicked on the Default value field and opened the Tokens Values list.
Under "Current user" I see the following:
NAME TOKEN DESCRIPTION
Profile profile [current-user:profile-main] The users's Profile profile.
Former Surname [current-user:profile-main:field_former_surname] Text field.
Former Surname [current-user:profile-main:field-former-surname] Field "field_former_surname"

I've tried using both the instances listed above to no avail - when I display my webform
the Default values are not displayed.
Are the default values only visible when the webform is printed?
Or do they appear on the screen during data entry, as one would expect?
I would prefer to use the Profile2 tokens.
Suggestions, please.

quicksketch’s picture

Taking into consideration this issue and another issue that can't be implemented cleanly with API breakage (#1215456: Multiple and same-page conditional rules), would those people here be in support of a 7.x-4.x branch that broke APIs with the current 7.x-3.x branch (thus not having to support %post, %request, %server, etc)? The %get token is by far the most common token, and given support for the full array of tokens, we could eliminate support for all these legacy super-global based tokens.

Beside here, also please express your opinion into https://nate.webform.com/form/927, which I've tweeted to solicit broader responses.

Alan D.’s picture

Great idea :)

I think one question on the survey should be:

( ) I would happily contribute $100 dollars to help to pay for an upgrade path.
[On select AJAX opened link to a chip-in page / paypal]
( ) I would rather reconfigure the administration settings myself.
[On select AJAX opened link to the Change Log page]

If the results suggest that there are users that need this support, maybe it is time for a chip-in widget to raise the funds required to pay for your (or another developers) time in the process.

[edit] I would be doubly supportive of dropping support for the upgrade path if this is holding your own business venture back! I just followed some of the links off the site to http://webform.com Love the theming on the forms! [/edit]

robertom’s picture

Taking into consideration this issue and another issue that can't be implemented cleanly with API breakage (#1215456: Multiple conditional rules), would those people here be in support of a 7.x-4.x branch that broke APIs with the current 7.x-3.x branch (thus not having to support %post, %request, %server, etc)?

Yes! I support this great idea ;)

Beside here, also please express your opinion into https://nate.webform.com/form/927, which I've tweeted to solicit broader responses.

I would respond at this webform... but I don't use drupal 6 and I haven't the right choise for question 2 (is required):

The most important thing for the *Drupal 6* branch offer me at this point is: ✻

  • Stability and compatibility with existing modules
  • New features (i.e. graphs, better Token and Views support, same page conditionals)
Shawn DeArmond’s picture

@quicksketch:

First of all, I would be in favor of 4.x that broke just those APIs.

However, do you see an issue with just leaving the %post, %get, %request, %server, and %session tokens as undocumented "legacy" tokens that will continue to work, but won't be announced anywhere. That way, they won't break existing sites trying to upgrade. I know your goal is to rip out the code that processes these types of tokens, but it might be worth seeing what it would take to just leave in these tokens.

%get IS actually supported in D7 core tokens, but, as discussed at length, is confusing and verbose.

Dave Reid’s picture

If we need improvements to the actual tokens provided by Token module, I'm more than happy to consider them so they're available and improved for more modules than just Webform.

Shawn DeArmond’s picture

Dave Reid’s picture

Thanks! I'll respond on that issue. Make sure to file more requests in the Token queue and ping me about them otherwise I won't see them in this issue queue.

Tab10id’s picture

Subscribe.
upd: sorry for this comment, @fenstrat thanks.

fenstrat’s picture

quicksketch’s picture

However, do you see an issue with just leaving the %post, %get, %request, %server, and %session tokens as undocumented "legacy" tokens that will continue to work, but won't be announced anywhere.

If the feature exists it will be used. There's no such thing as "not announced anywhere". :)

Support for token-based [post:*], [server:*], etc. tokens could be added by a contrib module easily enough, I just think that we should remove those tokens because they really shouldn't have existed to begin with; they're hacks.

Shawn DeArmond’s picture

True. Well, as long as [current-page:query:*] exists, verbose as it is, I'll be happy.

rjkuyvenhoven’s picture

to clear tokens when fields are empty apply the attached patch instead, or change line 2927 in webform.module after applying the patch in #66

from
$string = token_replace($string, $token_data);

to
$string = token_replace($string, $token_data, array('clear' => true));

quicksketch’s picture

FileSize
36.28 KB

Here's an updated patch with the following changes:

- Removed old token system and updated everywhere I could find that uses them.
- Add updating the site variables and individual webform confirmation texts to the upgrade path.
- Renamed update to 74xx numbering scheme.
- Converted update hook to use BatchAPI.
- Changed %date token to be [webform-submission:date:long] instead of [current-date:long]

Some things left to be done:
- Upgrade path does not properly support nested tokens (i.e. %value[fieldset_a][field_b]). Actually I'm not sure the new token system properly works with nested fields at all, I'm guessing probably not yet.

- We shouldn't convert the current %email and %value tokens as is into two separate parent groups. Instead each should be children underneath the fields which they represent. For example:
%email[test] tokens to [webform-submission:values:test]
%value[test] tokens to [webform-submission:values:test:raw]

Taking this approach will allow us to nest or pull out properties of fields such as:

  [webform-submission:values:test:label] (for select list labels)
  [webform-submission:values:test:day] (and month/year for dates)
  [webform-submission:values:test:minute] (and hour/ampm for times)
  [webform-submission:values:test:?] (for grids)

This doesn't need to happen in this iteration, but we should rearrange the tokens so that they are ordered field-name first, then derivatives of that field as children.

Finally, what do you think about ditching the "webform-" prefix on these things? Could we just take [submission] for our own, instead of [webform-submission]? It's not like there's a submission.module out there, and if there were, it would probably be acceptable that a top 20 module claim the namespace anyway. Thoughts?

quicksketch’s picture

Oh, I also removed the dependency on token module. We don't really *need* to make it a requirement, since it mostly provides the UI. The underlaying API works just fine without the module and there's no hard requirement for us to have Webform work properly (though you don't get the [current-page:query:?] tokens).

Dave Reid’s picture

Status: Needs work » Needs review
+++ b/templates/webform-mail.tpl.phpundefined
@@ -19,18 +19,18 @@
+<?php print ($email['html'] ? '<p>' : '') . t('Submitted by user: [webform-submission:user:name]') . ($email['html'] ? '</p>' : ''); ?>

Shorter you can just use [webform-submission:user] here.

+++ b/tests/webform.testundefined
@@ -466,7 +466,7 @@
+          'value' => '[user:profile_gender]',

Should this be [current-user:profile_gender]? The [user:*] tokens require a specific user account object to perform replacement.

+++ b/webform.tokens.incundefined
@@ -0,0 +1,148 @@
+        default: // Webform submission tokens (caching per webform node)
+          $split = explode(':', $name);
+          $skey = $split[1];
+          $node = node_load($submission->nid);
+          foreach ($node->webform['components'] as $ckey => $cvalue) {
+            if ($cvalue['form_key'] == $skey) {
+              if ($split[0] == 'submission') {
+                $replacements[$original] = $submission->data[$ckey]['value'][0];
+              }
+              elseif ($split[0] == 'email') {
+                $replacements[$original] = $cvalue['name'] . ': ' . $submission->data[$ckey]['value'][0];
+              }
+            }
+            else {
+              continue;
+            }
+          }

Rather than using the default step here (which would cause invalid tokens to somehow get replaced with valid values), you should use the token_find_with_prefix() function for the dynamic values. system_tokens() contains a good example with the [current-date:custom:*] dynamic tokens.

+++ b/webform.tokens.incundefined
@@ -0,0 +1,148 @@
+    if (($node_tokens = token_find_with_prefix($tokens, 'node')) && $node = node_load($submission->nid)) {
+      $replacements = token_generate('node', $node_tokens, array('node' => $node), $options);

Node is available as a chained token replacement, but I don't see it listed in webform_token_info() under $info['tokens']['webform-submission']?

+++ b/webform.tokens.incundefined
@@ -0,0 +1,148 @@
+    if ($url_tokens = token_find_with_prefix($tokens, 'url')) {
+      $replacements = token_generate('url', $url_tokens, array('path' => url("node/{$submission->nid}/submission/{$submission->sid}", $url_options)), $options);

Should be just array('path' => "node/{$submission->nid}/submission/{$submission->sid")

quicksketch’s picture

Should this be [current-user:profile_gender]? The [user:*] tokens require a specific user account object to perform replacement.

Thanks. And we probably need to convert the tests to use a Field field instead of a profile module field anyway.

Node is available as a chained token replacement, but I don't see it listed in webform_token_info() under $info['tokens']['webform-submission']?

Ah, I should have mentioned that. So there's no situation where it's possible to have a webform submission without already having its node (since the submission is specific to the node). Is it really worth duplicating a token you're going to have already, adding probably at least 500 rows to the token tree help table? I couldn't see the value in it if the top-level [node] tokens are already going to provide the needed functionality. We should remove the remnants of its support.

I'll look into the other suggestions too, which all make sense.

quicksketch’s picture

FileSize
35.63 KB

Still some of Dave's feedback to be incorporated in this patch, but it does the following:

- Now supports nested tokens.
- Rearranges the tokens as described in #85.
- Claims the "submission" namespace.
- Tests updated to work with Field module. All tests passing again.

Anonymous’s picture

Forgive my ignorance, but I'm getting an undefined offset error on line 114 of webform.tokens.inc. Only on webform submission when I'm using nested field tokens in the email output. Removing tokens from the email template seems to fix it, but the emails still send and data is saved just as normal either way. The only issue is the error printed to users. It's also worth mentioning I'm using the webform ajax and webform conditional modules, although they don't seems related to this.

Seems related to this thread, so I thought it was worth documenting. I was able to fix it with the following changes to lines 114-127 of webform.tokens.inc, but I'm not sure if this is the best solution.

Thanks!

          $node = node_load($submission->nid);
          foreach ($node->webform['components'] as $ckey => $cvalue) {
            if ($cvalue['form_key'] == $skey) {
-              if ($split[0] == 'submission') {
-                $replacements[$original] = $submission->data[$ckey]['value'][0];
+              if (isset($submission->data[$ckey])) {
+                if ($split[0] == 'submission') {
+                  $replacements[$original] = $submission->data[$ckey]['value'][0];
+                }
+                elseif ($split[0] == 'email') {
+                  $replacements[$original] = $cvalue['name'] . ': ' . $submission->data[$ckey]['value'][0];
+                }
              }
-              elseif ($split[0] == 'email') {
-                $replacements[$original] = $cvalue['name'] . ': ' . $submission->data[$ckey]['value'][0];
-              }
            }
            else {
              continue;
quicksketch’s picture

@rclations: Please try out the latest patch. It uses a completely different approach from the one you had tried, and it no longer contains that section of code at all. It also sounds like you're trying this on a production site (with several other modules installed). At this point I hope you're doing this just for testing purposes, since the syntax of the tokens has also changed, so you'll need to start over again and run the update against your original data.

Anonymous’s picture

@quicksketch thanks for the quick reply. I actually downloaded fresh copies of webform & token this morning then ran your patch before finding the issue. I ran it using terminal, but I don't see anything in the patch that changed webform.tokens.inc ?

I wish I was just using this code for testing purposes, but unfortunately there's an issue with webform conditional (http://drupal.org/node/1458140#comment-5912804) which is solved by using the new token system, so here I am. I've accepted that I'll just need to keep up with this thread and test everything heavily before updating the production site.

quicksketch’s picture

FileSize
43.27 KB

Oh silly me, my patches haven't included the actual webform.tokens.inc file. Here's one including that new file in the patch.

This patch makes the minor improvement over #89 in that it will properly convert tokens that are next to each other, such as:

%values[test][test][foo]%values[test][test][bar]

Will properly convert into:

[submission:values:test:test:foo:nolabel][submission:values:test:test:bar:nolabel]
quicksketch’s picture

@rclations: From your other issue:

This does not work = %value[fieldset_1][text1]
This is the new way, which does work = [webform-submission:submission:text1]

The format has changed as I mentioned. It's now [submission:values:text1:nolabel]. I would suggest starting with a pre-patch database and running the update.php script again to convert your existing tokens into the new format.

EDIT: Corrected token name. Should be ":values", not ":value".

Anonymous’s picture

Awesome, thanks so much for the help!
I've updated the other issue with the token structure above for continuity.

quicksketch’s picture

The #93 patch is functionally ready to go and meets all my requirements. I'd just like to get confirmation on the following:

- Does the structure of the token make sense? I like the way it works now, with the ability to tack-on modifiers at the end of the token (such as the current "nolabel" modifier). Later we can add things like "key" for select lists or "year" for date fields.

- Any qualms with claiming the "submission" namespace? I couldn't find a way to make this token webform-specific, because hook_token_info() doesn't take parameters for context, so it can't show submission tokens specifically for Webform. If we use [submission], other modules will not be able to use it without mixing together the token help listings.

Dave Reid’s picture

I still worry about a namespace conflict. It sucks to have longer tokens, but I think this would set a bad precedent for other modules.

Rather than do node and submission token replacement concurrently, have you thought about linking the form node with the submission tokens with [submission:form:etc] or [submission:node:etc]?

quicksketch’s picture

Rather than do node and submission token replacement concurrently, have you thought about linking the form node with the submission tokens with [submission:form:etc] or [submission:node:etc]?

Hey Dave, thanks for your input. I don't understand this suggestion. These tokens still aren't namespaced and only make the tokens longer ([submission:node] instead of [node]). As far as Webform's tokens go, there's actually only one place where the [submission] tokens are used (in the e-mail templates). Everywhere else in Webform only has the [node] token to work with, because the submission doesn't yet exist (such as when filling out the form).

quicksketch’s picture

Status: Needs review » Fixed

After chatting with Dave yesterday on this topic, I got his sign-off on this token implementation being acceptable. So, without further ado I've branched Webform for 4.x and pushed up these changes (the patch in #93). Yay! I'll enable the 4.x dev release and it should be available sometime soon after the drupal.org packaging script runs.

Shawn DeArmond’s picture

w00t! Awesome!

miro_dietiker’s picture

Woooow, cool to have this in, guys! Thanks a lot for this great progress!

Status: Fixed » Closed (fixed)

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

Rechi’s picture

I have a problem using the new tokens for fields inside an fieldgroup, I currently use the patch of #93:

[submission : values : fieldgroup-key : field-key : nolabel] -> Prints the entire Fieldgroup Content including label
[submission : values : field-key : nolabel] -> No Value
[submission : values : field-key : nolabel] -> Correct Value, if field is outside the fieldgroup

Do I use the wrong tokens?

fenstrat’s picture

@Rechi The patch in #93 was committed to webform-7.x-4.x in #99, so there's no need to apply it to anything, just use 4.x (e.g. 4.0-alpha4). If you've still got problems please open a new issue.

Rechi’s picture

I understand. Thank you for your fast reply.

dankoB’s picture

This looks great. Could you please clarify what tokens should be used or where to find the list of available token replacements? I'd like to prepopulate my webform with firstname, lastname, and email defaults for logged in users.

dankoB’s picture

Nevermind. Found it here: http://drupal.org/node/1308722
List is under the Edit tab of the webform Content type (in webform 4.x). email for example is [current-user:mail].

rooby’s picture

Version: 7.x-3.x-dev » 7.x-4.x-dev

Changing version so people don't get confused and expect to see this in 3.x.

pirex360’s picture

Please Help Me...

I am using webform and profile 2 , i cannot put webform using token from profile 2... i tried everything...