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.

Support from Acquia helps fund testing for Drupal Acquia logo

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.

scotwith1t’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?

scotwith1t’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...

scotwith1t’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

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

FileSize
61.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

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

rfay’s picture

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
FileSize
21.41 KB
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
FileSize
21.41 KB

Re-rolled only.

spacereactor’s picture

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

Jon Betts’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

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.

Jon Betts’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 :)

Jon Betts’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...

zd370’s picture

subscribing

manimejia’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
144.53 KB
62.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:

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).

calte’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

FileSize
19.59 KB

#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.

calte’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

bryancasler’s picture

subscribe

bryancasler’s picture

Is this ready to be committed?

bryancasler’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

Ryan Osītis’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 ;-)

bryancasler’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

@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.

Anonymous’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.

Striknin’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

bryancasler’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

FileSize
49.71 KB
30.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.

bryancasler’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

FileSize
22.06 KB

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.

Cray Flatline’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 :)

pixelsweatshop’s picture

sub

james.williams’s picture

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

a.siebel’s picture

301 *g* subscribe

RedTop’s picture

What's this about a pager of death thingy? Pager works for me. :)

mhahndl’s picture

subscribe ... Dave?

askibinski’s picture

sub

mbinde’s picture

subscribe

pillarsdotnet’s picture

Pager of death apparently refers to the fact that after 300 comments, clicking on the "New" link from your drupal.org dashboard doesn't actually take you to the newest comment; it just takes you to the head of the original post. You have to scroll to the bottom and manually click on the "last" link to see new comments, and that's just way too much work a major pita for most people with mobile devices. Hence anything after 300 comments probably won't be seen by the vast majority of more technically advanced drupal.org users.

EDIT: Updated based on #308 by geerlingguy.

wizonesolutions’s picture

Well, they're all subscribes now anyway. I'm sure no one will miss it when the patch lands/is committed :D

geerlingguy’s picture

You have to scroll to the bottom and manually click on the "last" link to see new comments, and that's just way too much work for most people. Hence anything after 300 comments probably won't be seen by the vast majority of drupal.org users.

...and for those of us who usually check up on d.o using iPads, iPhones, Android tablets/phones, etc., scrolling to the bottom is a MAJOR. pain. in. the. rear.

At this point, I will likely only check back on this issue once every 5-10 new posts :(

To help: #268374: "Jump to" links are broken on multi-page issues.

newtoid’s picture

+1

aaronpinero’s picture

Sorry if I'm adding this in the wrong place. I am using Views in Drupal 7 and attempting to employ replacement patterns to rewrite the output of a field in a view. I'm trying to use the replacement patterns for the field that I am rewriting, so they should be available. The field is a link and the replacement patterns that I'm told (in the UI) are available are -url and -title (as in [field_name-url] and [field_name-title]) However, when I implement the rewrite and look at the view, the replacement patterns are not replaced with data. They simply come across literally as "[field_link-url]" and "[field_link-title]".

So, my question is: is this a token problem, a views problem, a link field problem, or something else entirely?

Side note, this view is one that was brought up with a Drupal 6 > 7 upgrade. Does that have something to do with it?

Thanks,
Aaron

my.wahyu’s picture

I'm still use 7.x-1.x-dev.. although status report always give me notif "out of date modul" :-p
After try to install token beta 1 and beta2.. there was always ... appear error notification.
So i'm still using 7.x-1.x-dev.. hope beta3 release soon.

token is important tool.
d7 at http://www.gastia.com
newbie drupaler

paranormals’s picture

Subscribing

mitzai’s picture

subscribe

swortis’s picture

@aaronpinero , I don't believe field tokens are working at all in D7, so that would include Views. It is a Token issue, not a Views issue.

kenyangzj’s picture

subscribe

jastraat’s picture

@aaronpinero, it is also a link issue since the link module is still using link_token_list() and link_token_values() instead of the new hook_token_info() and hook_tokens() functions

AndrzejG’s picture

subscribe

Deciphered’s picture

Status: Needs work » Needs review
FileSize
22.08 KB

Re-rolled patch, applies to latest 7.x-1.x-dev

Status: Needs review » Needs work

The last submitted patch, field_tokens-691078-318.patch, failed testing.

Deciphered’s picture

My bad, testing was to quick for the fix. Let's try that again.

nylin’s picture

+1

pillarsdotnet’s picture

Status: Needs work » Needs review
NoDice’s picture

Patch looks good so far, great work.

I did notice a warning when editing and saving a node that uses automatic node title module using text field tokens for the node title:

User warning: Attempting to perform token replacement for token type text-field-value without required data in token_tokens() (line 757 of ...\sites\all\modules\token\token.tokens.inc).

My warning may be unrelated to your patch since I'm using auto node title module to generate the title. The setting I use for the content type is: "Automatically generate the title and hide the title field"

pillarsdotnet’s picture

Is the patch in #320 just a stopgap while we're waiting for the real fix, or was the ChipIn merely a wedding present for Dave?

MrHaroldA’s picture

Didn't chip in, but really interested in this feature!

tsvenson’s picture

@pillarsdotnet: Dave has had some technical challenges with getting Field Tokens working properly. Hopefully the code sprint at the Drupal Camp last weekend resulted in finding solutions to that.

pillarsdotnet’s picture

Cool. Looking forward to a real solution, then.

jhejl’s picture

Subscribe

Alan D.’s picture

Status: Needs review » Needs work

@tsvenson & Dave
Should other developers help with this? Is Stuart (Deciphered) going in the right direction? The last post by Dave was in April 15, so it hard to track the actual progress of this issue.

If it is getting close, I would suggest committing the best patch to the master (dev) repository and opening individual issues to clean up the remaining issues.

@Deciphered
Nice work picking up on this one, the patch looks great from a 1 min review. Will apply and test if the maintainers let us know what the status is on this.

Alan D.’s picture

Status: Needs work » Needs review

Fixing the status. Sorry, not sure how that happened.

EndEd’s picture

Subscribe.

ConradFlashback’s picture

sub

hgurol’s picture

Subscribe.

DamienMcKenna’s picture

What's the current status on this? Other module(s) are dependent upon this being resolved, e.g. the Date module (#1103032: Document how to use date tokens).

lukus’s picture

subscribing :)

