New hooks for additional token replacements

It's not currently possible. Webform doesn't currently use the token.module (though it would be helpful if it did), so tokens provided by other modules are not supported. However we run into the problem that we'd need to convert all the existing tokens to token module in some update. The change is too large to include in the 2.x version of Webform.

Let's make this the general issue for adding token replacement to Webform.

I would be very interested in having token support too.

+1 for token support

Am using Domain Access and I would like to use Webform to create one side-wide contact form to be used on each subdomain. With token support I could use Domain Access' %site-email as the recipient. Hopefully I'll be able to combine this with this then; http://drupal.org/node/462932

Cheers

+1 as well for token support,
I am having trouble using domain access and webforms together correctly.

I would really like the ability to use site-mail variable.

Thanks,
Tom

Even in the 3.x version, this still isn't possible. It might be interesting to support Token module in addition to the existing tokens, either that or consider using token's ability to use tokens that start with "%" instead of the traditional square brackets. I'd also have some serious performance concerns over token.module performance, since Webform can run token replacements up to 3 times for *every* field on the page. Select lists have tokens replaced for every option. Meaning on a typical form submission, you might be running 100+ token replace requests. On a CSV download it might be tens or hundreds of thousands of times.

You get my vote, this would be incredibly helpful.

1+ for token support.

This should have been finished by now.

This should have been finished by now.

I currently don't plan on supporting token module, which is why this isn't done. I'll review patches, but I don't think I want this in Webform due to the extreme performance penalties.

I currently don't plan on supporting token module, which is why this isn't done. I'll review patches, but I don't think I want this in Webform due to the extreme performance penalties.

Is there a way for me to create a forked version of this module, where all I need to do is maintain my patches to this module? (something like GitHub/BitBucket fork perhaps...)

I'm almost done adding token support to webform for a client of mine.

This module is amazingly easy to use....I'm happy I found it :)

I wouldn't recommend forking Webform in any way, especially at our current pace of development in the 3.x branch. Even git can't solve problems automatically when the same lines of code are changed between your fork and the original. I'm interested in seeing the approach you took, submitting a patch would be a good way to share your changes (though I'm not making any promises that it would be included).

Here's the patch.

Based on a comment above, the following code adds token support for uprofile.

I've rolled the following code into a new module "token_profile2" for myself.

/**
* Implements hook_token_list().
*/
function token_profile2_token_list($type = 'unspecified') {
  if ($type === 'uprofile') {

    // Load the profile tokens
    $fields = content_fields(NULL, 'uprofile');
    foreach($fields as $field) {
      if($field['type_name'] !== 'uprofile')
          continue;
      $tokens['uprofile'][$field['field_name']] = $field['widget']['label'];
    }
    
    return $tokens;
  } 
  else if ($type === 'profile') {

    // Load the profile tokens
    $result = db_query('SELECT * FROM {profile_fields} ORDER BY category, weight');
    $fields = array();
    while ($field = db_fetch_object($result)) {
      $tokens['profile'][$field->name] = $field->title;
    }
    
    return $tokens;
  }
}

function token_profile2_uprofile_values($account)
{
    global $user;
    $nid = db_result(db_query("SELECT nid FROM {node} WHERE type = 'uprofile' AND uid = %d", $account->uid));
    $profile_node = node_load($nid);

    // Load the profile tokens
    $fields = content_fields(NULL, 'uprofile');

    // Extract values
    $results = array();
    foreach($fields as $field) {
        if($field['type_name'] !== 'uprofile')
            continue;
        $field_name = $profile_node->$field['field_name'];
        $results[$field['field_name']] = $field_name[0]['value'];
    }

    return $results;
}

/**
* Implements hook_token_values().
*/
function token_profile2_token_values($type, $object = NULL, $options = array()) {
  $tokens = array();
  
  if ($type === 'uprofile') {
    $tokens = token_profile2_uprofile_values($object);
  } 
  else if ($type === 'profile') {    
    // Load the profile tokens
    $account =& $object;
    profile_load_profile($account);
    $result =  db_query('SELECT * FROM {profile_fields} ORDER BY category, weight');
    while ($field = db_fetch_object($result)) {
      $tokens[$field->name] = profile_view_field($account, $field);
    }
  }
  
  return $tokens;
}

