I just call token_replce without further args for basic token substitution. I'm not very familiar with core, so I can't go any further with user,node or any other tokens.
Found useful for easily displaying "create user" links in form field help texts just by using [site:url]admin/user/create, for instance.
I'm not sure if this is the right place to patch, comments are appreciated.
Works for me.
EDIT: If you're interested in token support in default values, see #1070878: Allow tokens to be used in the default value of a field.
Comments
Comment #1
grasmash CreditAttribution: grasmash commentedI'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
Comment #2
Dave ReidThis 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.
Comment #3
Dave ReidWe also need to apply this to D8 first, then consider backporting if possible to D7.
Comment #4
Dave ReidComment #5
grasmash CreditAttribution: grasmash commentedThanks Dave,
I replaced token_scan with is_string. Think that'll do the trick?
Comment #6
Dave ReidThis still needs to be patched for Drupal 8 first, which is where any changes for core have to go first.
Comment #7
grasmash CreditAttribution: grasmash commentedmy 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.
Comment #8
grasmash CreditAttribution: grasmash commentedswitching 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!
Comment #9
grasmash CreditAttribution: grasmash commentedLol, not trying to detag this either.
Comment #11
grasmash CreditAttribution: grasmash commented#7: d8-token-support-field-settings-1308564-1.patch queued for re-testing.
Comment #12
joppert CreditAttribution: joppert commented#7: token-support-field-settings-1308564-1.patch queued for re-testing.
Comment #13
grasmash CreditAttribution: grasmash commented#7: token-support-field-settings-1308564-1.patch queued for re-testing.
Comment #14
amonteroRe-rolling initial patches for just fields' help texts both for D7 & D8.
@madmatter23: Maybe we should split help text, description and default value token support into separate issues for making changes more manageable and easier for core maintainers, so we all can move the issues forward as time permits. I'm sure you are aware of #1070878: Allow tokens to be used in the default value of a field.
I will try to find some time to do a little research for related issues and let's hope all of them get into core soon.
Comment #15
amonteroI thought that naming patch as -d7 would test it against D7 core. I was wrong, it should have been -D7 (uppercase) and with that the patch will be ignored as the docs say.
I did a little research and found the issues:
#1070878: Allow tokens to be used in the default value of a field
#700230: default value with token replacements (Drupal 6)
So I'm splitting them to simplify and hopefully move them forward and making easier to core maintainers.
Re-rolling patches appropiately. D7 patch included ready to backport when issue gets to RTBC.
Comment #15.0
amonteroRelated issue
Comment #17
amonteroResubmitting patches. Testbot is not ignoring -D7 patch (?), renaming.
Comment #18
amonteroComment #19
grasmash CreditAttribution: grasmash commentedAmontero, 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.
Comment #20
amonteroBumping. Anyone else tested this?
Thanks madmatter23, your test would be helpful.
Comment #21
guile2912 CreditAttribution: guile2912 commentedPatch d7 #17 works fine for me on 7.12
Comment #22
amonteroThanks, guile2912.
D7 patch will be backported when D8 one goes RTBC. Do you have a 8.x install to test it? TIA.
Comment #23
amonteroComment #24
clashar CreditAttribution: clashar commentedamontero, thank you for the patch.
it works fine on D8!
Comment #25
BTMash CreditAttribution: BTMash commentedI 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.
Comment #26
guile2912 CreditAttribution: guile2912 commentedTested 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
Comment #27
amonteroRerolling 8.x patch adding image type field as pointed by pooja.sarvaiye in #1695984-5: Basic token support in fields' help texts - D7.
Comment #28
pooja.sarvaiye CreditAttribution: pooja.sarvaiye commentedThe patch works fine for D8. Tokens get replaced in help text of all the field types including image.
Comment #29
xjmThis issue still needs an automated test for the feature's functionality. Thanks!
Comment #30
kbasarab CreditAttribution: kbasarab commentedFirst 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.
Comment #31
kbasarab CreditAttribution: kbasarab commentedAlright. I think I got the image piece figure out. The createImageField() function didn't add it in anywhere so I added it there.
Comment #33
kbasarab CreditAttribution: kbasarab commentedMoving back to needs review as the patch that was meant to fail is the only one that failed.
Comment #34
guile2912 CreditAttribution: guile2912 commentedIf 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
Comment #35
tim.plunkett@guile2912 in this case, the point was to prove that it would fail. It's called Test Driven Development.
Comment #36
amonteroMaybe I'm being picky here, but using time-dependent tokens may cause false assertion failures in some edge cases. In this case, using a short date only would trigger it if testbot run crosses midnight.
I'm not familiar with d.o testbot internals and maybe test and assert happen very quick in succession, don't know. Since testbot runs last a few minutes at least, it seems a reasonable risk to consider. I just changed [date:short] token by [site:name] in kbasarab's tests.
Also, token_replace is always called with the option 'sanitize' set to TRUE by default, so adding check_plain to output test.
Comment #38
kbasarab CreditAttribution: kbasarab commentedGood 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.
Comment #39
amonteroSo, if code is already reviewed & tested can this issue go RTBC or the same reviews apply to tests?
Comment #40
amonteroAssuming tests need not to receive review other than Drupal testbot, changing to RTBC.
Comment #41
catchDon't we need something to indicate that you can use tokens here when entering the help text?
Comment #42
amonteroThat would be certainly desirable.
Before a patch reroll, what would be the best way to be translator friendly/compliant in the backport?
Something like this?
Also, for the help text we could use "This field supports tokens." string as 'token' contrib module currently does.
Comment #43
webchickLooks like this still needs work? It does not seem to still need tests, however. :)
Comment #44
amonteroAdding "This field supports tokens." to 'Description' field help text. Almost there, aren't we?
Comment #45
amonteroComment #47
Deciphered CreditAttribution: Deciphered commentedRe-rolled patch for changed Field module structure.
Comment #49
amonteroPatch applies and works.
Comment #50
webchickThis looks good to me, but we are over thresholds atm. :(
Comment #51
webchickWoohoo! 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.
Comment #52
amonteroBackport to 7.x to allow reviewing until we get David's input.
Comment #54
amonteroOps. One test was missing.
Comment #55
Deciphered CreditAttribution: Deciphered commentedAn Interdiff would be nice (against the D8 patch) if you have time.
Comment #56
EclipseGc CreditAttribution: EclipseGc commented#54: issue-1308564-token-support-in-field-descr-D7-54.patch queued for re-testing.
Comment #57
David_Rothstein CreditAttribution: David_Rothstein commentedI 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):
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?
Comment #58
EclipseGc CreditAttribution: EclipseGc commentedWell, 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...
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
Comment #59
amonteroSince #57 seems applicable to 8.x, raising visibility to maintainers to discuss because of already commited patch.
Comment #60
amonteroUnassigning.
Comment #61
Deciphered CreditAttribution: Deciphered commentedI 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.
Comment #62
amontero#54: issue-1308564-token-support-in-field-descr-D7-54.patch queued for re-testing.
Comment #64
amonteroSince #514990: Add a UI for browsing tokens has ben moved to 9.x and seems to me that the token browser perhaps will not make it in 8.x, let alone 7.x, how about a limited no-token-browser and no-help-text-addition-if-necessary backport feedback? What the gurus say?
Comment #65
amonteroAnd for starters, here's my feedback:
#58: I agree 100% with EclipseGc points. Displaying tokens not meant
to be parsed looks ugly, but worth the hassle IMO.
Possible solutions:
Comment #65.0
amonteroFormatting
Comment #79
apadernoThe 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?
Comment #83
quietone CreditAttribution: quietone at PreviousNext commentedI 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,