dazz’s picture

sub

wizonesolutions’s picture

Jolidog’s picture

Also subscribing and wanting to know what's the status.
Are there other issues that need to be solved first? If so, where are they being discussed?

I'm guessing people are more upset with the lack of status updates from Dave, then the lack of a solution.

I didn't come across this issue earlier, if I had I probably would have chipped in too :)

AndrzejG’s picture

#320 works for me, see http://drupal.org/node/1186628

sammyd56’s picture

This issue has become a big black mark for Drupal. I will surely be shot down for saying this, but it is my strong personal opinion.

Many contrib modules are waiting on this functionality, and therefore lots of new users, myself included, have found themselves following the status of this issue. The last we heard, it was a 10 hours job to finish, polish, and write tests. If things have since become more complicated, fine, that's certainly not unheard of. However, for a leading developer to not comment on this important issue for over 2 months (whilst remaining active in other areas of Drupal) does not paint the community in a good light, especially since people have donated money. It's not the lack of solution that upsets me, it's the lack of communication.

'Come for the software, stay for the community', right? Without communication and collaboration, Drupal is nothing.

pillarsdotnet’s picture

Dave, if you need more money to complete this project, please say so. You would do no less if your sponsor was a corporate entity; how much more so when it is the community at large?

EDIT: Also forwarded the above via Dave Reid's contact form.

EDIT 2: Dave says he's writing a progress report now.

AndrzejG’s picture

Could somebody join this project as co-maintainer and push it ahead?

Stolen Squirrels’s picture

Subscribe.

deshiknaves’s picture

Still learning a lot of things about Drupal. Any chance you can point me to how I can install this patch?

vito_swat’s picture

check http://drupal.org/node/707484 section Applying a patch

deshiknaves’s picture

Brilliant! Thanks for the help.

blackdog’s picture

FWIW - the patch in #320 works great for Taxonomy tokens in Pathauto.

dropbydrop’s picture

sub

sachbearbeiter’s picture

can more money help to hire an external programmer?

devilpigeon’s picture

can someone post the amended files please? i don't have the ability to patch files myself.

also - it seems the patch from a few days ago works ok, why hasn't this made it into a dev release????

hdcwebteam’s picture

One more subscribe. Like others, not wanting to overlook all the hard work already done but this is a critical, show-stopping issue for a lot of Drupal sites and a bunch of other modules, now 4 months old... just a little progress report now and again would be hugely appreciated

MrPhilbert’s picture

It does not seam that additional subscribers has done anything to motivate this.

Would thoughts of having to pay back money collected work better?

I am an advocate of the chipin program. I think good developers deserve to get some green love for their efforts. However, part of being a good developer that is accepting compensation is communication.
We don't want to sour people to this program when its just getting started.

Please understand that when people donate/contribute funds, they want to know that progress toward the cause is being made.
There are a lot of dedicated Drupal developers (Dave and Deciphered, you are among them). I just hope that you understand that communication is part of development (especially when people contribute funds).

My wife talks about this from the banking software world. Without communication (status reports etc.) and documentation, your software cannot be used to its fullest potential.

If you would like someone to help with communication/documentation, please contact me. That is my field.

Thanks,
MrPhilbert

rfay’s picture

The problem is, Dave Reid is already *so* filthy rich that money doesn't even motivate him. Regardless of money he spends 36 hours a day *outside* his regular working hours maintaining the bazillion crucial modules he maintains. And contributing to core. And helping people in IRC. On and on. I guess we'll just have to let him set priorities for now. I know this is an important priority for him.

Deciphered’s picture

rfay,

I'm more than aware of developers over-extending themselves, I'm constantly guilty of the same thing, maybe not the the same extent, but guilty no less.