To take advantage of the above "token_profile2" module in your webform, use this patch.

Sorry, please delete that patch. Here is the right one.

quicksketch, did you have a look yet? It's been a while and haven't heard back from you.

These patches have the same problems that I was concerned about: serious performance penalties and no migration of existing tokens. As-is there's no way we could use these patches. I'm not sure it's feasible to use token module with Webform considering the number of replacements that are done per page-load (essentially 2 or 3 for every component: the default value and the description, plus once for every option in select lists).

serious performance penalties... I'm not sure it's feasible to use token module with Webform considering the number of replacements that are done per page-load (essentially 2 or 3 for every component: the default value and the description, plus once for every option in select lists).

That's a valid point, but not reason enough to avoid incorporating token module as an optional feature. i.e. users can choose to enable/disable token module usage.

no migration of existing tokens.

Why do existing tokens need to be migrated? The patch works with webform tokens without any problem.

I second fizk's remarks.

Maybe it wasn't totally clear that fizk's patch requires 'standard Drupal tokens' to be surrounded by double brackets (thanks to this being supported by token.module)? This way, there is no confusion between the webform tokens and 'standard Drupal tokens'.
So no need for migration, and we can have the two types of tokens coexist - especially because of these performance issues.

@quicksketch: would you consider a patch that introduces a setting for turning this token support on (defaulting to off) - with a clear explanation in that admin screen about the performance issues you mentioned?
(Checking this extra setting at runtime has near-zero overhead; it can be cached somehow in the static array that exists already in _webform_filter_values() )

For the time being, here's a patch that applies to webform 2.9 in case anyone needs it. (It's fizk's #15 patch with only minimal style things I needed to adjust for my own setup. #15 is still 'the' patch for 3.x-dev.)

Token support should be the #1 priority for the webform. That includes sorting out the performance issues highlighted by quicksketch...

But everyone knows that incorprating tokens module into webform is only a step forward for webforms.

The #1 priority is getting out a stable release of the 3.x branch. Better tokens are probably somewhere in the top 20, but I wouldn't say it's the highest priority in any way.

@quicksketch: would you consider a patch that introduces a setting for turning this token support on (defaulting to off) - with a clear explanation in that admin screen about the performance issues you mentioned?

I won't be adding options to turn on or off esoteric features that have unknown performance penalties.

So no need for migration, and we can have the two types of tokens coexist - especially because of these performance issues.

We should only use one token system.

My feeling is that this won't be fixed until we start making the D7-only version of Webform (4.x) because the token system in Drupal 7 is actually fast enough to not have performance problems like the D6 version.

quicksketch,

Better tokens are probably somewhere in the top 20, but I wouldn't say it's the highest priority in any way.

From all our comments, my impression is that you're not too enthusiastic about adding token support because you're very worried about the performance.

My feeling is that this won't be fixed until we start making the D7-only version of Webform (4.x) because the token system in Drupal 7 is actually fast enough to not have performance problems like the D6 version.

Can you give me links to token module performance tests? I've used token module a lot without any noticeable performance drop.

Anyway, a lot of people won't be upgrading to D7 right away, just like there still are people using D5. If you don't want to make a D6 version at all or any time soon, we might as well fork this module.

I know a lot of people that use Webform would love being able to use token module right now.

And to get a sense of how many people use token module, see http://drupal.org/project/usage/token

As if July 18th, 2010:    D5: 9,337 D6: 183,970 D7: 121

I know a lot people use token. Nearly every module I've written has token support. That doesn't mean that it's efficient. The performance problems were the reason that it was rewritten in Drupal 7, otherwise it would've just been moved in directly.

Just general comments here...

If you don't want to make a D6 version at all or any time soon, we might as well fork this module.

Well, forking is a big word... 'using a patched version' would be more appropriate :-)

