Aug 17, 2011 UPDATE

The basic field tokens have been committed to 7.x-1.0-beta4 release. We are working on part two which involves writing tests for the base-level tokens, and supporting more detailed, nested tokens. For developers looking to start integrating their module's fields with tokens, please read http://drupal.org/node/1252608.

Subscribing to updates on this issue

Comments are now locked as this issue has become too long with too many 'Subscribe' comments. If you would like to stay updated on the progress of this issue, join the Token group at http://groups.drupal.org/tokens (you must be logged in to drupal.org to join). I will be sending out e-mails to all of the group's members with major updates to this issue.

Problem/Motivation

We need field tokens for Drupal 7. This capability used to be provided by CCK, but CCK was moved into core without this functionality, and Drupal 7 shipped without it in order to meet its release date. This issue is discussing how to add this capability back to Drupal 7, with the advent of the new Field API in D7 core.

This issue will act as a primary communication mechanism for major happenings around this important issue.

Proposed resolution

Details of proposed resolution can be found in the following sub-issues.

Remaining tasks

If you are a developer interested in helping to see this issue fixed, please help unblock the following issues:

* #1222592: Architecture RFC: Field token architecture
* #1195874: Need to figure out how to create nested tokens from the array token type
* #1058912: Prevent recursive tokens
* #1252714: Easily allow a 'token' view mode to override token display settings

If you are a site builder who needs access to field tokens, please do NOT subscribe to those issues (which will add noise to the discussion), but instead subscribe to this one; it will be updated with major happenings when they occur.

A side note that if you need simple node/term tokens, you should be looking into using the http://drupal.org/project/taxonomy_entity_index. It provides a [node:terms] token so that you can use [node:terms:first] to get the 'first' term associated with a node, just like the Drupal 6 [term-raw] token.

Original report by Deciphered

// Text of original report here.
(for legacy issues whose initial post was not the issue summary)

It doesn't appear that Fields are exposed to the Tokens system?

Seems like a fairly major oversight to me.

Cheers,
Deciphered.

Files: 
CommentFileSizeAuthor
#515 691078-466_same_as_462.field_tokens_remake.patch24.62 KBts145nera
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-466_same_as_462.field_tokens_remake.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#470 691078-466_same_as_462.field_tokens.patch21.33 KBalphageekboy
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-466_same_as_462.field_tokens_0.patch.
[ View ]
#466 691078-466_same_as_462.field_tokens.patch21.93 KBGiorgosK
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 691078-466_same_as_462.field_tokens.patch.
[ View ]
#463 691078-462-field_tokens.patch21.79 KBBevan
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-462-field_tokens_0.patch.
[ View ]
#320 field_tokens-691078-320.patch22.08 KBDeciphered
FAILED: [[SimpleTest]]: [MySQL] 0 pass(es), 14 fail(s), and 0 exception(es).
[ View ]
#318 field_tokens-691078-318.patch22.08 KBDeciphered
FAILED: [[SimpleTest]]: [MySQL] 44 pass(es), 15 fail(s), and 0 exception(es).
[ View ]
#280 modules_token.280.patch22.06 KBDeciphered
FAILED: [[SimpleTest]]: [MySQL] 44 pass(es), 15 fail(s), and 0 exception(es).
[ View ]
#262 token.module.txt30.88 KBdamien_vancouver
#262 token.tokens.inc_.txt49.71 KBdamien_vancouver
#238 URL aliases | The Urban Child Institute.jpg43.56 KBsafetypin
#143 modules_token.92.patch19.59 KBpillarsdotnet
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch modules_token.92.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#118 field-token-edit-instance-templates.png62.47 KBmanimejia
#118 field-token-templates-display-formatter.png144.53 KBmanimejia
#92 691078-token-field-tokens-v2.patch20.6 KBDave Reid
PASSED: [[SimpleTest]]: [MySQL] 205 pass(es).
[ View ]
#77 691078-token-field-tokens.patch21.41 KBDave Reid
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#60 691078-token-field-tokens-D7.patch21.41 KBDave Reid
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens-D7_2.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#43 691078-token-field-tokens.rfay_.patch23.6 KBrfay
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens.rfay_.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#42 691078-token-field-tokens-D7.patch23.6 KBDave Reid
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens-D7_1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#34 691078-token-field-tokens-D7.patch23.6 KBDave Reid
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens-D7_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#32 Selection_111.png61.41 KBDave Reid
#30 691078-token-field-tokens-D7.patch22.19 KBDave Reid
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens-D7.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#30 Selection_110.png88.11 KBDave Reid

Comments

Deciphered’s picture

Title:Field Tokens?» No Field Tokens in Drupal 7?
Priority:Normal» Critical

Bumping and marking as critical, I'm unable to port a few of my modules until this issue is resolved.

Cheers,
Deciphered.

eaton’s picture

It doesn't appear that Fields are exposed to the Tokens system?

That's correct -- it was noted in the original token patch, which landed before Taxonomy and Title/Body became Fields.

In D6, each field type was able to expose its own tokens -- I imagine that we'll need something similar here. I'm not up to speed on the internals of the Field system, and I'm pretty sure that the addition of language (as well as the assumption of multi-value fields in all instances) will make coming up with consistent and concise tokens an interesting challenge.

Is there anyone who has thoughts on how we might approach this?

webchick’s picture

Issue tags:+i18n sprint, +Fields in Core

Tagging for the i18n and fields in core teams to look into.

eaton’s picture

Based on existing conversations:

Token currently uses entity prefixes to identify what 'kind' of thing tokens are being generated for. For example: [node:title] or [node:author:email]. Ideally, the fields system would just make each field attached to an entity-type a valid token. For example: [node:field-event-location:latitude] would allow the 'location' field module to spit out the 'latitude' property of the 'event location' field. That's pretty much how it worked in D6, though some conventions (like 'use dashes, not underscores -- just like URLs' and 'the default [node:field-name] output should be the simplest text-only representation of a field's data possible') would be nice.

The multi-value fields and multilingual fields really are the trickiest problem. Some people have asked for tokens that are basically 'a comma-separated list of each entry for a given field.' [node:vocabulary-name:all-comma] might spit out a comma-delimited list of all the tags on a node from a given vocabulary, for example. These kinds of rules are a little maddening to document though: I have the nagging feeling that we should provide for the simplest common case and leave the rest up to contrib. Adding new tokens to existing objects isn't that nasty.

Specifying specific instances of a field and specific languages (like [node:tags:3:en] for the english version of the third taxonomy tag on a node)? Relying on the current 'language' passed into token_replace() to specify the language? I'm not sure which approach is correct. Those are the questions that need to be ironed out, and if we can figure how to make it consistent, that would be AWESOME.

Deciphered’s picture

He Eaton,

Just a quick note, why not have the langcode specified in the token_replace() call (or the appropriate D7 version) instead of in the token itself?

Would go further into detail, but I'm running late for work.

Update: I had another thought on my drive to work, regarding multi-value tokens, why not have token 'formatters', or themes, where by default mutli-value tokens are defined as an array of values, and if you don't define a specific token formatter they will get processed by theme_token_default() which would simply implode the array, possibly even with comma separation.

That way you could allow for developers to define there own formatters to get exactly what they want out of the multi-value token.

I understand that both of these thoughts are likely unachievable given the code freeze, but no harm in having thoughts right?

Cheers,
Deciphered.

yched’s picture

I, on the other hand, am not too familiar with the D7 token syntax and how much we can bend / fit into it :-/.

For the record, I think formatters (at least in the sense of 'Field API formatters', or 'the formatters used when displaying fields') should be left out of tokens.

- Formatters are here to generate sanitized HTML. Basic text formatters output a string, but with others on other field types you'll get divs, a's... Some of them output some pretty heavy HTML, too (the file_table formatter for file fields spits table markup). That doesn't fit with the scope of tokens.

