Tokens in field help text do not work for files, images, text fields

@DerTobi75, are you certain that it "All other help text fields seem to work just fine"? I can't get it working for any field.
@see http://drupal.stackexchange.com/questions/48483/drupal-7-tokens-in-field...

What tokens are you trying to use?

Will try to confirm shortly.

Confirmed. This is an issue with multiple-value fields, text fields, date fields, etc. I'm not finding any clear way that we can alter or futz with the description string in a reliable way that works on all fields and widgets. I'm wondering if I should just pull the 'support' from Token and try and push for the tokens in descriptions patch for core.

Push! Still not working!

Confirmed. This is an issue with multiple-value fields image

Just thought I'd quickly provide our own workaround:

/**
 * Implements hook_widget_form_alter().
 */
function mymodule_field_widget_form_alter(&$element, &$form_state, $context) {
  if(!isset($element['#type']) && function_exists('token_field_widget_form_alter')) {
    _mymodule_field_widget_form_nested_apply_tokens($element, $form_state, $context);
  }
}


function _mymodule_field_widget_form_nested_apply_tokens(&$element, &$form_state, $context) {
  if(isset($element['#type'])) {
    token_field_widget_form_alter($element, $form_state, $context);
    return;
  }
  foreach(element_children($element) as $key) {
    _mymodule_field_widget_form_nested_apply_tokens($element[$key], $form_state, $context);
  }

This ...-8.patch (against 7.x-1.x ~ >= 7.x-1.6) provides token replacement for all core field types' description (help text), plus date fields and field collections - and most likely a range of other fairly FAPI-faithful contrib/custom field types.
And multi-value'd instances are also supported.

The only known limitation so far is multi-value'd field_collection attached directly to an entity/node (not nested in another field collection). And that issue is probably a won't-fix, because the amount of code and static vars required to fix it would hardly justify the means (or an issue for the field collection project; a field collection - in that context - thinks it's parent is itself ;-).

The code doesn't assume well-formnedness API-wise from field instances (like: doesn't use values of array/object buckets unless it's certain they exist). Aborts gracefully if expectations aren't met.
The code also prioritizes performance: there's no need to do a lot of 'detective work' on the field at hand - and run the description string through a handful of expensive regexes (xss filtering and token scanning) - if the description definitely doesn't contain a token.

The algo is a spin-off from Localize Field (which translates field labels and descriptions) - thus a result of much FAPI reverse engineering, variable dumping and testing, testing, testing...

Really hope I haven't promised too much.

Changed issue version to 7.x-1.6 (from 7.x-1.4) - though not sure if that's OK(?) - to make ...-8.patch applicable/testable.

Features based module for human-aided testing.
It's node form - /node/add/tokdesctst - displays how many/which fields' descriptions don't get token replaced.
module: tokdesctst
node type: tokdesctst
field names: field_tokdesctst_*
tax vocabulary: tokdesctst
contrib dependencies: date, date_popup, features, field_collection

1. +++ b/token.module
   @@ -271,11 +271,155 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   + * Replaces tokens in field descriptions of (primaryly) single-value'd
   

   primaryly to primarily and doesn't need parenthesis.

2. +++ b/token.module
   @@ -271,11 +271,155 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +  if (!empty($context['instance']['description'])) {
   

   Instead of the excessive nesting here maybe consider returning early at the top?

3. +++ b/token.module
   @@ -271,11 +271,155 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +          // list_ types.
   

   Maybe change this comment to a sentence or remove.

4. +++ b/token.module
   @@ -271,11 +271,155 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +              $a = explode('<br', $props['#description']);
   +              $a[0] = $modified_description;
   +              $props['#description'] = join('<br', $a);
   

   Why is this exploding a partial tag?

5. +++ b/token.module
   @@ -271,11 +271,155 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +  // There's another description in $variables['element'][0]['#description']
   +  // but haven't found a field type that gets that one rendered.
   

   @todo?

@joelpittet Thx a mill for feedback.

1. Fixed.
2. Fixed.
3. Won't fix. The comment says 'list_ types' because the following block works on (matches) type like list_text etc. Thus nothing much more to explain; and removing the comment would mean loss of important information.
4. Because it works. File fields tamper with the description to display stuff like allowed file extensions.
5. Nope, no @todo - would be an utter waste of time. However, if it really turns out that that other description gets rendered in some exotic context, then we can - at that time, having a known example - try to fix things for such context.
   But comment part replaced with 'but that normally doesn't get rendered.', which at least moves the POV from first person.

You're welcome, just a drive by review on my way to token vs entity_token duplication issue:)

Thanks for the quick fixes!.

One more and more context to #17.5

1. +++ b/token.module
   @@ -271,11 +271,155 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +          unset($element); // Clear ref.
   ...
   +            unset($element); // Clear ref.
   ...
   +      unset($element); // Clear ref.
   

   We don't do inline comments like this in coding standards.

2. +++ b/token.module
   @@ -271,11 +271,155 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +  // There's another description in $variables['element'][0]['#description']
   +  // but that normally doesn't get rendered.
   

   May be worth moving this up to the top or to a relevant line it looks like it doesn't belong to anything (after thought)

Stumbling across this, just fixed the notes from #19.

Code looks good, @jacobfriis thanks a lot for this.
(Academic note: i don't think the commented unset() lines are necessary as the ref is unset in the next return line anyway, but what the heck, php will optimize this away anyway then.)

Crosslinking related issue #2564437: Provide entity tokens in field help: Whichever gets in first, the other must be rebased.

@joelpittet Cleaned up according to #19 ;-)

@axel.rutz Aye, you're right, thx. Unsetting those references is obsolete. Overly paranoid about references. They are gone now ;-)

Here are some small things I noticed:

1. +++ b/token.module
   @@ -271,10 +271,148 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +  if (strpos(' ' . $original_description, '[')) {
   

   if (strpos($original_description, '[') !== FALSE) {
   

2. +++ b/token.module
   @@ -271,10 +271,148 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +            $limit = 100;
   

   something like..

   foreach (element_get_visible_children($element) as $key) {
   

   see: element_get_visible_children

3. +++ b/token.module
   @@ -271,10 +271,148 @@ function token_form_block_admin_configure_alter(&$form, $form_state) {
   +          elseif (!empty($props['#description']) && strpos($props['#description'], '<br')) {
   

   strpos($props['#description], '<br') !== FALSE
   

One other thing...

This patch won't work with i18n_field because i18n_field will translate the element description in the same hook.
In the current patch, the translated description will be overwritten by the original (instance) description.

Patch with i18n support and works almost like the i18n description translation.

Small update, now without the double field_filter_xss()

Patch #26 doesn't fix the issue for multi-valued fields.
Testable via the attached tokdesctst Features module.
You'd have to implement hook_preprocess_field_multiple_value_form() to fix that.

Patch #22 does handle multi-valued fields. However that patch isn't applicable anymore.
Hardcoding a call to another contrib module - i18n_field - into this module is sort of ugly.
So I'll be on my way, off this issue ;-)

Hi,
Does this issue relate to #2653768: Help Text of multi-value File field NOT translated if Token module is enabled ? Thanks

Haven't tested for translations yet, (...) but will...
patch 26 did fix token support for address field help text in default language for me already.

p.s. i don't see any problem with the if statement if (module_exists('i18n_field')) how else to support translations?^^ Find it actually quite comforting to see it in there since I do develop a multilingual site.
Will report back on token support in form translation when my project reaches the translation phase.

Thx for the patch ;-)

EDIT: Looks I spoke to soon for address field, since all address field help texts are now doubled^^ one time with toke replacement and a second time without replacement^^

I needed this to work for a text field so I made a simple patch to token_field_widget_form_alter() in token.module to use the token-replaced value for "child elements", in this case "value". Works fine for my case, but haven't tested with image etc.