I don't know about you, but I would not be able to live without my own repository containing a slew of patches, which I keep in sync with official versions.
(And that way of working will get much more common, because easier, with D8 development switching to git.)
That's not criticism; it's a fact of life that downloadable packages from Drupal Contrib don't "always just work", and that we need to put in the effort to contribute patches. >90% of which will end up Contrib downloadable packages again, through issue queues... eventually...

And it's also a fact of life that quicksketch is the man here. I disagree with token.module being an "esoteric feature" and I'm willing to bet lots of people want it, but for the rest... I won't claim to know what should be #1 priority. And I can totally see how token.module could cause performance hits for large reports.

(In the meantime, if you want a 'fork', make your own repo or follow the atom feed on mine, or someting :-) Unfortunately loggerhead does not have a feature to automatically create a tarball from a directory...)

Thanks for the suggestions roderik.

If anyone would like to have token support using the patch in #19, please check out the webform patched module.

http://drupal.org/project/webform_patched

Support for uprofile and profile2 is not appropriate to add to this patch. I would guess it needs to be *basic* token API calls only if it were even to be considered. You didn't help yourself by including stuff that was inappropriate for the patch.

Dave,

That has nothing to do with why the patch isn't accepted. The heart of the reason is performance concerns.

Yes performance is the blocker but I said "you didn't help yourself by including stuff that was inappropriate for the patch."
forks--

#4

Your patches also tried to lump in a bunch of other module tokens...so there was never a chance the current patches would be accepted.

While full on token support would be rad, I can see the inherent performance crush caused by _webform_filter_values() coupled with the D6 token module.

I'd like to suggest an alternate solution, whereby we add in two hooks to allow custom modules to define their own replacement tokens. The first hook would be invoked in _webform_filter_values, and would merely return an array of key => value pairs. The results of the hook could be statically cached to avoid pounding the system with multitudes of invoke_all.
The second hook would be in theme_webform_token_help() to display these newly exposed tokens in the UI.

This way, module developers would be free to define whatever replacement tokens they want, and have a static buffer between the performance hit of external modules. D6 versions of webform dont have to have explicit support for the token module or any other module for that matter, and we could avoid having forks like 'webform_patched'. It'd be trivial to implement a module that implements token support externally.

And perhaps it should actually be four hooks (two each for 'safe' tokens and 'unsafe' tokens).

If this sounds at all resonable I could probably put some time into rolling a patch, but I'd rather not if there's 15 things I didnt think about/know about as to why this is a bad idea/wont work. One area where I might be confused on is why *all* of the replacements are not static i.e.

 // Provide a list of candidates for token replacement.
  // Note these tokens are not cached as they may change frequently.
  $special_tokens = array(
    'safe' => array(
      '%get' => $_GET,
    ),
    'unsafe' => array(
      '%cookie' => $_COOKIE,
      '%session' => $_SESSION,
      '%post' => $_POST,
      '%request' => $_REQUEST,
    ),
  );

Do those really need to get set on every single call to _webform_filter_values() ?

Cheers!

Do those really need to get set on every single call to _webform_filter_values() ?

Probably not, but there's hardly any processing involved in assigning a variable from a global every time it is run. I may be wrong about that, but changing something like that is likely to lead to esoteric bugs in some form (for users injecting stuff into $_SESSION or $_COOKIE for example).

Introducing as a hook (or multiple hooks) sounds like it may work. Rather than including two hooks for safe/unsafe I'd probably prefer just to pass an argument to a single hook.

Is the performance problem here the basic behavior of Token, or the shear number and complexity of Tokens it would process?

In the latter case, defining a webform Token type might be a fix.

EDIT: The triple tokenization could be fixed with a wrapper function doing some static caching: $tokens[$webform_nid][$token].

+1

I was happy with the built in tokens for Webform until I found out none of them work for anonymous users except %get[q] which really gives you very little to work on. It seems to me most of us probably get our submissions from anon users.

While I don't think we need full token support we certainly need more that%get[q]. Just some basics like page title and a real url would help a lot. I read that you could run url() on the %get to get a real url but I don't see how you could do that in a hidden field value since it won't support a PHP input filter.