- in D7 formatters can have settings, which becomes unmanageable in tokens (well, although the lack of UI for formatter settings in core's current Field UI might very well make the feature born dead)

Each field type (or contrib modules) can choose to provide 'variants' for the tokens on a given field type, but IMO this is a different animal than formatters.

Deciphered’s picture

Yched,

Yes, maybe it was a bad choice of terminology, but the idea is the same, have a default token 'style' (comma separated) and allow users/developers to define their own 'styles' and/or choose a style. That way it wouldn't be an issue of one module defining their multi-value token one way and someone else another way.

Either way, I would be happy accepting any option as long as we get field tokens, because at this stage I will just not be able to port my modules to D7.

eaton’s picture

I, on the other hand, am not too familiar with the D7 token syntax and how much we can bend / fit into it :-/.

It's pretty flexible, and the date related tokens give a good indication of how they work. [node:created] prints the short date, while [node:created:medium] prints the medium date, [node:created:custom:YYmm] prints the date in YYmm format, and so on. The date related token handling code just says, 'anything in the 'node' namespace that starts with 'date', I'll handle. If there are trailing elements, I'll use them to change the output."

Just a quick note, why not have the langcode specified in the token_replace() call (or the appropriate D7 version) instead of in the token itself?

You're right -- token_replace() already takes locale information, so there may not be any need to explicitly make it part of the user-entered token.

For the record, I think formatters (at least in the sense of 'Field API formatters', or 'the formatters used when displaying fields') should be left out of tokens.

There are situations where tokens are provided for large HTML-rich chunks of text. Node bodies and teasers, for example, could be inserted into an outgoing comment notification email. In D6, 'token' is one of the display modes that you assign a formatter to, just like 'teaser' or 'full' or 'rss'. I can see where many formatters would be inappropriate, though. a JS slider is never going to make sense, while the 'link' versus 'path' formatter for a FileField might make sense.

Basically, for every field, I'm suspecting that we need to expose:

  • a default token for each field at [entity-type:fieldname]
  • A sub-token for each data element in the field, like [node:field-image:path] and [node:field-file:mimetype]
  • A way for field-providers to provide alternative tokens (like [node:field-startdate:year])
  • A way to specify an individual delta for a multivalue field. How should this work? [node:field-image-2:path] or [node:field-image:2:path]? I'm not sure.
  • A way to specify that tokens for ALL deltas should be generated. How should that look? [node:field-image:all-commas:path]? Hmmm.

Thoughts? Anyone?

jide’s picture

Just a few thoughts...

About multiple fields, it could be nice to make the "all deltas" display the default, so that [entity-type:fieldname] outputs all the values. It would make sense since when viewing the fields on a node, their default display is similar to "all deltas".

I like the idea of "light formatters" or styles from Deciphered in #7, it would bring a lot of flexibility without all the weight of real formatters. Just an idea, couldn't we let modules define styles and then call them by using [entity-type:fieldname:style] or something ? But maybe this is exactly what Deciphered was thinking about.

If I'm not wrong, using formatters from display modes as it's done in d6 limits the user to one format per field, when you could want to use different outputs for different situations.

This approach could be used instead of alternative tokens in some cases maybe ? After all, we could consider [node:field-startdate:year] as a format / style ?

chx’s picture

Title:No Field Tokens in Drupal 7?» Field tokens
Project:Drupal core» Token
Version:7.x-dev» 6.x-1.x-dev
Component:field system» Code
Category:bug» task

This does not belong to core. Way, way, way too late. As CCK continues to exist with node reference, user reference so should token.

eaton’s picture

This does not belong to core. Way, way, way too late. As CCK continues to exist with node reference, user reference so should token.

I'm not opposed to this; Token will continue to live on in core as a place for new tokens and UI mechanisms for presenting tokens. If need be, it can hold field token code as well.

eaton’s picture

(er, rather... Token will continue to live in CONTRIB)

yched’s picture

If I'm not wrong, using formatters from display modes as it's done in d6 limits the user to one format per field, when you could want to use different outputs for different situations.

True. CCK D6 'token display as build mode' was more like a hack, never really flew IMO.

I guess we can live with the [node:body], [node:taxonomy] and [node:field-foo] tokens requiring contrib Token module, that cannot be called a regression. It just becomes the job of Token to implement the token-by-field-type collection mechanism, and to expose tokens in the name of core field types :-/

Eaton's proposals in #8 sound good.

re: Single value / all-values / separator :
- Is it technically doable to push them at the end of the token ? [node:field-name:variant:2], [node:field-name:variant:all:comma] ?
Can a generic 'multiple values handler' catch the end of the token and massage the results provided by the 'variant', or is it the job of the 'variant' provider to handle anything that's behind in the token ? (er, not sure I'm being clear..)
- Off hand, I'd rather lean towards making [node:field-name] be 'only the first value' by default (vs 'all values'), but that might be a personal opinion, no strong arguments here.

Deciphered’s picture

My biggest concern is that previously (D6) there was two different types of a field token, one for the individual field when passing the field as an object, and one with the first field on a node when node is the object.

As long as there is some way to to call out the specific field item you need I'll be happy, because if not then FileField Paths and any of it's sub-modules will be broken, as will the Custom Tokens module, and I'm sure many more.

As for the variant being part of the token itself, does that mean it will be up to the token implementer to support these variants? If instead you just had the token implementers have multi-value tokens always defined as an array and had a theme('token', 'comma-deliminated', $token) (or similar) style setup you would make multi-value tokens more consistent.

eaton’s picture

My biggest concern is that previously (D6) there was two different types of a field token, one for the individual field when passing the field as an object, and one with the first field on a node when node is the object.

Not really -- the two types of tokens were the same, just "chained" on each other, and that system is roughly how D7's token system works by default. For example, if you are generating tokens for a given link field you are essentially creating tokens like:

[field:url] = http://test.com
[field:title] = Test Dot Com
[field:target] = _blank

Node tokens are generated by the same code, but would be used in a slightly different fashion: [node:field-link:url], [node:field-link:title], and so on. The same code, the same tokens, just a different 'starting point.'

- Is it technically doable to push them at the end of the token ? [node:field-name:variant:2], [node:field-name:variant:all:comma] ? Can a generic 'multiple values handler' catch the end of the token and massage the results provided by the 'variant', or is it the job of the 'variant' provider to handle anything that's behind in the token ? (er, not sure I'm being clear..)

Theoretically yes, but it would collide pretty badly with 'chaining' that makes things like node and user references powerful. Right now the chaining starts at the 'left' side of a token and keeps chopping things off, using the leftmost 'chunk' to determine who should handle the remaining portions of the token. That means it's easy to special-case [node:field-foo-2] or [node:field-foo:2] but it would be tanglier to handle [node:field-foo:more:chained:stuff:2]. I have the sneaking suspicion that for now at least, it would make sense to support 'first delta' and 'all deltas, comma delimited' but not the ability to specify them explicitly. That would allow us to consistently generate the tokens: [node:field-name] and [node:field-name-all] as two distinct 'chaining points'. Some field modules could provide support for more complex mechanisms if they really wanted to, but this would give us maximum flexibility without sacrificing the chaining.

- Off hand, I'd rather lean towards making [node:field-name] be 'only the first value' by default (vs 'all values'), but that might be a personal opinion, no strong arguments here.

I agree; the 'all values comma delimited' scenario is less common, in terms of token's intended usage.

robby.smith’s picture

subscribing

Dave Reid’s picture

Version:6.x-1.x-dev» 7.x-1.x-dev
Dave Reid’s picture

Assigned:Unassigned» Dave Reid
fago’s picture

FYI entity metadata provides tokens for fields based upon the entity metadata of fields. I've not tested it much yet, but it seems to basically work.

blaiz’s picture

Suscribing

xjm’s picture

Tracking.

scotself’s picture

subscribing. so i'm confused by all the chatter in this and other forums...is this going to be available at the field level? i'm so used to using things like auto_nodetitle that uses a field token to generate the title from one or more fields' contents, i can't imagine not having this functionality available...

EDIT: after playing for another couple of days, it seems like this works fine for a while and then it goes away? any idea what could be happening? for instance, i've using field tokens in pathauto to set the path, have several dozen nodes with auto paths set already using that method, but now when i go to the pathauto config page, there are no field tokens available? i'm alos using tokens, as mentioned above, to set node titles and have had this work off and on, but even just refreshing my node/add/{my-type} page seems to do the trick sometimes!?? any idea if the issue is with token or with one of the other modules?

scotself’s picture

shameless bump. this one's bugging me to death. i had it working, have pathauto set to use field tokens, had auto_nodetitle working and now no field tokens at all...

scotself’s picture

ok, i see now...earlier i was benefiting from entity metadata's tokens before and i have since disabled it; that's why the tokens i though token was providing are gone :) i didn't read all the comments and just reread and saw fago's #19 and that HAS to be where my tokens were coming from...unfortunately i was getting another error when entity was enabled along with rules and tokens, so i disabled both. i'm abandoning rules for now until it's beta and seems that entity metadata and token may have some capatability issues (see http://drupal.org/node/934444). but fago's right, entity metadata does provide field tokens needed...