However, taking money for "move development along" and not actually moving development along (which I do doubt that is the case, but it's the appearance) is in my opinion deceitful. The people that have put money in did so with the understanding that the issue would be resolved.

Myself as a developer that could also put time towards this issue, there are two reasons why I can't and won't spend more time on this issue:

1. Someone has taken money to work on this issue, therefore they ARE working on it and any work I do will be a duplication, possibly taking the incorrect approach.

2. There is no transparency regarding the specifics of this issue, so for me to work on the issue I would have to duplicate all the research/testing to determine all the specifics of the issue, and again possible take the incorrect approach.

I respect Dave immensely, however if he is unable to resolve this issue he should at least give an update to what the issue is exactly, and how it should be resolved, and in a perfect world he should give back the money.

My thoughts, my personal opinion. Not meant to offend anyone involved or spark a flame war, I, like others, just want this issue sorted.

Cheers,
Deciphered.

MrPhilbert’s picture

Good Lord!
Mr. Contrib?
So it seems that there are a very few people that have this intimate of an understanding of the Drupal Code.
Dave Reid is one of them.
The list of other names that have this deep of an understanding is very short.

I can look at the code for some of the more simple modules and pretty much figure them out. For one such as this that operates at the very root of Drupal, I am hopelessly lost.
I am a marketing and sales person that became enamored with Drupal and its elegance and sometimes frustration (I can't resist a good puzzle). I am learning to read and write code as fast as I can. Hopefully someday soon I would/could be more helpful.
Til then, is there anyone else that has the capability to help with this?

MrPhilbert’s picture

Can we start a direct chipin to Deciphered?

Everett Zufelt’s picture

I applied the patch in #320. I can confirm the warning mentioned in #323 when using auto_nodetitles.

I also noticed that the list: text field on my node did not have a token.

Sborsody’s picture

Reminder: Entity Tokens (comes with Entity API) "provides token replacements for all entity properties that have no tokens and are known to the entity API" http://drupal.org/project/entity I've been using this for providing tokens for fields on nodes.

JohnnyX’s picture

You use Entity API with token or how it works? I haven't work with Entity API/ Entities before...

AndrzejG’s picture

I have Entity API enabled from the beginning and foung NO any token replacements for fields. If it is possibloe please indicate where.

Shadlington’s picture

Do you specifically have the entity tokens module enabled? Not just the core entity api module.

janvdp’s picture

I use this comment to subscribe...

AndrzejG’s picture

@Shadlington: Yes, I have it enabled.

tachikoma5’s picture

Another comment to subscribe. I am in the same boat where I need this for "Custom Formatters" and "Date module".

Stolen Squirrels’s picture

I'm reluctant to ever run the risk of unnecessary conflict in an open source community, but seriously ... ChipIn contributions paid and not even a status report since 15 April! With a total of 248,927 sites reporting usage of this module on 12 June (and sadly, down 3,245 from 5 June 2011), this is clearly a vital project for Drupal that is quickly becoming a serious black mark.

Reading through other posts, Dave is clearly dedicated to Drupal (and highly important in the long term future of Drupal), but he's also clearly over-extended (a common mistake). Although a patch would be better, most of us are just looking for a note from Dave indicating the issue(s) and when a patch can be anticipated.

However, regardless of the past (right or wrong, misunderstood or not), many of us simply need development to move along. I'm prepared to contribute funds towards development fees, whether additional funds to Dave or to an alternative developer, and I'm pretty certain many others would contribute as well. I'd like to think that Dave is busy with the patch, but with things being as they are, I'd like to suggest that if there is no feedback from Dave within a certain time that an alternative developer be paid to "move development along". Deciphered seems like the right candidate.

Dave - please give us an update or let us know that someone else should take charge.

Headache’s picture

Subscribe :\

MacRonin’s picture

Keeping an eye on this one by subscribing.

amysteen’s picture

subscribe. Currently using the most hilarious/dirty workaround for this issue.

pillarsdotnet’s picture

Currently using the most hilarious/dirty workaround for this issue.

Do share. I love dirty humor.

Deciphered’s picture

@pillarsdotnet - Nice: http://instantrimshot.com/index.php?sound=rimshot&play=true

 

@Stolen Squirrels & @MrPhilbert - I appreciate the sentiment, but I am equally as over extended at the moment and without any knowledge of the specific hold ups I would be of no use. However where we to get an update from Dave describing the specifics of the hold up and declaring his inability to work on the issue I would do what i could.

 

And lastly, while this is just my opinion (disclaimer), it must be said.
Too anyone who is suggesting more money is a good option, you're all insane. Money has already been paid with no visible result (not saying there has been nothing come of it, it's just the perception here), so to throw more money into the the abyss is pure insanity.
Drupal is an open source community, the majority of work done by the developers is done for the sheer love of the community and the project. Money is not a catalyst for passion (unless it is THE passion), it is an inhibitor. The best motivation to complete an issue is the necessity. If Dave hasn't got the need to resolve this issue personally then he's not going to have the motivation.
Please stop throwing money at issues, if you feel the need to throw money at something, donate it directly to the developer (buy them a beer), but with no strings attached.

 

Now, I think we should reduce the rambling and bitching (hypocrisy, I know), and get back to the issue at hand, because this issue needs fixing.

Cheers,
Deciphered.

Dave Reid’s picture

Wanted to give a quick update on this for everyone. I'm working on a full write-up of the progress that has been made so far, where we are now with the code behind the issue, why this is so damned hard and cannot be easily fixed, and why I think the current approach using the field API formatter system for tokens is flawed. I hope to have it posted by tomorrow night.

I will also not be accepting any more donations for this issue. To those who did donate earlier, I would like to say thank you. Your donations helped get this jump-started but unfortunately I ran into a wall so it would not be right to continue working on this issue for financial reasons, but instead for personal and "greater good" motivation. And I do want to resolve this is a way that is not half-assed, will work for the 80% of users out there, and in a timely manner now that this is holding a large number of people up from upgrading to Drupal 7.

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.

I am committed to resolving this issue and I apologize for the lack of feedback and progress so far. I will do a better job communicating with you all in moving and solving this tricky issue.

Everett Zufelt’s picture

FYI:

Based on the patch in #320 I rolled a working patch for node_reference at #1192504-4: Properly implement hook_token_info(). It isn't perfect, but it does what I need it to do for now.

paulgemini’s picture

This comment was redacted by its author, who is a big dummy and made a joke but missed Dave's reply directly above this comment! Original comment (paraphrased):

"Blah blah blah, bad joke, pretty funny joke, inopportune joke, bad timing, blah blah blah. Beer."

webchick’s picture

Paul, that kind of comment is neither helpful nor constructive, and only serves to completely demoralize major contributors to our project. You wanted communication on the status of things, you got it. If you can provide architectural guidance on the various blocking issues, please do. If you can provide testing once those solutions come of age, please do. But please keep your snarky comments to yourself.

mikey_p’s picture

I'd just like to remind everyone about the Drupal Code of Conduct. Lets all try to work together and stay positive towards one another so that this can be resolved more quickly.

MrPhilbert’s picture

I agree. Maybe a joke sometimes but diplomacy and understanding can go a long way. When I look at the code for some of these modules and Drupal core, I don't know how you guys and gals do it. I gets more complicated every day.
It is sometimes hard for people that are passionate about something to communicate in an effective way. We are all guilty of it. Look at it this way. We could be dependent on Microsoft or Apple and wait and wait then be told that "what we need has been determined by a higher authority".
If any of you are old enough to know who Struther Martin is, you can echo his famous quote now.

P.S. Thank you Dave for the note.

jcarlson34’s picture

@Dave Reid - Thank you for the update. It is much appreciated. I'm glad that the money I chipped in helped move the process along. Question: Is it possible to release this patch in stages? If certain field tokens work already, perhaps they can be included now with the module and side issues can be opened for the remaining token types needing to be added?

@Deciphered - The 'buy a dev a beer' chip-in plugin is a brilliant idea. I looked up the beer.me domain name but of course it was taken. drupal.org/project/beer is available though so perhaps someone can take the lead on that one. :)

