Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.It would be perfect if the arguments input in the field widget supports tokens.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | viewsreference-argument-tokens.patch | 6.83 KB | amerie |
Comments
Comment #2
NewZeal commentedSomeone else made a similar request: https://www.drupal.org/node/2823653
Given that the viewsreference module is a field applied to a node, I cannot see how tokens would have any benefit. The content of a field is not dynamic. The content of a field is a value that tokens access in order to display elsewhere. Because the field using viewsreference uses the Drupal Field API, then you will be able to use it as a token elsewhere if you so wish.
Please describe the situation in which you see yourself using a token, and let me try and explain why you won't need it :)
Comment #3
dom18fr commentedThank you for your answer.
One simple case in which i think i could need token is :
A node with a entityreference field pointing taxonomy terms.
A viewsreference field in this node pointing a view that lists some other nodes that reference the same terms.
I think it's a better user experience to use a token in argument to pass the relevant tids to the view. However, your right it's possible to do it manually, but it means
There's other more advanced case, where using custom tokens that provide values calculated from node context but not directly accessible in node edit form.
In both case, i would use token as default value.
I used the drupal 7 module https://www.drupal.org/project/viewfield this way, and i thought views reference field may have advantage to cover the same scope of functionality.
Thank you again for your work !
Comment #4
NewZeal commentedOK, I see how you might view tokens being useful with that particular scenario. But why not ditch the referenced terms and just have the referenced View? If you are using the terms for some other purpose on the node, why not incorporate that purpose into the referenced View. For instance you can use the View to display information about those terms. Having said that, at the moment multiple arguments are not enabled on Views Reference field at this stage, pending support for such an addition.
The Views Reference module intends to be a relatively simple implementation of Drupal entity reference. Should your request have merit then it would definitely have to wait for 8.x-2.x and would require a sponsor.
Comment #5
dom18fr commentedActually, referenced terms could be used for different purpose out of the node rendering context, such as a facet in a search engine for example.
Regarding to multiple arguments, i think views can handle multiple arguments separated by a comma in a single string value (i may be wrong, but it works when using contextual filters in the UI).
I totally agree with the approach when you want to keep it simple and as near as possible of an entityreference field.
If you think the token integration has its place in views Reference module, i can work on a patch for 8.x-1.x or a further 8.x-2.x.
Let me know :)
Comment #6
dom18fr commentedAfter having think about it, the token integration could be handled in a separated FiedFormatter.
The field formatter would expose a token aware argument field, and the argument input from the views reference field widget would override it if present.
This approach may be more relevant with the "non dynamic field value" paradigm, and it can live in a separated module.
Comment #7
keithm commentedI'm not sure I understand #3-#5 but regarding #2 I can give a common use case. I would be interested in knowing how it can be done effectively in viewsreference.
In the (real) world, a musician writes songs and produces recordings. Songs and recordings are related by a n-n relationship since each recording contains more than one song, and each song can appear on multiple recordings.
Let's say we model this with two node types: 'song' and 'recording'. We add a many-valued 'songs' entity (node) reference field to the recording type. Next we create a view 'song_recordings' that produces a list of all recordings for a given song. song_recordings takes a single argument, the nid of a song. Finally, in the song content type we create a view reference field 'recordings' containing the song_recordings view. The recordings field will list all the recordings for the song (node) it is embedded in - we just have to supply the nid for each song somehow.
In theory, it would be possible to use the UI to retrieve the nid of each song, and plug that value into the view reference argument field. This could become onerous if there are many songs. An alternative method used in viewfield is to supply [node:nid] as a default view argument, and perform render-time token replacement to make the song nid automatically available to the view.
Comment #8
NewZeal commentedUsing Viewsreference in this instance simply involves referencing a View that has a contextual filter that uses the nid from the url. That can be done with a block View. That would solve your problem. No need for a token.
Comment #9
keithm commentedRight you are. This is the only use case I have personally used in the past. I'll ask around to see if others have any others that cannot be met with default value handling.
Comment #10
NewZeal commentedHaving said that someone is having problems with that very configuration: https://www.drupal.org/node/2847192
Closing this ticket.
Comment #11
amerie commentedIn my case, I had a viewsreference field in a Paragraph, and I needed to pass the paragraph ID to the view. I couldn't figure out how to do that with default values in the view, so I created a patch to allow for the use of tokens in the argument field.
Comment #12
bmunslow commentedHi @Amerie thanks for your patch.
You patch addresses the problem discussed in this issue:
https://www.drupal.org/project/viewsreference/issues/2985364
Could you submit it there?