Mixologic thanks for posting this code chunk. As soon as I saw it I realized how easy it would be to move sessions back to being usable for anonymous visitors which is the norm for drupal. Much appreciated. The whole webform token system is a little wonky and would be better if it relied on the core token system but then again since I don't have the time or focus to make that happen I will simply smile and use what other have generously made for me.

I think this does not work in Webforms 3.4, right?

I need cck tokens for the sending email function. In the tab where I can set up the emailfunktion I can only choose between type by keyboard and take from a component, e.g. an email field. But what I need is a third option to get the Emailadress from a cck field. As far as the webform can be connected to a cck node, this should be possible, shoudn't it?

Is it be a big thing to bring that into one of the next releases?

Well, looks like there's been a discussion for adding Token support and I agree that this should be done. Like #4, I also use Domain Access and have multiple subdomains. I would like to setup a global form and use the site webmaster as an additional recipient, but this would require accessing Domain Access' different variables. Can you even use the current tokens in the recipient field?? Might I also suggest we rename this topic to:

Webform + Token Integration

Just a thought. It would stand to reason that it would make the module's life a hell of a lot easier to let Token do the heavy lifting and simply provide an additional group of tokens for Webform via Token itself.

I want to indicate, that there is a minimal support of tokens in edit component. But I'm not sure if that uses the token modul.
So what is missing are cck tokens to include values from a cck field from a node the webform is connected with. This should be added in the edit component part and also in the email setup part, as described in #37.

...right. I didn't believe that #27 would happen. Luckily the fork hasn't caught on, because it would be a maintenance nightmare when bugs started to get filed against it.

While upgrading to webform v3, I've tried to see if it was possible to create an add-on module which 'hooks into' webform (using hook_form_alter etc.)... but there's so many calls to _webform_filter_values() from different pieces of code, that it doesn't seem worth the effort, if it's even possible.

So while we're waiting for the birth of the hook mentioned in #32/#33... here's an updated patch for v3.4. (The patch in #19 actually did still work, though it applied with huge offsets. But it had some ugliness which is resolved in this one.)

Or someone who doesn't know how to use 'patch', can go to http://bzr.wyz.biz/drupal/6-patched/files/head:/sites/all/modules/webform/ , download webform.module from there (download link on the right), and drop it into the 'webform' directory.
(Unfortunately loggerhead does not have an option to provide tarballs.)

Of course with the remark that using this version could cause drops in performance (which is why quicksketch doesn't want to implement it in the main module)!

Subscribing, and also supporting quicksketch in his thoughts on the issue, to an extent. This is an awesome module, and there are a thousand areas where it can be improved—Token support being one of them. Please don't harass quicksketch over this (or any other issue), as he is obviously doing a ton of work on this module (and others), and will probably be a lot more amenable to adding in token support if we offered valid, nonaccusatory reasons for why we'd like it (regardless of performance implications).

For instance:

On my site, I'd simply like to use a [realname] token rather than %username, because some of my users' %username values are not supposed to be displayed for security reasons (silly IT requirement, but whatever...).

The only way to do this is to add Token support... and this is the first time I've ever had this requirement for a webform-created form I've made. Therefore, I would be willing to get a small hit in performance to add Token support :)

most of people looking to webform and cck as you should use one of them to solve your problems when i see if we use it together we can solve advanced problems like payment and more

if webform module can access token modules variables we can pass for example a price field when the webform can charge this amount of money for us so there is a kind of compatibility here only if there is a connection This connection is "WEBFORM MODULE MUST USE TOKEN MODULE."

@quicksketch/#33:

A new webform hook, which caches the gathered extra tokens? Something like this?

(I named it hook_webform_replacements()... until I came across theme_webform_tokens => named the 2nd one hook_webform_tokens_help() => renamed hook to hook_webform_tokens() )

Somewhat off topic trivia:
I've already been punished for my arrogance of 'just' hacking token support into this module, which submits webforms & was gathering $node tokens in during the hook_nodeapi($node, 'view') phase. :-)
And paid penitence by patching other modules so they don't recurse (because they try to rebuild $node) and cause grief.

I predict a certain amount of Issue Queue Fun for whoever goes on to upload & support a contrib module which does webform-token support :-)