paulgemini’s picture

Whoops, bad timing on my part! I was writing my comment apparently while Dave was responding and didn't even realize he'd already responded. In that context, it comes off as mean spirited and directed at him rather than just general silliness meant to entertain and diffuse the tension in this thread. Apologies.

Ha - and the more I think about it, it also must have been fairly frustrating to read what looked like mockery directed towards Dave, who had just moments earlier offered to work diligently on the issue. You must have thought, "Why is this fool attacking the guy who has just promised to work on this critical issue?" Bad timing indeed!

geerlingguy’s picture

@paulgemini - The 'edit' button comes in handy in these situations... also, the word 'redacted.' :-)

Thanks for the status update, Dave! I'm still using a patched version from a couple months ago that's working relatively well. I'm not in a huge rush, especially if the extra time makes the module more performant or future proof. Plus, it's best to get it right than to make people change the way they use tokens after a first (buggy) version.

Sborsody’s picture

I apologize for the confusion. The Entity API project (http://drupal.org/project/entity) extends the internal Drupal 7 entity API by providing a CRUD interface. In that project there is a module called Entity Tokens. You need to enable both modules. Some may find it an acceptable work-around to this issue.

AndrzejG’s picture

I am afraid that from the next Dave's message we will learn that there is no sense to develop the mechanism of formatters based on tokens or even that the concept of tokens has serious limitations. In fact, both concepts lead to infinite number of more and more detailed tokens; in consequence thousands tokens would carry all the complexity and inconsistency of Drupal system.

If so, I would suggest to establish a kind of limit for development of tokens/formatters approach and develop it to this limit. Why? Because IT WORKS. And such move would give core developers (and us, I hope) some time to elaborate better concept.

I write this because I'm not sure to attend this discussion tomorrow.

Shadlington’s picture

I'm glad this is moving along. Thank you for the update Dave, I hope it puts most fears at ease.

JohnnyX’s picture

Thank you for the update! I'll take a look at taxonomy_entity_index

Stolen Squirrels’s picture

@Dave Reid - thanks for the update. Let us know if/how we can help.

spacereactor’s picture

#380 you also need to run cron after new field is added in order to update as new entity tokens

luco’s picture

subs.

#386. yeah, I'm old-fashioned. :]

sammyd56’s picture

Looking forward to reading the status report. Drupal badly needs this project to move forward... don't leave us hanging Dave!

hgmartini’s picture

One more subscription.

torgosPizza’s picture

Subscribing!

ikeigenwijs’s picture

subscribe,
I hit a wall with this problem.

mrconnerton’s picture

sub

mudsurfer’s picture

subscribing

tsvenson’s picture

@davereid: Quick question. Is there any risk that the available patch in this ticket will be incompatible with what you are working with. That is, I will have to redo a lot of stuff using field tokens once your solution is implemented?

Yuri’s picture

Thanks for the update, Dave.
Subscribing.

Pasqualle’s picture

.

sonar_un’s picture

Subscribing

Nikdilis’s picture

Tomorrow night is coming soon....... ;-)

benmalen’s picture

Subscribing

ranx’s picture

subscribe

grossmann’s picture

subscribe

SeriousMatters’s picture

subscribe

amarnus’s picture

thebuckst0p’s picture

Subscribe.

Trunkhorn’s picture

Surely, this is some kind of joke?

If so, I don't get it.

thebuckst0p’s picture

The list of reasons why I'm not going to use D7 for any more projects keeps getting longer, and this one just bumped to the top of the list. I'm not a core contributor, so those who are can dismiss what I'm about to say if they wish, but as a developer who has worked with Drupal for years, active in the community, and contributed a number of modules, I think the development cycle for D7 and now D8 has gone off the rails, losing focus, making the code base too complicated to work with, losing critical features in the process, not letting contrib catch up before another half-baked core release is announced. It's a real shame.

thebuckst0p’s picture

I'm now getting a 416 error loading the 2nd page of this post, "Requested Range Not Satisfiable. None of the range-specifier values in the Range request-header field overlap the current extent of the selected resource." I think that's Apache's way of saying "+1, WTF."

sammyd56’s picture

I'm beginning to think Trunkhorn may be right. I wonder how many people have been watching Dave's twitter feed for some kind of update, only to be deluged pictures of cats, complaints at Google's slow development, and boasts of how many new modules he is creating? If this is how one of the most respected members of the community sets their priorities, I want no part of Drupal. How do I unsubscribe?

xjm’s picture

(Edited to avoid feeding the trolls.)

MrPhilbert’s picture

I live right above Microsoft. I remember when Windows Millennium edition first came out. Everyone in my neighborhood new it was just a stop gap. In fact, work had begun on Vista long before. Non Microsofties (like myself) were not very impressed with how this was done. We all thought they should have focused more on fixing XP and then work on a better Vista when it came out. It turns out that Millennium just sucked up resources that gave current XP users headaches and ultimately left Vista users disappointed.