juves’s picture

Suscribing

BenK’s picture

Subscribing...

sharikov’s picture

Suscribing

Dave Reid’s picture

Priority:Critical» Normal

#967330: The [current-user:?] token should provide the actual loaded user is blocking this issue to support fields on the [current-user] token since it's a user entity. Bumping this down back to normal since its a new feature.

Azol’s picture

subscribing

Dave Reid’s picture

StatusFileSize
new88.11 KB
new22.19 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens-D7.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

WHEW! I think I got it nailed down how to finally get this working. Here's a preview of how they work so far.

About the solution:
1. Added a new field view mode 'Token' that is used when generating the token values.
2. For each field, we needed two different token types. The first is the field's instance token type, the second is a field's value token type. By default the field instance token type works with the first value in the field. The is the best thing I could come up with that would easily allow us to chain tokens.
3. You can access any value in the field by using [entity:field-name:values:3] or [entity:field-name:values:3:chained-token] - that would access the 'fourth' value in the field since you're using the array index.
4. Added implementations for text, taxonomy, file, and image fields.
5. Clears the token cache when adding, updating, or deleting a field instance.
6. The really, really cool thing is for any module that provides a field it works really easy. All you have to do is provide the field instance token type, and the field value token type and its tokens, and make the token replacement code for the field value token type. Everything else is called for you.

Problems encountered:
1. The default build of a field includes lots of divs and markup. I tried implementing a duplicate copy of theme_field() and using token_field_attach_view_alter(), but it hasn't worked for me yet. I'm also not happy with the way [entity:file-field:file] and [entity:image-field:file] are generated.
2. Still haven't written tests or checked what happens when you 'delete' a field.

Dave Reid’s picture

Status:Active» Needs review

Screenshot of #30 in action:

Dave Reid’s picture

StatusFileSize
new61.41 KB

Screenshot of a text and taxonomy term reference field from #30

Dave Reid’s picture

I would love, love, love to hear from the people from the earlier parts of this issue (/me looks at eaton, yched, Deciphered) to hear what they think about where this is headed and how it matches up with our expectations for how this would have worked in core.

Dave Reid’s picture

StatusFileSize
new23.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens-D7_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Cleaning up and adding more comments since this was fun for even me to understand.

yched’s picture

@Dave Reid : thanks for kicking this !

I can't do a code review just right now. I kind of hoped it was possible to get rid of the CCK D6's approach of generating token values by rendering the 'node' in a dedicated view mode. That's a hacked and semi-working approach, having token values depend on how a view mode is configured is confusing and unflexible.
+ As i tried to advocate earlier, view modes and rendered nodes go through field formatters, which are targeted at generating HTML, which doesn't really fit with tokens (ie : some formatters might be ok for tokens, others not, in a hard-to-predict way)

This being said, i have little clue off-hand if another approach is doable :-). Maybe just : one token per column in the field-type 'schema' (raw data), and let field types specify ad-hoc 'computed' tokens out of that.

Dave Reid’s picture

That's kinda what we've done here.

For example, in #33, the [node:field-file] is the field_formatter version of the field (all values). I don't know what other way we can generalize code to display all values of a field like we need to do with the base token. And the base field token and when someone uses [node:field-file:values:0] (and not [node:field-file:values:0:file:path] are the only times we use the field formatter. For the first value of the field, you can access the raw data using [node:field-file:description] or [node:field-file:file:path].

yched’s picture

Oh, ok got it now - I should have watched #31 more closely.

fago’s picture

As i tried to advocate earlier, view modes and rendered nodes go through field formatters, which are targeted at generating HTML, which doesn't really fit with tokens (ie : some formatters might be ok for tokens, others not, in a hard-to-predict way)

Agreed, I don't see full-blown HTML output like an image-view fitting into the concept either. I do think we want to have attributes like URLs to different image versions or the image description text available as tokens, I'm not sure about formatters in general though.

>[entity:field-name:values:3]
For consistency with entity-metadata, would it be possible to go with [entity:field-name:3] instead ?

Dave Reid’s picture

Agreed, I don't see full-blown HTML output like an image-view fitting into the concept either. I do think we want to have attributes like URLs to different image versions or the image description text available as tokens, I'm not sure about formatters in general though.

Please look back at the screenshots. That's what's provided.

For consistency with entity-metadata, would it be possible to go with [entity:field-name:3] instead ?

No because that would make the [entity:field-name] token a dynamic token and we would not be able to provide any kind of token help for it. That's why the dynamic 'any value' token has to be nested one level deeper into [entity:field-name:values].

fago’s picture

>No because that would make the [entity:field-name] token a dynamic token and we would not be able to provide any kind of token help for it. That's why the dynamic 'any value' token has to be nested one level deeper into [entity:field-name:values].

We could just provide token help for [entity:field-name:0] or [entity:field-name:X], not?

Dave Reid’s picture

Because that's *NOT* how the token system works in D7. We use the stuff in hook_token_info() to validate the tokens people use in form elements. You can't just make 'fake' tokens just to show in the token help. That's why we support the 'dynamic' property of hook_token_info() in Token.module.

Dave Reid’s picture

StatusFileSize
new23.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens-D7_1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
rfay’s picture

StatusFileSize
new23.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens.rfay_.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Same patch as #42 - seeing if the -d7 removal from the name will solve it.

fago’s picture

Which 'dynamic' property? I'm not aware of that + it's not documented for hook_token_info()?

Dave Reid’s picture

We support it via token.module. You have to add the property via hook_token_info() or hook_token_info_alter() but it's meant to be used for tokens like [date:custom:*] (see token_token_info_alter()) where the third part of the token can literally be *anything*. Field values work in the same way. Fields can have *any* number of values, so we do want people to be able to access them, but for the most part, we can provide the explicit chained tokens for the first field value, and the dynamic chained token for all values.

BenK’s picture

I did a quick functional test of the patch in #43 and everything seems to be working great.

To test, I used Field tokens in combination with the Realname module and Private Message's Realname integration. This involved creating first name and last name fields on the user account, using the token browser to assign those fields as a user's "realname," and then using that realname in writing (autocomplete) and reading Private Messages. Everything worked as advertised.

So at least from a basic functional perspective, this patch is looking good.

Cheers,
Ben

fago’s picture

ad #45:
I see. I'm unsure whether having dynamic tokens like 'custom' date tokens is a good idea - for that we can define new date formats. Anyway the field tokens are only partly dynamic though - as only the number of items really available is dynamic, so one could validate the token to contain at least a numeric key. Perhaps you could tweak the validation to only allow numeric dynamic keys? Then we could go and make [entity:field-name:0] tokens.

The point is with :values the token-data-structure would look pretty much different as what we have in entity_metadata as property, what is inconsistent and would mean the efforts of #975616: Entity metadata needlessly duplicates properties are for nothing.

Dave Reid’s picture

Again that making [entity:field-name:index] tokens does not work with the current token API. Each field instance can have different value settings, and it complicates the UI listing. That's why I started using [entity:field-name:values:index] as the dynamic token.

jcarlson34’s picture

@Dave Reid Thank you so much for working on this.

In testing, text and term reference (taxonomy) fields work great with modules like Automatic Node Titles. Haven't tried file or image fields yet.

Any chance the other Drupal core field types, like integer, list (text), list(numeric), will be supported as well?

Dave Reid’s picture

@jcarlson34: Yes, the final version will have full support for all core field types, I just wanted to start with a few to make sure the process would work.

jcarlson34’s picture

Ah fantastic. I figured as much but thought I should ask just to be sure.

fago’s picture

ad #48:
What entity-metadata does is using [enity:field] for single valued fields, and [entity:field:0] / [entity:field:1] / .. for multiple value fields (=lists), though I don't think the latter is implemented for tokens yet (but as property). That way you could also do tokens that combine all list-values into a single one, e.g. by imploding the values with a komma.
Perhaps, that would make sense for token too? Having a consistent token/entity-property data structure is surely that would users would expect.

Else, I still think we could do [entity:field-name:index] while having [entity:field-name:column] at the same time.

eaton’s picture