[ other readers: #40 still applies if you want unsupported webform-token integration right now. ]

So I read over this for the fifteenth time and see that my comments in the 'Rules:' section don't match the code behaviour.
Rewrote that comment section.

(I've probably been too wordy because it's only 'internal' comments that are not seen by hook implementors, but I needed to write that out to keep from getting confused.)

This is absolutely fantastic. I'm working on a module that absolutely needs this feature. I have tested #44 and it works great!

I'd like to make one small addition to it, though: Add $email to hook_webform_tokens(). My module actually adds values at the $email level, so I really need the value of the $email itself to be fed to the hook. To make this work, I also had to add $email['eid'] to the $extkey caching mechanism.

Re-rolled patch attached.

My module actually adds values at the $email level

Doublechecking:
- does your module modify $email itself?
- or does your module use values in $email, to generate token values which it returns (for use in e.g. some random place in the message body)?

I'm asking because your change will mean that the token generation is run twice per submission, always* -- which is usually superfluous processing. So I'd like to make sure that what you are doing, can't be done in e.g. theme_webform_mail_headers or some validate function added to webform_client_form.

* lots of places, _webform_filter_values() is called with no $email argument. In one place, it's called with $email set -- which isn't completely built then, by the way.

--Deleted. Sorry, duplicate submission.--

--Deleted this one too. Drupal.org wasn't refreshing the page, so I didn't think it was submitted. Sorry.--

My module does not edit $email. But I need $email->eid passed to hook_webform_tokens() because it processes my custom token differently for each $email->eid.

...ok.

I tried to work out a theoretical situation where I'd prevent token hooks from being fired twice for every e-mail, by forcing you to read/modify $email somewhere else.
And failed :-)
(I believe e.g. theme_webform_mail_headers() does not allow you to modify $email as it isn't passed by-reference.)

(The only way I see is to introduce another module_invoke_all(), i.e. probably introduce a second hook with another name... one call with, and one without $email as argument.
Idunno...............
*still keeps status at needs review*)

@roderik, that's not strictly true. I just tested it using step-through debugging.

Token hooks are only fired once per $email->eid. They're also fired once with $email = NULL (from webform_format_email_address() and others), as well as once with $node = $submission = $email = NULL.

For example, given a submission where $nid = 3, and $sid = 1:
--If there are no emails configured, token hooks are fired once. ($extkey = 0-0-0)
--If there is one email configured, token hooks are fired three times. ($extkey = 0-0-0 and 3-1-0 and 3-1-1)
--If there are two emails configured, token hooks are fired four times. ($extkey = 0-0-0 and 3-1-0 and 3-1-1 and 3-1-2)
--If there are three emails configured, token hooks are fired five times. ($extkey = 0-0-0 and 3-1-0 and 3-1-1 and 3-1-2 and 3-1-3)
etc.

Ideally, it would remove one of those firings if webform_format_email_address() and others were to also pass the $email variable to _webform_filter_values(). It does not, which is why we get $extkey = 3-1-0. Unfortunately, several functions call _webform_filter_values() without the $email parameter, so we're not likely to get past that. My hook doesn't process anything if !$email.

Just know that it's not necessarily duplicating the hook fires, just adding one per $email->eid.

Subscribing

Subscribing

Patch @45 worked like a charm for webform 6.x-3.4.

I really hope this gets into the module. It has really given my users the ability to add their own webforms with data auto filled in for their users and making everyone happy and a better experience overall.

Cheers!

subscribe

@FatGuyLaughing found a small bug when anonymous users try to view a form with tokens. This patch is re-rolled off of CVS today with the bug fixed.

@Shawn DeArmond thank you for the quick response and the new patch. Most people don't respond like that. Patch has been tested and works without any issues.

Cheers man

This patch looks really good. Thanks Shawn DeArmond and roderik for your great work on this. However there are some areas that I've got concerns about:

- This little bit of code is terribly confusing, could we simplify?

+  $extkey = (isset($node) ? $node->nid : 0) . '-' .
+      (isset($submission) && isset($submission->sid) ? $submission->sid : 0) . '-' .
+      (isset($email) && isset($email['eid']) ? $email['eid'] : 0);

- The "%" character is forced to be part of the token, I'd prefer this were not necessary to include when defining tokens and instead was added to the tokens in _webform_filter_values().

- This entire approach is sadly entirely at odds with the D7 token system, which generates tokens as-needed instead of generating large lists of tokens in one giant batch (often generating hundreds of unnecessary tokens). This makes using this system on D7 difficult, or at least entrenching our inefficient system in a way that would require reworking in D7.

So while I think that this general approach is quite good for D6, I'm unlikely to add it to the project until we also figure out what to do about D7. Perhaps that discussion should actually continue over here: #1001798: Rewrite token replacement system to use D7 tokens

I re-rolled the patch to account for some of #58. I cleaned up that confusing code, and made it so that _webform_filter_values() adds "%" to the token keys instead. I also updated webform_hooks.php to reflect the changes.

As for the D7 token system, I'll look into that issue and attempt to imagine how the conversion would work. Actually, since we're now adding the "%" token keys in _webform_filter_values(), it wouldn't be difficult to (for D7) instead wrap it in brackets a la D7 tokens.

@ Shawn DeArmond / #51:
Thank you for testing this. In my head didn't take into account the situation where $submission is NULL. I guess I should go through the code again and think about whether we can prevent some hook firings on "-0" - haven't done so. And if we can't, your patch is perfect.

@quicksketch:

This entire approach is sadly entirely at odds with the D7 token system

...which is not your problem.

Just playing devil's advocate here (? maybe. I do actually think it isn't your problem.)

