Node tokens (provided by Webform) don't work as default values or description

Expiring same problem and can't find the solution, subscribe.

I am experiencing exactly the same issue. Subscribing.

Subscribing

I need too the %nid token, but it is not working.

Subscribing

Subscribing... noting this is also an issue for 7.

The node object needs to be passed to _webform_filter_values() for these to work. Looking at the render functions for the component types hidden and textfield this doesn't seem to be happening. Here's a patch to fix it for those types by simply loading the node again and passing it on.

I wonder if a better way would be to pass the node object from _webform_client_form_add_component() to the component's render function somehow, although this may change the API.

This only provides the webform node object itself. If you're using webform in a block it may not be so helpful.

Try this instead, it grabs the nid from the URL so works with blocks. Should components be providing this information?

The first patch is "correct", the node tokens are not intended to reflect whatever node page you are on.

subbing.
the node tokens are not intended to reflect whatever node page you are on.
I do not understand this. It's extremely useful use the tokens in that way (provide the current node).
It would be extremely easy in this way put the classic "product name" in the "more information form", usually a block.
Why don't provide this behaviour by default?

Tokens are always intended to reflect the node on which they are used. I agree that having "current node" tokens may be useful, but that's not the expected or typical behavior of tokens.

Updating title. Node tokens do work in other places (such as in e-mails).

Actually, they don't work. %title won't render in emails on 7.x-3.12 (I was sent here from the 7.x issue since it was closed)

I had the same problem. I have a webform in a block and I need it to pull an email address from a View and mail to that address. I'm using Webform PHP, in spite of the developer's grumbling, because it really is the most expeditious way to do what I need to do. In terms of it being a bad idea to expose raw PHP on a Drupal site, that horse left the barn a long time ago (at least on my site). The real key is only giving access to trustworthy users.

Anyway I'm using Webform PHP to load the View, get the email address, and send the email. Webform still has trouble getting the NID when it's embedded as a block, so I created a hidden Webform field and used javascript to populate it with the nid.

Hope that helps.

Patch based on #7 for all components where it makes sense to me. This also includes calls to _webform_filter_descriptions() which I missed the first time round.

I haven't tested but it looks ok.

Alternatively, something like this:

function _webform_client_form_add_component($node, $component, $component_value, &$parent_fieldset, &$form, $form_state, $submission, $format = 'form', $page_num = 0, $filter = TRUE) {
  $component['node'] = $node;
  ...
}

function _webform_render_textfield($component, $value = NULL, $filter = TRUE) {
  ...
  '#default_value' => $filter ? _webform_filter_values($component['value'], $component['node'], NULL, NULL, FALSE) : $component['value'],
  ...
}

Just tried the patch from #9, it worked beautifully for what I'm trying to accomplish. Thanks!

Just ran into this issue myself. I am using a Webform block and trying to pass URL (or similar) in a hidden field since the block is on multiple pages and we're interested in seeing which page the user submitted the form from.

I understand limiting access to %server due to caching of GET pages though there are a few %server variables that would be handy to have and shouldn't cause an issue with cached pages. For instance in my case %server[url].

For those looking for an immediate solution, you can simply use jQuery to set the value of your hidden field.

// Update hidden input value in a webform
$(function() {
  $("#webform-id #hidden-input-id").val(location.href);
});

@patchers, better use menu_get_object() to load current node object instead of checking args

Or better yet, use neither. See #10.

This would be good to get resolved properly. I'm leaning towards the method in #17 to use the existing node object, it'd be nice to get some feedback.

I'm having the same issue and it would be great if this could be fixed generally. Is there still work in progress to get this into the next release perhaps?

Do you have any patch for default value like: %profile[field_XXX] who work in D7 too? :-)

I've marked #1224130: %title token in Webform duplicate, but it contains a lot of other helpful posts also.

I would like to use cck fileds as tokens. I want to have cck field tokens from current node so i can access it in webform block. I have an email address in node cck file and want to use it in webform block form, should i just use webform php for this? i tried pateched 9 and 16 but they didnt help or maybe i am accessing it wrong tried "%node[field_email]" ?

I would like to use cck fileds as tokens.

See these other issues:
#1001798: Rewrite token replacement system to use D7 tokens
#428982: New hooks for additional token replacements

thanx quick

What needs to happen for this issue to move forward and get a patch committed? I need this for D7.

imclean's #16 looks really good. There are a couple minor spacing issues (a space after commas), but really I can take care of that when I apply the patch. My concerned are around the number of extra calls to node_load() (once per field), but since that is static cached, I don't think it should really be that bad of an issue.

This patch is necessary even if #1001798: Rewrite token replacement system to use D7 tokens is completed, so I don' think I can delay the requirement of it. I'm just a bit leery about it because loading the node instead of passing it in as a parameter doesn't seem "right", but it will clearly work. Without breaking the existing APIs of the 3.x version I think this is probably about as good a solution as we can get.

So in short, I think this is good to go. Further testing is always appreciated by anyone who is interested in this before (or after) it's committed.

Without breaking the existing APIs of the 3.x version I think this is probably about as good a solution as we can get.

Considering the tokens don't currently work, would my suggestion in #17 break the API in any meaningful way? This passes the node as a parameter within the $component array.

Considering the tokens don't currently work, would my suggestion in #17 break the API in any meaningful way? This passes the node as a parameter within the $component array.

No that wouldn't cause any API breakage immediately. However that gets us into an uncomfortable position where $component sometimes contains some stuff that is there some of the time and not others. Right now a $component is a $component, and it's always the same everywhere (thought as this patch demonstrates, sometime things are NULL, like 'nid' when you're creating a new node). Entire properties being there some of the time is prone to error. So even though the approach in #17 would also work, I'd prefer #16.

The patches from #16 didn't apply very cleanly to the 3.16 version, since we rewrote the file component for Drupal 7, turned the "email" field into an HTML5 field, and introduced the "number" component. These patches apply the changes to all the new components and ports the patch to both versions.

Committed to both branches. Thanks @imclean for the patches (and feedback)!

I still have every intention of finishing up #1001798: Rewrite token replacement system to use D7 tokens, which complements this issue (so you could use any node property you liked, rather than just %nid and %title). It may also be able to solve people's requests for "the current node" tokens, which token module could at least theoretically provide, even if it's not available by default.

Right now a $component is a $component, and it's always the same everywhere

Ah yes, it probably isn't a good idea to hijack it for other purposes. Good to see this issue resolved!