"Having a consistent token/entity-property data structure is surely that would users would expect." -- This is what programmers would expect, but we're not exposing raw entity metadata to end users, site builders, site administrators, or other non-developers anywhere outside of token at present... Although I'm sympathetic to the desire to have One Metadata System To Rule Them All, the first priority is making sure that people can access commonly needed stuff with sensible tokens, sensible browsing/help, and a minimum of crazy special-case code.

This patch definitely delivers that, and I'm not sure we gain a lot from the perspective of someone using Token in its intended use cases by providing separate tokens for every delta. "The first" and "All of them" seem like valid cases for token module itself to handle in the case of multivalue items. Nothing prevents other modules from grafting MORE tokens on if they want to expose every individual delta, neh?

yched’s picture

Looking back at #30/ #31, the thing that worries me is that nothing communicates the fact that some tokens ([node:field-file], [node:field-file:file] / [node:field-term], [node:field-term:term]) depend on how a specific view mode is configured, while the others are 'constant'.
Sounds hard to predict - especially, I'm not sure what is the pattern for the second one ([node:field-file:file] / [node:field-term:term])

fago’s picture

>This is what programmers would expect, but we're not exposing raw entity metadata to end users, site builders, site administrators, or other non-developers anywhere outside of token at present...

We are not exposing raw entity metadata to end users, but site-builders make use of it e.g. in Rules or other modules like the Search API. Thus users would see a different structure there as for token replacements.

Anyway, if the code required to align it is too complicated, then I guess we have to live with the different structures. If it's possible though to align the structure without much extra effort, we really should do that.

>"The first" and "All of them" seem like valid cases for token module itself to handle in the case of multivalue items.
Makes sense.

Dave Reid’s picture

Looking back at #30/ #31, the thing that worries me is that nothing communicates the fact that some tokens ([node:field-file], [node:field-file:file] / [node:field-term], [node:field-term:term]) depend on how a specific view mode is configured, while the others are 'constant'.
Sounds hard to predict - especially, I'm not sure what is the pattern for the second one ([node:field-file:file] / [node:field-term:term])

Not really. The first-level [entity:field-name] is always the field formatter version. All the second levels are constant except for [entity:field-name:values:index], which also uses the field formatter.

yched’s picture

And that's not exactly what I'd call self-explanatory ;-).
That's possibly mainly a UI issue - is there any way to add some meta text in the token summary listing shown in #30 ?

R.Hendel’s picture

subscribe

BenK’s picture

Status:Needs review» Needs work

