On a barebones site, I'm trying to get a hidden field to be populated by the NID. I think I should be able to use the node token %nid in the field to do this automatically, but when I do it I just get a literal '%nid' in the form submission.

I've worked around this using URL arguments - now I have links that point to node/78?node=78 . I have no problem pulling that out with get[node] .

In testing this, I found I also get a literal submission using %title , so it seems to be just Node tokens affected.


Murz’s picture

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

choosewisely’s picture

I am experiencing exactly the same issue. Subscribing.

P.Selfin’s picture


sapox’s picture

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

jibran’s picture


ecksley’s picture

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

imclean’s picture

Version:6.x-3.11» 6.x-3.x-dev
Status:Active» Needs review
2.01 KB

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.

imclean’s picture

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

imclean’s picture

2.02 KB

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

quicksketch’s picture

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

elgandoz’s picture

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?

quicksketch’s picture

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.

quicksketch’s picture

Title:Node tokens (provided by Webform) don't work» Node tokens (provided by Webform) don't work as default values

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

jaymallison’s picture

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)

koppie’s picture

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.

imclean’s picture

Title:Node tokens (provided by Webform) don't work as default values» Node tokens (provided by Webform) don't work as default values or description
15.19 KB

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.

imclean’s picture

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'],
eflage’s picture

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

jfine’s picture

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.

jfine’s picture

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);
filsterjisah’s picture

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

imclean’s picture

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.

Anybody’s picture

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?

micke793’s picture

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

quicksketch’s picture

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

Marko B’s picture

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]" ?

quicksketch’s picture

Marko B’s picture

thanx quick

nodecode’s picture

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

quicksketch’s picture

Status:Needs review» Reviewed & tested by the community

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.

imclean’s picture

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.

quicksketch’s picture

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.

quicksketch’s picture

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.

quicksketch’s picture

Status:Reviewed & tested by the community» Fixed

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.

imclean’s picture

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!

Status:Fixed» Closed (fixed)

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