If this sounds like it might be a round peg in a round hole, please raise your hand.

More than anything I'm hoping that I am dead wrong!

Should I have waited for the real D8 (er Vista) or should I just relent and let my neighbors convince me about the power and versatility of (gasp!) ASP.net?

Shadlington’s picture

I really don't see why anyone is bringing D7/D8 into this.
This is contrib, not core.

...I am not even going to touch the other points raised today for the same reason as xjm edited his post.

pillarsdotnet’s picture

WHO IS WALKING OVER MY BRIDGE?

Trunkhorn’s picture

It really does seem that developers are backporting the changes in D7 to D6 instead of bumping their clients to D7.

This makes sense considering D7 came out a year after the date Dries originally projected, and that D7 sat with a pile of critical issues for 6 months after its release.... and still has a few critical issues currently floating that would put developers off of upgrading.

So the safest thing is to backport and that has really suffocated D7 contrib.

D8 may be better when it comes out... two to three years from now.

Shadlington’s picture

...D7 will be better when D7 contrib has time to mature.
The situation for D7 right now is better than the situation was for D6 when it was first released.

And this is really off-topic. Can we stop, please?

Trunkhorn’s picture

Uh no... I lived through the D6 release and this is about 2x worse at this point.

In D6 everyone was waiting 6 months and longer for the stable Views release, but core already had multiple stability releases.

We still have the same situation now, except we are still waiting for Core to get rid of its criticals.

tsvenson’s picture

Please stop all the off-topic comments, its enough with all the "subscribing" comments! D7 vs D6 debating definitely does not belong here.

JohnnyX’s picture

Please stop it. I wouldn'd read all these off-topic comments....

AndrzejG’s picture

Please stop and try to find proper solutions having such tools as we have. My first two sites in D7 are working excellently, one of them really complex.

todddevice’s picture

subscribe

millaraj’s picture

subscribe

Jean Gionet’s picture

sub - upgrading from d6 to d7 produces this error as well as one for the contact module update.

thummel’s picture

subscribe

devilpigeon’s picture

bump bump trumpy trump. trumpity trumpity trumpity trump. a-wump a-bump a-slump a-trump. buuuuuuuuuump bump bumper bump. wumpy wumpy wumpy "it's pronounced throat-warbler mangrove!" wump.

paolomainardi’s picture

Subscribe

dmenefee’s picture

Subscribe.

Tyrael’s picture

offtopic:
for the pager of death problem, you can use the following url:
http://drupal.org/node/691078?comments_per_page=10000000
this will show all(okay, not all, only the first 10000000) comments for that topic.

Tyrael

MrPhilbert’s picture

Hilarious!
You might be short a zero though.

"A chuckle a day keeps the frustration away"

koro’s picture

subscribing

webchick’s picture