I just tried to apply the latest patch (in #43) and it wouldn't apply. It looks like we need to re-roll that patch...

--Ben

Dave Reid’s picture

Status:Needs work» Needs review
StatusFileSize
new21.41 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens-D7_2.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
Dave Reid’s picture

Ok we have a D7CX pledge to hit, so unless there are any more objections, I'm going to have to move forward with this as its one of the last remaining must-haves for 7.x-1.0.

Dave Reid’s picture

Priority:Normal» Major
BenK’s picture

Status:Needs review» Needs work

I did some testing of the patch in #60 in conjunction with the latest D7 version of the Realname module. I'm getting the following error message, but I'm not sure if the culprit is Token or Realname:

PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'realname' at row 1: INSERT INTO {realname} (uid, realname, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => First Name: Al Last Name: Admin [:db_insert_placeholder_2] => 1291858538 ) in realname_update() (line 203 of /Users/benkaplan/git/drupal-rc1/sites/all/modules/realname-DRUPAL-7--1/realname.module).

To re-create this error, add two fields to the user account ("field_firstname" and "field_lastname"). Then on the Realname configuration page, use the Token browser to make the Realname equal to "[user:field-firstname] [user:field-lastname]". Then save this setting. You'll get the above error on every page of the site. It appears that either Token or Realname is passing in all of the HTML markup into the Realname database field itself.

I tried changing the Realname to "[user:field-firstname:value] [user:field-lastname:value]" and the error went away.

So is Token or Realname the culprit? If you'd rather I post this in the Realname issue queue, just let me know.

--Ben

Dave Reid’s picture

@BenK: Yeah, you have to use [user:field-firstname:value] and [user:field-lastname:value] which are the raw value tokens instead of the root tokens which are the formatted versions.

Bevan’s picture

There are some missing features. I am not sure if these are known issues, or if they are intended to be in this patch or not;

  • Only text fields are supported, not boolean, numeric, date or references fields
  • Tokens can not be used for the Default value for fields. Or at least no token suggestions are available to select.
Dave Reid’s picture

Only text fields are supported, not boolean, numeric, date or references fields

As I explained above, I haven't written the integration for all core field modules. I'm trying to get input on this implementation before I sink more work into finishing this off.

Tokens can not be used for the Default value for fields. Or at least no token suggestions are available to select.

Please file a new issue since this issue is just about providing tokens for field values. This may be impossible to do with the new Field API in D7 as well. :/

jcarlson34’s picture

As per Dave's request in #61:

Ok we have a D7CX pledge to hit, so unless there are any more objections, I'm going to have to move forward with this as its one of the last remaining must-haves for 7.x-1.0.

No objections here. I think its getting to 'last call' and 'speak now or forever hold your peace' territory.

As for #54, I think adding labels like (output constant) or (output views dependent) to the token description field could clarify and resolve those concerns.

ayalon’s picture

for me, this is critical as well...

I have tested a lot of tokens with patch #60. All common tokens and field values are working. Because this patch should be ready before Drupal 7 is out, we should push forward this patch and make a second iteration adding the mission "special cases".

ayalon’s picture

Status:Needs work» Reviewed & tested by the community

I forgot to mention, that you have to clear the cache to see the new token values.

jerrac’s picture

I applied patch 60 to token-7.x-2.x-dev released 2010-Dec-14 on a clean install of D7 RC2. Using pathauto, I was able to use this pattern just the way I wanted: content/[node:field-test-vocab:vocabulary:name]/[node:field-test-vocab:name]/[node:title]

I got content/nameofmyvocab/termiselected/nodetitle. :D

spacereactor’s picture

So far patch #60 since to be working, can it be roll in for the public before 5 jan drupal 7 release.

noussh’s picture

I patched #60, but getting following errors.

patching file token.module
Hunk #1 FAILED at 35.
Hunk #2 FAILED at 167.
Hunk #3 FAILED at 256.
3 out of 3 hunks FAILED -- saving rejects to file token.module.rej
patching file token.tokens.inc
Hunk #1 succeeded at 912 with fuzz 2 (offset 146 lines).

what could be wrong?

tsvenson’s picture

Subscribing

frank31’s picture

Subscribing too

Cheek’s picture

subscribing

hass’s picture

Status:Reviewed & tested by the community» Needs work

Patch in #60 needs to be re-roled as it does not apply anymore :-(

Dave Reid’s picture

Status:Needs work» Needs review
StatusFileSize
new21.41 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 691078-token-field-tokens.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Re-rolled only.

spacereactor’s picture

#77: 691078-token-field-tokens.patch queued for re-testing.

glowsinthedark’s picture

Woohoo! Successfully applied patch in #77 to token-7.x-2.x-dev released 2010-Dec-18 on D7 RC4. As mentioned above, only text fields are supported (only tested text and list) and cache needs to be cleared each time a new field is created for a content type. Using Pathauto, I was able to integrate a text field into the URL.

jcarlson34’s picture

#77 works like a charm just like #60 before it.

Taxonomy terms work great. Like #79 said, you have to clear the cache to see newly created fields listed.

Bright Web Design’s picture

Status:Needs review» Active

This patch works as it said, but it doesn't work for the select field.
Please some one create patch for the select field too.

Dave Reid’s picture

Status:Active» Needs work
thekevinday’s picture

subscribe

geerlingguy’s picture

Subscribe. Didn't realize this was not yet fixed. Silly me...

SilviaT’s picture

subscribe

JohnnyX’s picture

Subscribe

JohnnyX’s picture

Could you make a new dev version available which contains the patches? I'll download and test it.

Dave Reid’s picture

Just discovered http://api.drupal.org/api/drupal/modules--field--field.module/function/f... and want to investigate using that.

SilviaT’s picture

The #77 works for me too. Tested with Real name module.

mariusz.slonina’s picture

+1 for #77 + Realname (select support is missing), thanks!

geerlingguy’s picture

With the patch in #77, I get the following error when using Token + Pathauto:

Notice: Undefined index: field_short_name in _token_field_attach_view() (line 1101 of /home/parishes/public_html/sites/all/modules/token/token.tokens.inc).

This is on node save, patched against latest -dev release.

@glowsinthedark / #79 - how do you have your pattern set up for your path alias, and what kind of text field are you using to make Pathauto work with Token? Also, are you using the -dev branch of pathauto, or stable? (For my internal tracking: http://archstldev.com/node/786).

Dave Reid’s picture

StatusFileSize
new20.6 KB
PASSED: [[SimpleTest]]: [MySQL] 205 pass(es).
[ View ]

Another revision that gets rid of the need for the _token_field_attach_view() function by using field_view_value() and field_view_field(). This makes it impossible to have tokens with labels or full field rendering. I guess we could add something like [entity:field-name:rendered] if people want that.

geerlingguy’s picture

Testing...

[Edit:] Well, that got rid of the PHP error, but Pathauto is not updating the path alias on node save (or re-save). Here's the pattern I'm using:

[node:field-short-name]

field_short_name is a simple required text field, no frills.

geerlingguy’s picture

+++ token.tokens.inc 11 Jan 2011 17:28:20 -0000
@@ -860,3 +860,499 @@ function _token_profile_fields() {
+  if (($type == 'text-field-value' || $type == 'text-with-summary-field-value') && !empty($data['item'])) {

This line seems to be where the data stops, as when I run dpm() on $type, I get 'node' on node save.

dpm() on $tokens returns a node object, and dpm() on $data returns an array with 'field-short-name'.

+++ token.module 11 Jan 2011 17:28:20 -0000
@@ -167,6 +167,27 @@ function token_form_alter(&$form, $form_
+function token_field_create_instance($instance) {
+  token_clear_cache();

+1 on clearing caches on create, update, and delete.

Powered by Dreditor.

ccheu’s picture

subscribing

deng17’s picture

I guess I'll just wait for an official version of Token. Hope this would be fixed soon since CCK fields are very important.

tsvenson’s picture

I'm eagerly waiting for this too, but I know Dave has a lot on his plate and also want to make sure it is done right. Hopefully his investigating in #88 will prove fruitful for field tokens.

glowsinthedark’s picture

@geerlingguy: Sorry, just noticed your question in #91. I've since removed that particular test site and don't remember the version that I patched. However, I do remember that it was a plain text field. Since I need list fields to work in order to put a Drupal install in the hands of business users, I've been waiting on further progress before testing further.

rharmsen’s picture

I hope a working version lands soon, as I am to in need for a working Realname in Drupal 7.

JohnnyX’s picture

New version works with pathauto for forum url aliases

skhot’s picture

subscribed

novakov’s picture

subscribing

hailander’s picture

Status:Needs work» Needs review

#77: 691078-token-field-tokens.patch queued for re-testing.

parraccourci’s picture

subscribing, waiting for node reference support as said it would be in #66.

CSCharabaruk’s picture

Subscribing, need this bad.

geerlingguy’s picture

Status:Needs review» Reviewed & tested by the community

With patch in #92 and latest pathauto and token stable releases, everything's working well for me... haven't tested all use cases, but at least pathauto and token seem to be playing nice with each other. This is a critical patch, imo, and seeing that I'm not hitting any errors anymore, I think it's pretty safe to commit. A few small bugs and kinks should be worked out in follow-up issues, I think.

jcarlson34’s picture

Happy birthday #691078: Field tokens thread!

This thread is a great example of the collaborative efforts of the Drupal community.

Btw the #92 patch is working great. Been testing it in quite a few instances and it passes every time.

hass’s picture

You are too early, this brings ill luck :-)

geerlingguy’s picture

@jcarlson34 - lol, it's still Jan. 20 by this drupal.org's time, and by my local time... it'll be a few more hours :)

glowsinthedark’s picture

#92 works, but I'm not sure what field types are supposed to be supported. Taxonomy and text works, however, date doesn't. Using current supported versions of Token, Pathauto and Date.

Dave Reid’s picture

Thanks for everyone testing. I need to do one final round of polish/cleanup this weekend to final push on this.

stevetweeddale’s picture

Subbing - thanks for all the work that's gone into this.

pitkane’s picture

Howdy,
after actually playing around with drupal for a few days now it's time for my first post to community :)
Was working with automatic nodetitles and was missing all of the field tokens. So I applied #92 patch and got it working (tho it seems you have to clear all caches everytime new fields are added, havent tested this much). As #101 stated i'm not sure what field types are supposed to be working atm. Are we getting support for all core types like _integer_ ;)

geerlingguy’s picture

@pitkane / #113 - Welcome to the contributing side of the community! :-)

So far, it seems that text-type fields are fully supported... I haven't had the chance to test other types.

effulgentsia’s picture

subscribe

jcarlson34’s picture

Hmm just found out about the Entity API module's 'Entity tokens' which is a submodule of the Entity API. According to the text on the submodule: "Provides token replacements for all properties that have no tokens and are known to the entity API."

Currently I am seeing basic support for select lists and other Field types that will eventually be fixed in this patch. Select lists seem to work great for modules like Custom Breadcrumbs and Automatic Node Titles right now if all you need is the value contained in the field.

I am assuming Tokens will eventually provide more options than the Entity API and will override Entity tokens for core/major field types but haven't seen any mention of it here yet. The two modules seem to play nice with each other but just wanted to make sure...

kris84’s picture

subscribing

manimejia’s picture

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new144.53 KB
new62.47 KB

Well silly me...
For the last two months I've been hand rolling a version of this feature myself, for an app that needs tokens on field content. I'm sure I searched these issue queues before I started, but somehow ended up venturing out on my own. The app that I'm building has a need for generating reports in "plain english", so my work has been focused on the generation of modular sentence pieces using field data and tokens.

So I have a bunch of code.
It's got a few app specific bits (so it's not releasable) and it's not as 'polished' as what's posted here already (thanks DaveReid et all), but there's some usefulness to come out of it, and from my experience.
So check out the code online and I'll summarize bellow:
field_token.module : http://pastie.textmate.org/1507182
field_token.tokens.inc : http://pastie.textmate.org/1507177

So what I've done here is that 'field_token' module calls a hook on all other modules, from it's implementations of hook_token_info() and hook_tokens(), to provide their own 'field specific' tokens. This allows the field token type itself (and any other common tokens, like 'template') to be generated by the field_token module, and provides for consistent naming. Each implementing module is expected to then provide field tokens based on it's data.

One solution I thought of is to implement what I call "token styles". This allows for field data to be output in different formats (like 'date' token does). It is very similar to chained (or 'dynamic') tokens, where another key is appended after the token (separated by a colon). This allows (for example) an address field to use a token of the format [field_myaddress:street:name], where "name" is a style of the "field_myaddress:street" token, and outputs only the street name of the street column in the address field. I don't know how to implement this without having the field type module do the replacement of the tokens.

Here's a tip on field token naming. Granted that I din't think of replacing _ with - in my field token type names, but one thing I did manage to consider is that not all field names will be prefixed with 'field'. Only fields generated by the "field_ui" module can be guaranteed to have a 'filed' prefix. So I suggest that any field token solution be aware of this, and ADD this prefix (as needed) to any field name before making a token type from it. For example:

<?php
function token_build_field_token_name($field_name){
  if(
strpos($field_name, 'field_') !== 0){
   
$field_name = "field_$field_name";    
  }
  return
strtr($field_name, '_', '-');
}
?>

The coolest thing I've done is to add a 'template' token to each field token type (or instance) that defines token templates. These 'templates' are (essentially) user editable token filled hunks of text. Having each template registered as a token allows for embedding templates inside each other, to build really nice human readable generated sentences from field data. I'm pretty sure this would not be covered in the 'token' module here, but would make a fine addition as it's own module. (see attached scree shots)

So how can I be of help...
Now that I know that the folks here with token module are working hard on a field token solution, I don't see the point in continuing to develop on my own. Is there any use for the code I've developed, or the ideas I've come up with?

cwithout’s picture

#92 is working for me. I've also used it to implement tokens for the Amazon Module's asin field, and it's working well.

But I'm seeing one issue. When a field I've used as a token is left empty, I get the token itself in the title. If that's not just a problem with my installation, I think it would be better to remove the token if it's valid but there's no value.

Here's an example:
3 Text fields: field_first, field_middle, field_last
Auto Nodetitle pattern: [node:field-first:value] [node:field-middle:value] [node:field-last:value]
When any of the fields are left empty (such as optional middle name), I get '[node:field-middle:value]' as part of the title.

So John Smith's node title comes out as 'John [node:field-middle:value] Smith' instead of 'John Smith'.

ropaolle’s picture

Assigned:Unassigned» Dave Reid
Status:Postponed» Reviewed & tested by the community
Issue tags:-token, -url. views, -D7 stable release blocker+i18n sprint

Who could belive that this would be such a huge thread.

cnolle’s picture

#92 works very well for me using auto nodetitle, except for fields of the tye 'List (text)'.

rorymadden’s picture

subscribe

rhlowe’s picture

Subscribing.

Dave Reid’s picture

Status:Reviewed & tested by the community» Needs review

I would actually like to hold this up for #1047740: Add an [array:*] token type and a [user:roles] token as it may help solve this issue in a much better way.

CSCharabaruk’s picture

Just tried patch from #92, and noticed there's no node reference field support (as yet). Where would that fall in, so I can figure out what/where to edit, so I can at least grab titles of referenced nodes?

tnanek’s picture

Not sure if this should go here or not, and I haven't read all of the above, but when using a numeric field through a token, I would like a way to switch the thousands seperator. Right now it seems to be defalting to a comma. My use case is a year field to be used in the title - years ordinarily have no thousands separator, so that needs to be editable somewhere (this isn't specific enough to be a date field IMO - just a year).

I went to the content type's display tab in admin/structure/types/manage/ (content type machine name) /display figuring thats where the other settings of that sort are. I would expect another sub-tab on this page for tokens (currently it is Defaults and Teaser for me, and default doesn't seem to apply).

--EDIT--
I'm using the latest releases of all modules, and auto_nodetitle and applied the patch from #92.

dboulet’s picture

Subscribe.

AnotherHowie’s picture

Status:Reviewed & tested by the community» Needs review

Having read through this whole thread, I'm still confused. Is there any definitive documentation somewhere for what tokens are exposed?

In my D6 site, I could have Pathauto use: releases/[field_version-raw]
That doesn't work in D7, nor does [node:field_version:value], [node:field-version], or [node:field_version] (trying to follow the discussion above). I just get: "The Pattern for all Software Release paths is using the following invalid tokens: [node:field-project], [node:field-version].", and it's true that no 'cck' related tokens appear in the reference on the URL Aliases page.

However, I can't tell if I'm just doing it wrong, or if it's not going to work anyway yet, because it's not documented (the README for Token is two lines long). So I have Token 7.x-1.0-beta1, Drupal 7.0 and CCK 7.x-2.x-dev (don't think this is relevant anymore?) - is it possible to reference a field value from a custom content type in URL Aliases patterns? and if it is, what is the definitive syntax?

tnanek’s picture

@AnotherHowie:
You'll need to install the patch in comment #92 to the token module in order to make use of the fields through tokens. Mind you this is still in the testing phase, and thus hasn't been put into any of the official packages yet.

To apply the patch see the documentation for help.

CCK is not needed anymore - the majority of it is built in to Drupal 7 now, as well as the majority of token, you'll just need to install token to have the token list appear essentially; with this patch to it, fields are then exposed through this, and the syntax is visible in the list. The remaining parts of CCK that are not in core are in the References module (just node reference and user reference, as far as I know anyhow).

calvintennant’s picture

+1

kehan’s picture

subscribing

mindgame’s picture

subscribe

kbond’s picture

subscribe

odisei’s picture

subscribe

bfroehle’s picture

Just a reminder that the current status here is that a previously RTBC'ed patch in #92 is being held up per @Dave Reid in #124

I would actually like to hold this up for #1047740: Add an [array:*] token type and a [user:roles] token as it may help solve this issue in a much better way.

I've implemented field tokens for Date in #906622-11: Cleanup the token code based upon #92 in this module.

sammyd56’s picture

subscribe

craigritchie’s picture

subscribe

FrequenceBanane’s picture

subscribe

joostvdl’s picture

subscribe

DeweyOxberger’s picture

subscribe

Magenta-dupe’s picture

With the patch from #92, I can not see any tokens from "List (text) - Check boxes/radio buttons" - fields. Is this normal?
Is there a way to have tokens from these fields?

jcarlson34’s picture

Hi Magenta. Yes this is normal.

Certain tokens aren't available yet with the patch. #30 states that the tokens available now are: text, taxonomy, file, and image fields.

I asked a similar question in #49 about List (text) and got the official answer in #50.

You could try the Entity API module and enable entity tokens, that may work in the meantime but not sure if that module conflicts at all with this one. Hope that helps!

pillarsdotnet’s picture

StatusFileSize
new19.59 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch modules_token.92.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

#92 re-rolled after the Great Git Migration.

MayaL’s picture

subscribe

mattab’s picture

Hi there, I applied the patch as per #143 but I do not see the "Fields" tokens appearing in the "Replacement patterns" help that is displaying all available Tokens.

For example I use Pathauto, and would like my URL to contain the 'location_region' field Title as the start of my URLs followed by the Content Title.

I'm new to Drupal, so maybe I am missing something...? Thanks

jcarlson34’s picture

@mattab Try clearing your site's cache and see if the Tokens show up then.

This command can be found at: /admin/config/development/performance

mattab’s picture

Thanks jcarlson34 - hopefully this patch can be implemented in the plugin as soon as possible! This is a very important feature :) thanks

LSU_JBob’s picture

subscribed

Dave Reid’s picture

I've opened up a separate git branch just for this feature and pushed it to Drupal.org:
http://drupalcode.org/project/token.git/shortlog/refs/heads/691078-field...

SMonsen’s picture

Version:7.x-1.x-dev» 7.x-1.0-beta1

Subscribing

bambilicious’s picture

Subscribing.

geerlingguy’s picture

Version:7.x-1.0-beta1» 7.x-1.x-dev

Patches should always be against -dev.

safetypin’s picture

patch #143/#92 is working for me. field tokens for taxonomy and images are displaying, and pathauto properly uses the taxonomy term names for the path as expected.

Geijutsuka’s picture

subscribe

kenianbei’s picture

subscribe

coreyo’s picture

The given patch worked well for me, and its provided functionality was the only thing that made this module worth using for me. I'd like to see it pushed into the official release so that I don't have to keep repatching.

calvintennant’s picture

Integer field types are not showing up as tokens with this patch applied. Is this an intended result?

Alan D.’s picture

Sorry for subscribing too - I've got two modules that need this to provide the token support.

TimG1’s picture

subscribing

wizonesolutions’s picture

Subscribing. Fill PDF needs tokens.

Docc’s picture

subscribe

egil’s picture

Subscribe

animelion’s picture

subscribe

animelion’s picture

Is this ready to be committed?

animelion’s picture

#149's branch seems to have added fields support for me. I'm still looking for better OG integration. Any suggestions?

#1088538: OG (Organic Groups) tokens missing.

tbenice’s picture

sub

MustangGB’s picture

Subscribing

rositis’s picture

subscribe

Dave Reid’s picture

Just an FYI: Sorry I am very busy this month. Had DrupalCon last week and I am getting married this weekend, so please be patient. I should have more free time to resume working on contrib in April once I return from my honeymoon.

xjm’s picture

Congratulations!

geerlingguy’s picture

Ooh! Congratulations on the marriage, and we'll hopefully have a nice gift in the form of a working patch when you get back. Relax and have fun!

spacereactor’s picture

Congratulations bro. :)