If you implement a hook now (instead of any direct support for e.g. D6-token.module), then this saves you the headache of being responsible for whatever funny code (and timing issues) someone decides to implement as hook implementations in their custom modules. In hindsight I agree that this is way better than adding direct D6-token.module support.

And you are also not responsible for providing an upgrade path for their possibly-funny code.
(token.module in D6, for instance, is as much at odds with the D7 token system, as this D6 hook_webform_tokens() is. Using the D6-style way of implementing tokens is also difficult -if not impossible?- in D7... But it didn't stop them from dropping hook_token_values() in D7... :-) )

All you might do is add text to the README, that people will probably need to rewrite any hook_webform_tokens() implementations, and they will probably be needing to use the D7 token system for it in D7, and details are still forthcoming. (I don't see a problem with the "details are still forthcoming" part. I am expecting the functionality to 'get e-mail and submission values' to be present in the D7 webform module in some way, and am not worried about the exact way I'll need to rewrite my token hook_webform_tokens() implementations in D7, to achieve the same result.

( @Shawn DeArmond: are you? )

Or am I looking at things the wrong way?

(I'm holding off on trying to add optimizations as indicated above, until I know that at some time in the future, the code will actually be considered for inclusion and the adding of roadblocks will stop. It works well enough for me, right now.)

subscribe

Probably not adding much and maybe discussed as I admittedly haven't gone through this whole issue in detail, but an external token replacement module is probably very easily implemented. I actually did something like this better tokens and even add a few others, but this can be easily extended to support tokens module, and maybe just commen:

Basically a module implementing hook_webform_submission_presave($node, &$submission)

and doing something like this:

(note, this is just an idea of a code, haven't actually properly tested)

function MODULE_webform_submission_presave($node, &$submission) {
  foreach ($node->webform['components'] as $key => $component) {
    // look for [xxx] tokens
    $match = preg_match('/\[.*\]/', $component['value']);
    if ($match) {
      $submission->data[$key]['value'][0] = token_replace($submission->data[$key]['value'][0]);
    }
  }
}

All the performance worries and warnings in here probably apply, but it might be a quick work around for anybody needing something quick without resorting to a patched webform.

Anyway this issue looks like close to a resolution, but, thought might be interesting to share this.

I tried to add one of these patches, but all of them do not work in my system. I use webforms 3.6 and applying the patch works. But after adding one of these patches my webside is broken and I get this error in browser:
Fatal error: Call to undefined function webform_menu_load() in C:\xampp\xampp\htdocs\eemission\drupal\eemission_work\includes\menu.inc on line 410

Whats wrong here? Can anybody help?

Thanks

PS: I use a test environment which is win 7 and xampp. Maybe thats the problem?

Ok, I could fix that problem. The patching engine mixed up the rights so that drupal didn't had rights to execute. Sorry I could have see that before.

But another question: I thought that I would get some tokens in the edit component option to insert some tokens. But I still can not see anything. Do I need an additional module to get tokens into the edit component of webform? Which module?

Thanks

@majorbenks: This functionality adds an API so that other modules can hook into webform and contribute their own tokens. There are no modules on d.o that implement these hooks yet, because this functionality is not yet committed to webform.

If you want to write a module and test the hooks, please add your experience in a comment here.

I do have that code working - just didn't release it immediately, because I figured people could still apply #40.

I have NOT changed this code to work with Shawn DeArmond's latest patch; my own site does not work with the 'mandatory prefixed %' yet.
So I guess if you want to use the below code as-is, you should use '%[[token-key]]' in your text.
And if you want to use '%[token-key]', you should delete the ", '[[', ']]'" from all function calls. Untested.

function MYMODULE_webform_tokens($node = NULL, $submission = NULL, $email = NULL) {
  // Token module replacements
  global $user;
  $info = array();

  $tokens = token_get_values('global', NULL);
  if ($tokens->tokens) {
    $info['safe'] = array_combine(
        token_prepare_tokens($tokens->tokens, '[[', ']]'), $tokens->values);
  }

  $tokens = token_get_values('user', NULL);
  if ($tokens->tokens) {
    $info['unsafe'] = array_combine(
        token_prepare_tokens($tokens->tokens, '[[', ']]'), $tokens->values);
  }

  if (isset($node)) {
    $tokens = token_get_values('node', $node);
    if ($tokens->tokens) {
      $info['unsafe'] += array_combine(
          token_prepare_tokens($tokens->tokens, '[[', ']]'), $tokens->values);
    }
  }

  return $info;
}

subscribe

Re #59, I'm having an interesting problem where hook_webform_token_help is overriding the function theme_webform_token_help. Anyone else experiencing this?

Shawn

...and I just discovered why, in case anyone runs into the same problem... my module with the hooks in it is named the same as my theme... silly me.

Shawn

subscribing

hello,

i understand that this patch we are discussing is just an api and it doesn't do anything by itself.
i need to ask how to make it something to work with, i need to see the tokens in the (token values) tab.

can someone guide me or just provide the patch as a working module ??

thanks in advance

can anyone reply this please, that will be so helpful
i'm in the middle of a project and this gonna help me a lot.

thanks in advance

Be more specific. Your general remark about "provide the patch as a working module" seems to suggest that you don't fully grasp what is being discussed here. (Webform will never support 'token-tokens' directly in one patch/working module.)

Read #65, #66 and #67. I believe you should either be able to show what you tried & what specifically did not work for you / you don't understand about the code in #67... or you need to pay a consultant for help anyway (because he will need to help you with more than just a reply).

demonrage,

Also look at http://drupal.org/project/webform_patched . You can use webform_patched for now, while you're waiting for this issue to be resolved.

@fizk

thanks so much, that was what i really needed.

Re-roll to v3.11.

I finally adjusted my own repository to include ShawnDeArmond's latest patch. And accounted for the results in #51.... by changing comments in webform_hooks.php.

The webformtoken.module file is the example 'glue code' to the Token module which I'm using together with this patch. (A better version of #67). It should have performance advantages over the Webform Patched module.

Subscribe.

I tryied out these patches. They are great. But I wonder if it would be possible to put in cck-fields also?

i been looking the solution quite a while for profile2 token to webform. I found this http://drupal.org/node/968226 .It written that need to enable entity metadata. I don't know how to do it.. i very confused, i hope someone could make a step by step for this. Appreciate it.

Regards,
Novex
novex@ideaninfotech.co

@Novex

See:
http://wolfgangziegler.net/introducing_entity_metadata
But its only for 7.x
This thread is about 6.x

A bit slow, but anyway now I get it. Adding tokens for a node or any contenttype would be easy by adding its type into the webformtoken module (now 'global' and 'user' are added). But actually the problem is getting 'in touch' with the node / contenttype that is meant. The webform itself is the only available node. 'global' and 'user' data is also available, therefore that data is available through webformtoken. Any other needed data must first be passed to the webform.

#1001798: Rewrite token replacement system to use D7 tokens is now finished, though we had to branch Webform for 4.x to introduce the feature, since we can't just change out the token system on 100,000 active sites. That issue only helps Drupal 7 however, and I'm still not sure what we should do about this issue and Drupal 6. Right now we're able to provide an upgrade path from 3 to 4, but introducing new tokens will mean we can't provide an upgrade path for tokens we don't know about.

At the risk of sounding like a fool (because I still don't get the issue)...

... so what?

Does D7 provide an upgrade path for all D6 tokens that people provide in the modules they've written? Heck no. It's not your problem. What I said in #60.

People will love you for the possibility to provide their own tokens, in 'webform contrib' code. People who write contrib modules know that they need to significantly overhaul these, with each major version upgrade.

Re-roll against 3.18 attached (only because webform_hooks.php was renamed).

@roderik: Intentionally introducing un-upgradeable features is not exactly "expected behavior". Just because contributed modules regularly have bad (or non-existent) upgrade paths doesn't mean that we should intentionally create a situation like that. For now my take on this is mostly that you should use hook_form_alter() in a custom module to populate defaults if needed.

After resisting this issue for 3 years, and finally providing a solution for the current version of Drupal, I don't think it's likely that we'll see this added to Drupal 6. Considering the branching of a new branch of Webform, the 3.x branch will quickly go into maintenance updates only.

Intentionally introducing un-upgradeable features is not exactly "expected behavior".

Yes it is.
We're looking at this way differently.

Providing a hook (== giving the user to extend your stuff with code, be it Drupal Core or Webform) implies not having an upgrade path. In general, there is never any upgrade path for code that sits on a hook. Your reasoning sounds to me like being against form_alter hooks... because whatever the users do on that a form_alter "does not have a good upgrade path to D7".

*..shrug* oh well. I guess you are worried about people mistakenly blaming Webform for non-upgradeable fuctionality that is in fact not provided by webform but by some custom module.
And tbh by now there aren't that many people who want this in D6. Well played :-p

*grumble grumble* I was personally perfectly happy with my #40 patch, before you mentioned creating a hook *grumble grumble*

... OK I'm over it now ;-)

Congrats on adding token support to webform 7.x-4.x.!

roderik, There's about 100 D6 and 50 D7 reported users of webform patched. I guess it's not a whole lot, but I'm sure those few really enjoy their token support.

Sorry @roderik, I think you're right on pretty much all counts. I'm always trying to do it "right" and often times that means delaying the functionality until what I consider to be the "right way" actually becomes possible. Lots of people use Rules module every day (in D6 and D7), as it happily gobbles up 160MB of RAM generating tokens and tacking on a second or two of processing time. Just looking over at http://drupal.org/project/webform_rules you can see at least a couple thousand users don't have a problem with it.

Often times when I *do* bend and put in things against my judgement, I end up with a lot of code that is either un-upgradeable or I'm just not interested in working on it (because I didn't like it to begin with and don't need it). It's this exact reason why Flag module still doesn't have a stable release for D7, because there's too much code that I don't like in it or that is dependent upon other modules making it too difficult to stabilize (including Services, Rules, Session API, Token, Translation Helpers).

Ultimately it's a somewhat selfish approach to module maintenance, but unless I can successfully recruit permanent maintainers I'll put my own interest to reduce maintenance overhead over features. I know you're saying it's not adding overhead at all because it's "not my problem", but as long as people get responses in the Webform queue they'll keep asking questions, whether it's my problem or not.

Moving into won't fix. Though I'm loath to recommend it you can use Webform Patched to get this functionality in Drupal 6. The 7.x-4.x version of Webform is stable as long as you're not using add-on modules with Webform that haven't been upgrade yet.