Basic token support in fields' help texts

I've added a few more lines this patch so that it now adds token support for all of the following:
- field default value
- field help text
- field description

I was considered rolling this functionality into either a token.module patch or a contrib module, but it ends up being much more efficient to simply place this change in core.

Issues requesting this functionality:
http://drupal.org/node/1070878
http://drupal.org/node/1248306

+++ b/modules/field/field.moduleundefined
@@ -501,6 +501,13 @@ function field_get_default_value($entity_type, $entity, $field, $instance, $lang
+
+  foreach ($items as $key => $value) {
+    if (token_scan($value['value'])) {
+      $items[$key]['value'] = token_replace($value['value']);
+    }
+  }

This only works if the default value is a string. Also it's unnecessary to call both token_scan(). token_replace() will do nothing if it doesn't find any tokens.

12 days to next Drupal core point release.

We also need to apply this to D8 first, then consider backporting if possible to D7.

Thanks Dave,

I replaced token_scan with is_string. Think that'll do the trick?

This still needs to be patched for Drupal 8 first, which is where any changes for core have to go first.

my bad, that last patch recorded two commits. I also hadn't noticed your drupal 8 change.

I'm attaching two patches here, one for d7 and one for d8.

switching to 8, sorry about this back and forth.

Dave-- please let me know what I can do to help move this patch into D7.

Thanks!

Lol, not trying to detag this either.

#7: d8-token-support-field-settings-1308564-1.patch queued for re-testing.

#7: token-support-field-settings-1308564-1.patch queued for re-testing.

#7: token-support-field-settings-1308564-1.patch queued for re-testing.

Amontero, thanks for putting time into this. I think that splitting up the patches is a fine idea. Let me know if you need any help pushing this through.

Patch d7 #17 works fine for me on 7.12

amontero, thank you for the patch.

it works fine on D8!

I like the idea (and due to what the patch entails, am tagging as 'needs backport to D7'). And the code looks good to me as well. However, I haven't manually tested it yet, and I do think it could use a test to make sure it works as expected and doesn't have an effect on something else we don't know about as a result of the patch.

Also, the D7 patch should be in this issue.

Tested the D7 for few month now, and havent seen any side effects
Re queuing both patches for testing, hoping the D7 on will make it !

-Edit, ok, so we have D8patch that passed, so it wont be tested again, and a D7 one that cannot be tested because "Patches can only be tested against the current version of the issue."

So here is the D7 backport issue : #1695984: Basic token support in fields' help texts - D7

The patch works fine for D8. Tokens get replaced in help text of all the field types including image.

This issue still needs an automated test for the feature's functionality. Thanks!

First attempt at adding tests. Locally the field test is working but I haven't gotten the image one to pass yet. Assuming its something simple I'm missing.

Alright. I think I got the image piece figure out. The createImageField() function didn't add it in anywhere so I added it there.

Moving back to needs review as the patch that was meant to fail is the only one that failed.

If you dont want a file do be tested, you should name it "whatever-do-not-test.patch" ^^
As explained on the advanced patch contributor guide http://drupal.org/node/1054616

@guile2912 in this case, the point was to prove that it would fail. It's called Test Driven Development.

Good call @Amontero. There is definitely a chance it could happen overnight. I just had started with date just as a test and never changed off it.

Don't we need something to indicate that you can use tokens here when entering the help text?

Looks like this still needs work? It does not seem to still need tests, however. :)

Re-rolled patch for changed Field module structure.

This looks good to me, but we are over thresholds atm. :(

Woohoo! Below thresholds again.

Committed and pushed to 8.x. Thanks. Moving back to 7.x. I think this is eligible for backport (note that it does include a string addition, but on the backend), but would not hurt to get David's two cents on this.

An Interdiff would be nice (against the D8 patch) if you have time.

#54: issue-1308564-token-support-in-field-descr-D7-54.patch queued for re-testing.

I was pointed to this issue in IRC and I see there is also a secret request for my feedback in some of the comments above :)

Anyway, it seems pretty reasonable to me.... though I must say I wonder what happens if you've written a field description that is trying to refer to tokens rather than use them? Example from the User module (this isn't a field, but I don't think it's too much of a stretch to imagine an actual field that has a similar description):

function user_admin_settings() {
....
  $email_token_help = t('Available variables are: [site:name], [site:url], [user:name], [user:mail], [site:login-url], [site:url-brief], [user:edit-url], [user:one-time-login-url], [user:cancel-url].');

  $form['email_admin_created'] = array(
.......
    '#description' => t('Edit the welcome e-mail messages sent to new member accounts created by an administrator.') . ' ' . $email_token_help,

So, um, we should think about that a bit.

I'm also not sure I see the point of the new help text in this patch if all it's going to say is "This field supports tokens". That doesn't mean much on its own, and probably isn't guaranteed to be true for all fields (in Drupal 7) anyway if, as the patch shows, some fields like those provided by the Image module need to do extra work to support this... So maybe that can just be left off and leave the help text to the Token module, or something?

Well, they'd have to switch to using the html entities in order to display that right? I think it's a totally valid concern, but I also think it's worth it. Still...

$email_token_help = t('Available variables are: [site:name], [site:url], [user:name], [user:mail], [site:login-url], [site:url-brief], [user:edit-url], [user:one-time-login-url], [user:cancel-url].');

is REALLY ugly. That being said, I still think it's probably worth it.

With regard to your second issue, I 10000% agree. I spent a good 10-15 minutes just hunting around for a good example of tokens supported by this field. However, since this is a field #description, I'm not sure any field has to do extra to support it, unless the field is trying to expose it's own values to the help text as well, which seems an incorrect way to use it since you can get help text for a field you've not yet filled out. :-S

Eclipse

I propose that #514990: Add a UI for browsing tokens is a precursor to this aspect of this issue, because once that issue is resolved we would want to implement the actual token browser in lieu of the help text.

The status of this issue is a little confusing. An automatic comment says there is a commit for Drupal 9.1.x.
Is the status correct, or should it be Needs work?

I agree with @apaderno that this is confusing.

This was committed to 8.x and re-opened for backport to Drupal 7, then moved back to 8. From what I gather it was re-opened because simply adding 'this field support tokens' is not very useful to the user and should be improved. Searching the issues I see that there is an issue to improve the user experience with using tokens, #514990: Add a UI for browsing tokens. It seems reasonable to put effort into that issue instead of trying to do something in this old, rather untouched issue.

Therefor setting to fixed at the time this was committed.

Cheers,