GerdC’s picture

Subscribe

ghmercado’s picture

patch 143 worked for me thank you.

pillarsdotnet’s picture

Status:Needs review» Reviewed & tested by the community
bfroehle’s picture

Status:Reviewed & tested by the community» Needs work

Let's remember:

I've opened up a separate git branch just for this feature and pushed it to Drupal.org:
http://drupalcode.org/project/token.git/shortlog/refs/heads/691078-field...

I would actually like to hold this up for #1047740: Add an [array:*] token type and a [user:roles] token as it may help solve this issue in a much better way.

Has anybody looked into this?

Lastly, not all core types are supported yet. Perhaps somebody could generate a list of core-provided field types and whether or not they are supported with the latest patch in #92 / 691078-field-tokens.

Implementing the missing field types should be relatively straightforward if somebody would like to tackle that.

jdufaur’s picture

Subscribe

kehan’s picture

subscribing

JustMagicMaria’s picture

Only some of my fields are showing up as tokens even after I apply the patch and clear the cache. It doesn't seem to be related to field type as one Date field shows up and another doesn't.

jay-dee-ess’s picture

subscribe

jay-dee-ess’s picture

subscribe

bforchhammer’s picture

subscribing

rwohleb’s picture

subscribe

Rob_Feature’s picture

Congrats on the wedding! (oh, and um...subscribe)