Tagging as a stable release blocker (hopefully that's not being presumptuous).

GiorgosK’s picture

Still no update from Dave ?
subscribing

webchick’s picture

Restoring tag.

damien_vancouver’s picture

Hopefully this won't remove webchick's tag for +D7 stable release blocker, which was definitely not presumptuous.

As far as I can tell, what is really blocking this issue from anyone else jumping in and helping is that we are all waiting for an explanation as to why the patch we were testing is a flawed approach. In his June 21st update, Dave alluded to working on:

a full write-up of the progress that has been made so far, where we are now with the code behind the issue, why this is so damned hard and cannot be easily fixed, and why I think the current approach using the field API formatter system for tokens is flawed.

which was hopefully going to be ready by the next day. Sadly, it was not.

As someone who is using the patch that was originally on this issue, and has been for 3 months now on a nearly production site with users in there and no problems, I am now left in a rather awkward spot. I hope to release this site on August 1st, yet I'm relying on functionality from a patch that I can only assume is going to be scrapped. On the other hand, the issue is going nowhere and i have had no problems with the patch on this thread. Without that writeup, I don't understand why that patch is no good, what the alternatives might be, what can be done by any of us to help get to a stable solution.

In short, we really need that writeup.. either from Dave, or someone else who appreciates the scope of what's required to get a solution that can work for everybody. I donated with the chip in along with many others hoping that would move the issue along. Personally I'd feel I'd gotten my money's worth from the chip in if I saw even the writeup at this point. I appreciate the issue is much more complicated than I realize, and would really like to understand the problem at least. Plus with this many subscribers I think we'd see some movement towards a fix if we all understood the situation clearly.

kmdesign’s picture

Why doesn't Acquia jump in and fix this? If webchick's missive today on ported modules holding back D7 stability has any teeth to it (and a bite was firmly planted on this issue early this morning -- see #430), then surely the issue is serious enough to sprint it to a fix by a team of experts who truly care about the reputation of Drupal, no?

I don't get it. The harsh reality is, I need field tokens like I need custom content types. Or to put it another way, I have a $5K stereo/amp and $50 pair of broken speakers that have no bass. Contributors need to realize that there will be times when their modules become so relied upon by the developer community that they essentially become part of "core" as well (Views 3, anyone?). It doesn't matter to me now whether Token is a contrib module or part of core. I, along with 1,000's of other developers need the module to work with D7, period. The fact that a Chip-In was started on this, and that people contributed to it, should be enough of a signal to the powers that be, that this module needs some love and attention, now.

Come on developers of other modules, it's time to get involved. Fix this oversight. Solve the difficult problem associated with this module—the one that I'm certain is quite true, and quite complex to solve. No diminishing the task at hand. I'm certain it's difficult and time consuming. But it has to be solved.

As for the patch that's seemingly out there, like damien_vancouver, I'm all for alpha and beta testing, but not for running a client site on a patched module. Drupal is funny like that: it's mostly contrib, yet the community forgets that businesses are running on the stability of D7 and contrib modules. So I ask... doesn't someone have a responsibility to make sure contrib modules that reach a certain use-rate get priority attention? ...especially when they're not yet fully ported to D7? Token is at 215,000-ish, +- a few 1,000 each week. A quarter-million!

I'll leave with this: BrowserID module, from announcement to module in one day? Brilliant. Google+ module week after release? Facebook-take-that. Token module 6 months after D7 release and still no seriously presented road map to a solution? Priceless. For everything else, there's Mastercard,... for which I'm willing to break out and use, if someone would just solve this incredibly annoying issue.

kmdesign’s picture

Issue summary: View changes

Adding 2011-06-21 update

webchick’s picture

Status: Needs review » Postponed

Hi, folks. Dave Reid, chx, and myself spent some time on the phone today to hash out the remaining architecture issues. I've updated the issue summary at http://drupal.org/node/691078 with the current status of things.

If you're a developer, there are pointers to other issues you can help out with, including the large architecture discussion that needs to happen.

If you're a site builder who can't actually help with this stuff, please stay tuned. We'll update this issue as major developments occur.

For now, marking this as postponed.

GiorgosK’s picture

@webchick
first issue in your summary (#1222592: Architecture RFC: Field token architecture) is regarding Drupal 8 or is that a mistake ?

webchick’s picture

Since it's a Drupal core issue, to solicit wider feedback, it goes against 8.x in order to get more eyes on it. But the discussion there is for solving this issue, for the 7.x version of Token.

GiorgosK’s picture

I suspect since there is many more available/willing people to test 7.x modules than 8.x core that issue might stagnate from lack of 7.x patches to review/test (or will there be 7.x patches ?)

Dave Reid’s picture

The core issue is an attempt to get feedback on the architecture from other core maintainers, especially Field API maintainers since the solution and implementation that is used in Token.module for Drupal 7 should be of core-quality and moved to Drupal 8 core when completed. We need their feedback and input that was sorely missed when this issue was bumped from core to contrib. Patched and reviews of the token patches will likely happen in a separate issue for token.module and we will keep this issue posted with progress only.

keithm’s picture

subscribe

zilverdistel’s picture

subscribing

kbond’s picture

Status: Postponed » Needs review
Issue tags: -Fields in Core, -token, -url. views, -D7 stable release blocker

#320: field_tokens-691078-320.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Fields in Core, +token, +url. views, +D7 stable release blocker

The last submitted patch, field_tokens-691078-320.patch, failed testing.

kbond’s picture

Status: Needs work » Postponed

oops, sry

pumpkinkid’s picture

I hate doing this... but I need to keep track of this... Subscribe...

AlanAtLarge’s picture

subscribe

antiorario’s picture

Subscribe

NicolasH’s picture

subscribe

Alan D.’s picture

To miss the paging issue / slow loads, book mark the following link, incrementing the comments_per_page parameter every now or then. :)

http://drupal.org/node/691078?page=2&comments_per_page=446#new

pillarsdotnet’s picture

Alan D.’s picture

With all the other 147 other comments on page 2 ;)

I am glad there is some life in this issue at long last, in other threads. Maybe there will be a resolution in sight soon, albeit these are leaning towards resolving this in Drupal 8 core, which may result in slow progress...

bryancasler’s picture

+1 for pillarsdotnet's solution, that's what I've been using. Mix up your drupal dashboard and switch the two main columns. The links provided for new comments in my first column are different than those in the second. See this screenshot to know what I'm talking about. http://awesomescreenshot.com/091h0a8c9

aweizd’s picture

subscribe

Pomliane’s picture

+1

ecksley’s picture

Subscribe

Kolibri’s picture

Subscribe

kurtzhong’s picture

#143 patch doesn't work for me.

Why drupal org doesn't provide a follow button or a subscribe link? Feel so evil to put a meaningless 'subscribe' here. : )

NancyDru’s picture

sub

ar-jan’s picture

Aaah.... dare I say it? ... Subscribe!

Tim Jones Toronto’s picture

I'd like to be part of Drupal history with this thread. Sub.

geerlingguy’s picture

I'd like to be part of Drupal history with this thread. Sub.

+1 - does anyone know what the longest thread on drupal.org is? I know #644538: Duplicate order notification e-mail, and duplicate stock decrement hit 355 lately, and I recall another 400+ comment issue... Of course, with Issue Summaries (and someday, hopefully soon, subscriptions), this could stand as the longest issue for a very long time.

...and to anyone coming into this issue at this point, please re-read the issue summary, and if you want to help brainstorm the proper solution, the action is currently in #1222592: Architecture RFC: Field token architecture, as was mentioned earlier by webchick, Dave Reid, et all.

badrun’s picture

Category: task » feature
Priority: Major » Minor
Status: Postponed » Active

subscribe

tsvenson’s picture

Category: feature » task
Priority: Minor » Major
Status: Active » Postponed

@badrun Please don't change issue setting unless you really know what your doing!

Bevan’s picture

This version of the patch applies to 1.0-beta3.

Bevan’s picture

Wtf!?

pragnatek’s picture

sub

alphasupremicus’s picture

Subscribing....(what can I do to help this get into the module?)

GiorgosK’s picture

@Bevan
applied the patch by hand
netbeans reported that could not be applied to current context (I have applied lots of patches before)
so I created a the same patch for any one that has the same problem

Anyway I am not exactly sure how to test this !!!

badrun’s picture

@tsvenson

Sorry, I am really don't know what I did. I just want to subscribe to the issue.

TimelessDomain’s picture

Status: Postponed » Needs review

Status: Needs review » Needs work

The last submitted patch, 691078-466_same_as_462.field_tokens.patch, failed testing.

alphageekboy’s picture

Assigned: Unassigned » alphageekboy
Status: Needs work » Needs review
FileSize
21.33 KB

Updated patch file to use unix line endings.

Status: Needs review » Needs work

The last submitted patch, 691078-466_same_as_462.field_tokens.patch, failed testing.

mducharme’s picture

subscribing

pillarsdotnet’s picture

Assigned: Unassigned » alphageekboy
Status: Postponed » Needs work

Since this patch is not part of the current plan for Field tokens, please open a separate issue to bounce it off the testbot. According to the Issue Summary:

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

and:

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

Status: Needs work » Postponed

Resetting to postponed.

pillarsdotnet’s picture

Assigned: alphageekboy » Unassigned

Unassigning.

W.M.’s picture

Assigned: alphageekboy » Unassigned

subscribing

Mark Trapp’s picture

Status: Needs work » Postponed
dellis’s picture

subscribe - it would be great to have this automatically available
--I came across this though (haven't tried it yet) for people who need something asap:
http://mackstar.com/blog/2011/06/17/how-add-your-own-tokens-cck-fields-d...
and the Entity Module seems to help with some of this too

oliveyrc’s picture

subscribe

dwalker51’s picture

Subscribe

askibinski’s picture

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

sub

MrPhilbert’s picture

Just tried token replacement and it worked like a charm.

Oh wait, I was just experimenting with Orchard CMS.

As much as I like Drupal, it's issues like this that are making me look elsewhere.

fizk’s picture

Drupal history, here I come!! Subscribe.

kbond’s picture

@MrPhilbert I agree.

nmc’s picture

subscribe

AniaMi’s picture

Subscribe

ewills’s picture

Subscribe

jboeger’s picture

Suscribing.....

Isostar’s picture

Subscribing

Danny Englander’s picture

Subscribe

Darryn’s picture

Subscribe....

devilpigeon’s picture

it amazes me we can (apparently) get to the moon and back in the space of 8 days in 1969, yet this seemingly trivial issue in comparison has dragged on and on with no solution in sight.

it's a joke. my development in drupal has ceased. i shall not return, save an almighty overall positive re-write for D8 (not holding breath).

chx’s picture

@devilpigeon that 8 days took eight years to prepare and 24 billion dollars. Get real.

fizk’s picture

@chx It would've been 8 days from start to finish on an 8 dollar budget if they had you working in NASA back in '69. Sheesh...

thebuckst0p’s picture

NASA metaphors aside, I think this issue reflects a very serious broader problem in Drupal 7, that the code is becoming too abstract and complex to work with. I wrote a blog post about this recently and would be very interested in the perspective of chx and other core devs.

geerlingguy’s picture

@thebuckst0p - I've written an additional followup to your blog post (and others like it), here. I think it's unreasonable to consider abandoning Drupal because of one or two relatively small issues, like this one. There are many different workarounds, and yes, they may be slightly inconvenient... however, the situation is not much different than Drupal 6 (though there are a lot more people lurking about drupal.org these days), where there were (and sometimes still are) a few issues that really peeved me, but that I could not do much about.

I always found a way to move along and get the job done with Drupal, and this is something that's simply not possible with many other platforms. Maybe it's a little tougher until Token works better, but it's possible.

I do agree with the sentiment that it would be helpful to see increased communication about the progress of this and other issues on drupal.org, but I don't expect it—I simply hope for it, and carry on.

wizonesolutions’s picture

Folks, please read the Issue Summary up top. There are several issues that must be solved before this one will get any updates. I wouldn't expect any updates till then. I hope this comment gets seen...I felt the same way until I realized there were other issues at play.

devilpigeon’s picture

@thebuckst0p - spot on. very well written article. when you're working with abstracted layers of abstraction, then something's come off the rails at some point. to me, the only solution moving forward at this point is a ground-up rewrite, not a half-arsed attempt at 'untangling the untangleable'. i also think that strict deadlines, and sacrificing usability in order to maintain those deadlines, is doomed to failure.

Trunkhorn’s picture

The reality is that drupal.org is practically broken for devs so they are less likely to float here around users.

Now webchick, who has been the brightest light to begin to take reigns and fix things is sidelined because her father is ill.

D7 is dead people.

There is really no use for everyone to continue complaining in this thread... let's face the obvious.

How in the world taxonomy got converted into a field without the ability for the value of that taxonomy to be available to panels and other modules is beyond reasoning.

It's as if they wanted to convert the taxonomy system into the completely broken blocks system.

It's whack, and we can only hope a rational group forks someday, fixes the issues which are probably leadership driven, and brings it back to drupal .org to save the day.

geerlingguy’s picture

I'm presuming the previous post was written as a joke? If not, I think I just fed a troll.

Drupal 7 is alive and kicking.

MrPhilbert’s picture

Asp.net mvc 3, razor view engine and nuget package manager. 30 minutes to something custom. The borg is getting harder and harder to resist.
I've been beating my head against the wall with D7. Even the folks at palantir seem to be focused more on other systems (node.js anybody?).
Still hopeful though.

Sorry to hear about Webchicks father. That is much more important than anything she could be doing here.

gdemet’s picture

I've been beating my head against the wall with D7. Even the folks at palantir seem to be focused more on other systems (node.js anybody?).

We've been focused on Drupal 7 work for about a year and a half now, and to date have not done any node.js projects. Perhaps you're thinking of another firm?

MrHaroldA’s picture

Drupal 7 is alive and kicking.

Couldn't agree more! D7 kicks ass!

bleen’s picture

subscribing

Encarte’s picture

Sorry, but:

a) This issue is not about Drupal being alive or dead. All discussions are legitimate and may be useful, but, imho, they should be posted like in #495 (just a link is enough).

b) Bringing up private lives (#499) in this issue (specially about deceased loved ones) is purely bad taste and almost trollism (I say «almost» to not get too aggressive, but this is unacceptable behaviour).

Could we spare time to everyone and avoid coming here to read off-topic messages? All we want is to know news about tokens, for the rest there is http://drupal.org/planet and lots of other places. Thank you.

Trunkhorn’s picture

Hey Encarte,

She posted the info on her twitter, so it's public knowledge as far as I can tell. The point was that she has been instrumental in getting D7 back on track these past two months and especially getting Dave Reid to break his nearly psychotic silence on this issue, and that she was understandably going to be away.

Not to be too aggressive, but the only troll in this situation is you, and the rest of the devs that can make drupal 7 work while regular end-users are told to either pay to play or STFU.

Are you blissfully ignorant of the garbage that went down in this issue? Namely Dave Reid taking money through chipin before his honeymoon to solve this issue, and then play quiet for weeks after saying again and again he was going to update us all, while apparently having hours of freetime to discuss cats on twitter?

Seriously, D7 is dead for endusers...I guess I should have been more specific.

Truly the definition of "Freemium".

erikwebb’s picture

Sub.

Dave Reid’s picture

Basic level field tokens (e.g. [node:field_tags], [node:field_image], etc.) have been committed to Token and included in 7.x-1.0-beta4 release.

Next up working on tests for the basic-level field tokens, and then the array issues for nested/detailed field tokens. If you are a core developer, please try to help take a look at #1222592: Architecture RFC: Field token architecture.

No need to comment on this issue with a reply about the release or a swear word at me for my past mistakes. If you encounter bugs, please file a new bug report in the module.

cweagans’s picture

Issue summary: View changes

Locking thread.

AndrzejG’s picture

Thanks, Dave.

jcarlson34’s picture

Thanks Dave! That's great news.

jcarlson34’s picture

Thanks Dave! That's great news. doh double post...

sammyd56’s picture

As (presumably) one of the "H8TERS" who you'd like to tell to "SUCK IT", I would in fact like to thank you for your work. This is excellent news for many, many Drupal users :)

Off to test...

Dave Reid’s picture

We can stop linking to my tweets now - thanks. That is my public place to vent and I attempt to make a good faith effort to stay professional on drupal.org which includes better communicating with everyone.

And if you're already subscribed - seriously there is no need to add any comments. I'm just trying to make this only about keeping everyone updated now.

For anyone that has a module that provides a field type I have already started the documentation page on how to support tokens for your field.

damien_vancouver’s picture

@Dave Reid, thank you so much. Just having this limited functionality with the basic tokens does exactly what I needed for both my use cases.

I'm using it to output custom block titles off fields, and to build custom filefield paths based on a Term Reference. In both cases, the defaults you've chosen to go with for the basic tags (value for text and the term name for the term reference) work perfectly. I am extremely stoked!!

To clarify for people, here's what you'll get with the Token 7.x-1.0-beta4 release:

-You will get one token for each field, found under Nodes. It will be named: [node:field_fieldname]

-For text fields, the token is going to contain the value of the field. I'm guessing this will work the same for other simple types like Integer. In the patch on this thread, this was [node:field-fieldname:value].

-For term Reference fields, the token contains the name of the selected term. In the patch on this thread, that was [node:field-fieldname:term:name].

You will be unable to get anything other than this one value for each field at this point, though that functionality is coming later. If you were relying on anything other than the :term:name for terms or the :value for other fields, then you are going to have to wait a little longer. But if you are just after simple values as described above, you should be good to go.

If you're upgrading from the old patch on this thread, here's what to do:

First upgrade your token module to 7.x-1.0-beta4. Then you will have to edit each place you were using the old field tokens and fix up the token names to match the correct names going forward.

In particular, the hyphens in the field names are now underscores, and you have to remove :value or :term:*, anything like that at the end, as there is only one token per field now. If you look in the list of tokens under “Replacement Patterns”, you will find the new terms under Node and alphabetized by field name.

ts145nera’s picture

I try to apply by hand the patch http://drupal.org/node/691078#comment-4799174 (#470) to token beta 4 and it work fine for me for date token field.
I export this in another patch that is the same of #470.
Please review it
Thank you

pillarsdotnet’s picture

I export this in another patch that is the same of #470.
Please review it.

Please do not post patches to this issue.

Please ask someone to translate the issue summary into Italian for you. Please read and understand the Italian translation.

Please post patches to:

DamienMcKenna’s picture

Is it time to close comments on this and move all work to the other tickets? Maybe also update the ticket summary?

Dave Reid’s picture

I'm going to lock comments. At over 500 comments that's sending a lot of e-mails to everyone commented here.

For everyone's convenience with respect to keeping everyone updated on this issue that still wants to be we have a 'Tokens' group on at http://groups.drupal.org/tokens. I will be using the Broadcast functionality to send out an e-mail update to all group members with major updates to this issue's progress.

So again 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 also be sure to add comments manually to this issue when there are updates as well.

Dave Reid’s picture

Issue summary: View changes

Update for 2011-08-17

Gaelan’s picture

Status: Postponed » Needs review
Issue tags: -Fields in Core, -token, -url. views, -D7 stable release blocker

Status: Needs review » Needs work

The last submitted patch, 691078-466_same_as_462.field_tokens_remake.patch, failed testing.

maio1980’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 691078-466_same_as_462.field_tokens_remake.patch, failed testing.

kocurmatus’s picture

Status: Needs work » Needs review

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

jaydalpe’s picture

#143: modules_token.92.patch queued for re-testing.

designarti’s picture

Status: Needs review » Needs work

The last submitted patch, 691078-466_same_as_462.field_tokens_remake.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

locking comments again - link to group for subscribing