Jennifer_M’s picture

subscribe (got here via http://drupal.org/node/1051392, meaningful URLs for forum posts) - & sending thanks to everyone working on this!

Dane Powell’s picture

sub

NickWebman’s picture

The patch on #143 worked for me. I was seriously hosed without this. Thanks everyone.

xandeadx’s picture

subscr

Agileware’s picture

Subscribing

damien_vancouver’s picture

subscribing... at first glance the patch from #143 is working great for me!

cappadona’s picture

subscribe

yamenshahin’s picture

how i can apply this patch... i am using godaddy "Shared hosting".

tnanek’s picture

@yamenshahin:

See http://drupal.org/patch

I can give you a more thorough help in a private conversation, send me an email through my profile's contact tab if you want some additional support.

Trunkhorn’s picture

sub

kardave’s picture

Subscribing

Dave Reid’s picture

Anyone wanting to help get this finalized can ChipIn to fund my time on this (widget is at the top of the issue). I've based this on about 10 hours of work to finish, polish, and write tests.

geerlingguy’s picture

Consider it my wedding gift ;-)

animelion’s picture

Just put my money where my mouth is.

pillarsdotnet’s picture

The chipin link is crashing Google chrome. Had to switch browsers to post this.

jcarlson34’s picture

Well worth the money. Thanks for working on this Dave. And congrats on getting married!

Dave Reid’s picture

Thank you to everyone who's donated so far. I've slotted some time tonight and this weekend for trying to whip this back into shape.

designerbrent’s picture

Glad to see this is getting some attention.

Thev00d00’s picture

+1

Deciphered’s picture

@Dave Reid,

Can you make a note above the Chipin widget that it is not place by me, nor related to me in anyway as I am receiving emails about it?

Thanks.

Dave Reid’s picture

@Deciphered: Pass along any e-mails to me. My apologies about that - I added a better edit note.

jimmynail’s picture

subscribe

kbond’s picture

olafveerman’s picture

subscribe

scottrouse’s picture

Thanks, Dave. Excited to see this in place. Subscribe...

Wappie08’s picture

Thanks Dave, chipped something in for your good work :)

Actually theres one really cool thing which I think didn't even work in D6: in an integer select field you have [custom_select_field:raw_value] and [custom_select_field:label_value], I think most people are looking for the label in their urls.

Greets

basicmagic.net’s picture

subscribe

jeffwidman’s picture

subscribe

that0n3guy’s picture

subscribe

georgedamonkey’s picture

subscribe

Atratus’s picture

Is there any ETA on when we might see tokens for integer fields?

_nolocation’s picture

subscribe

JohnnyX’s picture

Subscribe

iKristjan’s picture

Subscribe

carn1x’s picture

Subscribe

gazwal’s picture

+1 Subscribe

MrPhilbert’s picture

Great idea to show a chip-in link! This should be promoted throughout Drupal for the great developers out there so guys like me can contribute with more than just testing. I don't have a lot of money, but I really appreciate the hard work and dedication people put into this.
Thanks
This $50 should complete your fund drive.
Looking forward to the first dev release.
MrPhilbert

vito_swat’s picture

subscribe

kououken’s picture

subscribe

Sborsody’s picture

@#142,

That was it! I had the Entity API and Entity Tokens enabled previously, which provides tokens for fields, then disabled them thinking that I didn't need those modules. That left me wondering why Pathauto was complaining about invalid tokens...

davidneedham’s picture

So far, the branch (#149) for this issue is not working. I see fields show up in the list, but if I try to use them with Automatic Nodetitles, things get wonky... like, the creation form shows the correct content type, but when I save the form, it somehow converts it into a completely different content type. I can confirm that it is the token branch at fault, because core tokens work perfectly with Automatic Nodetitles. It's only when I try to use one of the field tokens that it switches content types.

I can't confirm where the problem exists, but the branch in #149 is not compatible with the current dev release of Biblio. It somehow hijacks the content creation process - but only when a field token is used. Weird. I created an issue in the Biblio queue too: #1139432: Biblio Incompatible With Field-fix Branch of Token Module

rjerome’s picture

It (#225) was a problem in my (biblio) module. See http://drupal.org/node/1139432#comment-4397072

Pleex’s picture

Is there going to be support for select fields?

ldweeks’s picture

Congrats on getting married! Subscribing...

JamFar’s picture

subscribing

joelstein’s picture

Subscribing.

david3000’s picture

subscribing! I don't wanna use the patch ;-)

roseiro’s picture

Subscribing.

slippast’s picture

Subscribing. Here's a vote for including References tokens.

Is there a need to increase the ChipIn amount? If so it appears many people (including myself) would contribute. I see this as a critical part of Drupal 7's infrastructure so don't be afraid to ask for more, especially in light of recent personal events. Thank you!

iStryker’s picture

#143 worked for me.

fjen’s picture

+ subscribe

Tebb’s picture

Haven't read this rather long issue, but + 1 for increasing the ChipIn if it will help progress this.

Happy to make a modest contribution.

bjalford’s picture

How does the patch in #143 work? I have a content type with three term ref fields. After applying the patch I can now see the list of field types but not the actual fields.

For example, I can see [taxonomy-term-reference-field-value:term:name] but how do I make it show the value of a particular term ref field?

safetypin’s picture

StatusFileSize
new43.56 KB

@bjalford: when I put the token (similar to the one you mention) in a automatic alias field, it gets translated into the term name and inserted into the path of the node. I feel like it's a little difficult to explain, but I've attached a screenshot that will hopefully help.

hansfn’s picture

subscribe.

martinjbaker’s picture

subscribing

Agileware’s picture

For those saying increase the chip in, I'm pretty sure you can keep chipping in even if requested amount has been raised.
Especially seeing as this chip in is already at 110%.

Tebb’s picture

Thanks. I already chipped in 10%, but it's still showing only 100% for me.

The idea of increasing the chipin was mainly to have some measure of how much work was remaining and the effort needed, so that others could contribute towards that.

localsteve’s picture

Issue tags:-i18n sprint+token, +url. views

Hello all,

Not sure if this is related, but I am trying to link a field to the user's profile from views. I am placing the [user:url] token into the rewrite as URL but it doesn't render, I get mysite.com/[user:url]

I am using drupal 7, token 7.x-1.x-dev and views 7.x-3.x-dev

Am I overlooking something, also even if I use one of the available tokens (displayed under replacement patterns) the same happens.

Kind of a newbie, but i've already applied the patch provided in this thread.

marsbidon’s picture

Category:task» feature

Hello,

This module still doesn't support fields of type "list_text" and I need it for my project :(
Can you tell us when "token" will be finished?

Thanks a lot ...

muriqui’s picture

Category:feature» task

subscribing

... and, @marsbidon - Probably shouldn't recategorize a long-standing issue like this just to add a request. Changing back to "task."

olafveerman’s picture

Hi Dave, anything you can share on the progress of this issue?

sw3b’s picture

subscribe

Encarte’s picture

subscribing

shinz83’s picture

I need tokens for event dates. Anyone?

Adam S’s picture

Subscribing

amoutiers’s picture

subscribe

keithm’s picture

subscribe

paulgemini’s picture

subscribing

Shadlington’s picture

Subbing

animelion’s picture

Hey Dave, any update on this? It's been over a month since you last posted in here. I know you're busy, in that time you've commented on no less than 675 other issues. http://drupal.org/user/53892/track

Just wondering if we could be 676?

juves’s picture

Tracker shows not his recent comments, but recently updated topics with his old comments

jared12’s picture

Subscribing

sachbearbeiter’s picture

subscribing

dogboy72’s picture

subscribe

MakubeX’s picture

subbed

tahiticlic’s picture

Status:Needs work» Needs review

#92: 691078-token-field-tokens-v2.patch queued for re-testing.

damien_vancouver’s picture

StatusFileSize
new49.71 KB
new30.88 KB

I upgraded to the new 7.x-1.0-beta2 version, and the patch from #143 works fine for me still!

... there are a lot of people are subscribed to this thread!!

I'm guessing not all of them have been able to patch or know how.

I've provided instructions on how to patch below, as well as the changed files below so you can try it out without having to use a patch file! As you can see by the 7.x-1.0-beta2 Release Notes, there have been a lot of fixes to the module, so you should update to that version and then help test this patch by one of the below methods. Hopefully this patch will make it in there before 7.x-1.0 is ready.

Method 1: How to patch it yourself

These instructions will "just work" in Mac OSX or UNIX, probably not for Windows unless you find a patch program or apply the patch using git.

  1. Update your token module to version 7.x-1.0-beta2.
  2. Download the patch file from #143 above (the filename is modules_token.92.patch) and place it into your sites/all/modules/token folder.
  3. Apply the patch with:
    patch < modules_token.92.patch

    which should output:

    patching file token.module
    Hunk #1 succeeded at 40 (offset 6 lines).
    Hunk #2 succeeded at 172 (offset 6 lines).
    Hunk #3 succeeded at 261 (offset 6 lines).
    patching file token.tokens.inc
    Hunk #1 succeeded at 978 (offset 7 lines).

Method 2: Download the patched files and save into the token folder

If you just don't want to patch or can't patch (like you are in Windows or you only have FTP access to your server), I've attached the two changed files as text files. You can just save them in place of token.module and token.tokens.inc from 7.x-1.0-beta2, instead of using a patch.

  1. Update your token module to 7.x-1.0-beta2.
  2. in your sites/all/modules/token folder, rename token.module to token.module.bak and rename token.tokens.inc to token.tokens.inc.bak.
  3. Download the attached two files (token.module.txt and token.tokens.inc_.txt) and place them in your sites/all/modules/token folder.
  4. Rename token.module.txt to token.module, and rename token.tokens.inc_.txt to token.tokens.inc

Testing it out

Once you've updated to the patched 7.x-1.0beta2by one of the above methods, follow the below instructions to see it working and learn the names of your Field tokens:

  1. Go to your site's Help->Token page (admin/help/token). , or expand REPLACEMENT PATTERNS in an edit form.
  2. Expand the Nodes parent tree item
  3. scroll down a bit under Nodes and you should now see the your field replacement patterns, which will begin with"field-"
dogboy72’s picture

I had applied the patch successfully but it wasn't until I upgraded to 7.x-1.0-beta2 that it worked for me. Thanks for your post.

juves’s picture

Thanks to all who work on this.

#262 works well.

Waiting for node reference integration. Can't use PathAuto and CustomBreadcrumbs without it.

Adam S’s picture

Some field Tokens are available to me without the patch such as references tokens and text tokens. Have a look at help -> token to see what is available.

animelion’s picture

For anyone interested, here are some related discussions happening that may be resolved by this patch.
#1088538: OG (Organic Groups) tokens missing.
#1047740: Add an [array:*] token type and a [user:roles] token

JohnnyX’s picture

I use token 7.x-1.0-beta2 with the patched files and try to fill a field with the values from another field. Found a litte bug.

The values are filled in without separator.

value1,value2,value3,... gets value1value2value3...

Second problem (maybe not token module...). I override the output of a view and use tokens for my output and it doesn't work in the first column (view as table/ draggable table).

Modules

DraggableViews 7.x-1.x-dev
Views 7.x-3.0-beta3
Token 7.x-1.0-beta2 (patched files downloaded!)

Also tested with DraggableViews disabled. Same problem.

neurojavi’s picture

subscribe

urlM-2.0’s picture

Assigned:Dave Reid» Unassigned

subscribing.

JohnnyX’s picture

Second problem (maybe not token module...). I override the output of a view and use tokens for my output and it doesn't work in the first column (view as table/ draggable table).
Seems work as designed. Doesn't work in the first column. My workaround was to show a empty first column with a space as content.

But first problem still persists. If I try to fill a field with input/ values from another field (both taxonomy fields with comma separated values for tagging) the values are set as one string and not as comma separated values...
Any solutionfor this problem?

Mintaj’s picture

subscribe

adamdicarlo’s picture

Subscribing.

Looks like #269's change was unintentional -- this should be assigned to @Dave Reid, right?

TL;DR current status (copied from #135):
Just a reminder that the current status here is that a previously RTBC'ed patch in #92 is being held up per @Dave Reid in #124

I would actually like to hold this up for #1047740: Add an [array:*] token type and a [user:roles] token as it may help solve this issue in a much better way.

modstore’s picture

subscribe

Docc’s picture

sub

tsvenson’s picture

Assigned:Unassigned» tsvenson

@adamdicarlo: #1047740: Add an [array:*] token type and a [user:roles] token was changed to fixed earlier and Dave has also tweeted that he is planning to have Field Tokens merged into the dev version of Token this week.

Everyone is eagerly awaiting this historic moment :)

tsvenson’s picture

Assigned:tsvenson» Unassigned

Have no idea how it got assigned to me this time. Switching back to Unassigned as I can't assign it to Dave. Something weird is going on with the assign option me think...

RedTop’s picture

Subscribing. Thanks for those fantastic patches, I nearly had to revert back to D6. phew. :)

rickyraccoon’s picture

subscribing and eagerly awaiting patch for this.....thanks

Deciphered’s picture

Not sure if it's already on the agenda (or in there, but I can't see it), 'Image Style' tokens are essential.

 

@Dave Reid,

Can you possibly outline where you are up to with this issue and what the hold ups are, in the case that someone else can step up and get this issue resolved, I would think that with a bounty of $445 someone would be willing to do the work.

Cheers,
Deciphered.

Deciphered’s picture

StatusFileSize
new22.06 KB
FAILED: [[SimpleTest]]: [MySQL] 44 pass(es), 15 fail(s), and 0 exception(es).
[ View ]

Added Image Styles to the patch.

Status:Needs review» Needs work

The last submitted patch, modules_token.280.patch, failed testing.

Shadlington’s picture

@Deciphered: I believe Dave has been working on this so that bounty really isn't up for grabs. Not that that's how chip ins work anyway - folks put up money for Dave to work on it, not someone else.
I'm pretty confident we can trust that he will get there when time allows, its just a matter of patience.

That said, @Dave perhaps an update on progress would be useful in case some of the followers of this issue (such as Deciphered) would be able to help in some way.

Deciphered’s picture

@Shadlington, my point is that if Dave is unable to dedicate the time to this issue, and that if someone else was to spend their time to resolve the issue they should receive the bounty. I disagree with the paid approach in these situations as I've seen time and time again people taking donations but never coming through.

I am not saying that is what Dave is doing, I'm simply trying to find out what the status of this issue is and why it has yet again stalled. If he where to outline where things are, other developers would be able to collaboratively work to resolve the issue.

Shadlington’s picture

Okay, I thought you might have meant that, but wasn't clear.

I re-read my post and I may have came across a little rudely. If that's how it seemed, I apologise - I meant no offence.

mmgg’s picture

subscribing

really praying for this update soon!! this is the last module holding my current project from launching!
thanks!

ungabunga’s picture

subscribe

andypost’s picture

Status:Needs work» Needs review

#280: modules_token.280.patch queued for re-testing.

davidd07’s picture

subscribe

Status:Needs review» Needs work

The last submitted patch, modules_token.280.patch, failed testing.

Deciphered’s picture

Regarding the patch, the reason it'll be failing is because I appended the changes to the pre-existing patch, as there appears to be confusion about exactly what should be being patched.

There is an extremely out of date Field Tokens branch as well as the standard Dev other builds. This patch applies to the Dev as does the previous patch, it's just that not all of the line numbers match up anymore, as shown in comment #262.

CryAngel’s picture

I use patched token module by damien_vancouver (#262). After installing it on the every node page appeared
notice

Notice: Undefined property: stdClass::$node_type in the function entity_extract_ids() (row 7368 file /home/site/includes/common.inc).

I was disabling modules one by one, and notice dissapeared after I disabled patched token module. So I think problem belongs to it. Please check it and thanks in advance. :)

Mark Trapp’s picture

Subscribe.

Andrew Schulman’s picture

Subscribing

oromix’s picture

Subscribing

richygecko’s picture

Subscribing & looking for number fields

sunketh’s picture

Subscribe. Waiting for select list fields to work.

vimalramaka’s picture

super subscribe

geerlingguy’s picture

Ah, crud. We're about to hit 300 comments / the pager of death. Hopefully Dave can chime in soon. This issue's resolution would go very far towards getting more Drupal 6 to 7 migrations (and new site builds) done a thousand times easier :)

nicoz’s picture

sub

james.williams’s picture

unfortunately, here's another subscribe. 300 has been reached!

Pages