For the Drupal 7 version of this issue, see #2010898: Use tokens for entity selection view arguments.

Entity Reference allows using a View of a specific display type to set the available options. This is good.

It's also possible to set arguments (contextual filters) on that view from the ER field config screen. This is also good.

Those arguments must be completely static. This is not good.

Rather, it should be possible to have dynamic, context-aware arguments. The most obvious is "the node that this is on", allowing the view to filter based on the node itself. Ideally, other "relational" contexts (Panels-style, or maybe just via token if that's easier) should be possible, such as "the author of the node this is on", "the OG of the node this is in" (my actual use case), etc.

That would greatly expand the potential flexibility of that view to do all sorts of context-aware select lists.

Of course, there's the obvious problem of what to do when creating a node (or user, or whatever other entity) the first time, since there is no "this" yet to refer to. I see two possible ways to address that:

1) Allow for a default value, or a different context to pull from if null. Eg, if there's no node owner, default to the current user. This would be configurable.

2) Punt that question to the View, where there is already fairly sane default argument capability. As long as we are able to do relational arguments, so that the contextual filter on the View doesn't have to be the entity type that it is on, that's probably sufficient and easier to implement anyway.

In my specific use case, I want to have an ER from a node to other nodes of type Foo that are in the same OG as the node being edited; if the node is being added, default to the user's OGs. The same concept would apply in many other situations, of course, such as related posts by the same author, etc.

(The current alternative involves writing a completely new custom views default argument plugin for every use case, which is highly sub-optimal.)

Thinking about it, I believe tokens would likely be the most straightforward way to specify such values.

So:
1) Is this feature something that would be accepted?

2) I MAY be able to get some time to work on this for the client project that requires it, if I knew it would be accepted so that we're not working with a project fork. :-) Is this doable? (If not, we'd have to fall back to the one-off above.)

Files: 
CommentFileSizeAuthor
#73 1699378-token-replacements-for-entity-reference-views-selection-arguments-72.patch3.44 KBjpstrikesback
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/views/lib/Drupal/views/Plugin/entity_reference/selection/ViewsSelection.php.
[ View ]
#75 1699378-token-replacements-for-entity-reference-views-selection-arguments-75.patch3.54 KBjpstrikesback
PASSED: [[SimpleTest]]: [MySQL] 54,464 pass(es).
[ View ]
#71 token-replacements-for-entity-reference-views-selection-arguments.patch3.44 KBjpstrikesback
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/views/lib/Drupal/views/Plugin/entity_reference/selection/ViewsSelection.php.
[ View ]
#63 view-argument-as-token-1699378-63.patch5.31 KBdysrama
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es).
[ View ]
#61 Screen Shot 2013-04-10 at 8.50.48 AM.png37.43 KBStriky2
#46 view-argument-as-token-1699378-46.patch5.6 KBjpstrikesback
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es).
[ View ]
#43 view-argument-as-token-1699378-43.patch5.6 KBMegaChriz
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es).
[ View ]
#26 Skærmbillede 2012-10-29 kl. 07.14.28.png156.19 KBlsolesen
#26 Skærmbillede 2012-10-29 kl. 07.14.57.png29.33 KBlsolesen
#26 Skærmbillede 2012-10-29 kl. 07.15.28.png104.37 KBlsolesen
#27 view.txt16.23 KBlsolesen
#41 view-argument-as-token-1699378-41.patch4.6 KBlsolesen
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]
#31 view-argument-as-token-1699378-31.patch4.87 KBlsolesen
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in sites/default/modules/entityreference/plugins/selection/EntityReference_SelectionHandler_Views.class.php.
[ View ]
#33 view-argument-as-token-1699378-32.patch4.88 KBlsolesen
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]
#30 view-argument-as-token-1699378-30.patch4.36 KBlsolesen
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]
#29 view-argument-as-token-1699378-29.patch4.3 KBlsolesen
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]
#28 view-argument-as-token-1699378-28.patch4.31 KBlsolesen
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]
#23 Error.JPG151.78 KBjadsam
#19 view-argument-as-token-1699378-19.patch4.33 KBguile2912
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]
#17 view-arguments-as-token-1699378-17.patch3.86 KBguile2912
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]
#14 view-arguments-as-token-1699378-14.patch3 KBguile2912
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]
#7 1699378-token-arguments.patch3.74 KBCrell
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]
#4 view-arguments-as-token-1699378-4.patch3.12 KBguile2912
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

Comments

I understand your frustration with this and came up with a work around:

I am using OG and needed to make an entity reference field on the Group Node to show all nodes that belong to that group.

There is a view that comes with OG that already does this. The problem is I couldn't pass the group ID (GID) of the current node to the view through the entity reference field.

The default "What to do when Filter NOT found" list wasn't helping at first. Group Context, NID from URL, weren't working.

Basically in the end I inspected the $field_state of the actual edit form itself (Devel or var_dump) and was able to access the auto-complete path inside the fields array:
$field_state->YOURFIELDNAME->...->['settings']['handler_settings']['view']['args'] (Think language ['und'] and [0] are part of the ... part as well).

All that to find that the auto-complete path (which is what the view sees) was:
/entityreference/autocomplete/single/YOURFIELDNAME/node/CONTENT_TYPE_NAME/NID

So, all you have to do to grab the NID (Or any of the other field information you get from that URL) is set your view to use the "Raw value from URL" option if filter is NOT present and set it for the correct offset. In this case NID is 7.

LONG STORY SHORT: (Read the last paragraph).

The ability to use tokens in the entityreference view arguments would be terrific, and I'd certainly use it that it were included in entityreference.

deviantpixel: Thanks, that sounds like a clever workaround. It only works for autocomplete-based widgets, though. If I have a select-based widget, there's no autocomplete to draw from.

Status:Active» Needs review
StatusFileSize
new3.12 KB
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

This module is so great and I needed this , so here you go. Using tokens like [current-page:url:unaliased:args:value:1] makes this sooo powerfull :)
This patch if for the dev version, havent tryed it on rc3 yet . Please test it so we can have this included as soon as possible ! Thank you.

Status:Needs review» Reviewed & tested by the community

The patch in #4 works for me. The token to get a node id feels kind of hackish but I seem to recall that there's not a clean way to get at node tokens on node edit forms.

Status:Reviewed & tested by the community» Needs work

The aptch in #4 is lacking any token help. No one I know can write token strings from memory. :-) It needs the token help information attached. I'll work on that and report back.

StatusFileSize
new3.74 KB
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

OK, my error. It does include the token selector thingie, but only if token module is enabled. :-) We should probably expose the token functionality only if token module is enabled. The attached patch does so.

Also, this only handles global tokens. Tokens based on the entity the form is on would be even better. However, we can probably save that for a follow-up patch.

Status:Needs work» Needs review

Wow! Thanks for working on this. The patch seems to work well, although I'm struggling to work out what the tokens would be for fields on the current form, so can't say how well it works on tokens relating to the current entity being edited. Tested with tokens relating to current user and site - fantastic.

Great feature, so hope it can be committed soon.

arrrgh: What you're talking about are contextual tokens, eg, the $node being edited or the $user being edited. That's what I was referring to in #7. The trick there is that on entity add pages those will always be empty, so you need to have some sort of sane default handling or else build your view to have sane default handling. And even then, it would only apply to the node as it was saved previously; dynamically updating the form client-side is a totally different animal.

Status:Needs review» Needs work

Oooo, nice patch!

<?php
+      if (module_exists('token')) {
+       
$description = t('Provide a comma separated list of arguments to pass to the view. You may also use the tokens provided below.');
+      }
+      else {
+       
$description = t('Provide a comma separated list of arguments to pass to the view. Install the <a href="@url">token module</a> to allow for dynamic values.', array('@url' => 'http://drupal.org/project/token'));
+      }
?>

^ The token module is actually only required to display the list of tokens in the UI, let's rewrite this so that it works.

<?php
  
protected function initializeView($match = NULL, $match_operator = 'CONTAINS', $limit = 0, $ids = NULL) {
    
$view_name = $this->field['settings']['handler_settings']['view']['view_name'];
    
$display_name = $this->field['settings']['handler_settings']['view']['display_name'];
-   
$args = $this->field['settings']['handler_settings']['view']['args'];
+   
$args = array_map( 'token_replace', $this->field['settings']['handler_settings']['view']['args'] );
    
$entity_type = $this->field['settings']['target_type'];
?>

^ This one is not used and should just go away.

<?php
-    $args = $this->field['settings']['handler_settings']['view']['args'];
+   
$args = array_map( 'token_replace', $this->field['settings']['handler_settings']['view']['args'] );
?>

^ We should use the proper context we have instead of a global token replacement. The entity type and entity being edited is passed by entity reference to EntityReferenceHandler::getInstance(). We can leverage it here.

Since the token module provides the UI, and the token system is basically unusable in a GUI without the token UI (really, does anyone remember token strings by heart? I don't), I think only enabling when token module is available is reasonable.

I left out the contextual instance above on simplicity grounds for now (and because my use case found an alternate approach, so I didn't have much further time to spare on this issue :-( ). Do you want that now, or in a follow-up patch?

Well you should be able to disable the Token UI if you want , and still have the system working (otherwise, I would call this a bug).
So I the token module is available, show the help, otherwise, tell that you can have help if you activate it.

StatusFileSize
new3 KB
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

So here is a new patch.
It now manages the fact that the module "token" may not be available as Crell stated, and add a small sentence about it.
I took off what you said what not used.
I also had a deeper look into the context, but I have a bad news about it.

Because the entity reference fields does not know where it is the is nowhere we can get the nodeid being edited for example. So we cannot pass it to the token_replace function to have access to node tokens. I think that we may only be able to access global tokens on this one.

For info, help texts are split on purpose, because those strings may already be translated. If I glue them together, we would have to wait for them to be translated again.

Status:Needs work» Needs review

So I guess it would be nice to have this little working piece of code to start with, and maybe later find a solid way to get the info we miss for now.

Status:Needs review» Needs work

As I mentioned in #11:

The entity type and entity being edited is passed by entityreference to EntityReferenceHandler::getInstance()

Not having a proper entity in the token data makes this patch essentially useless.

Status:Needs work» Needs review
StatusFileSize
new3.86 KB
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

You are really hard in business !!
I was so near of it before (but my test site uses filed collections, so that make things a little more complex) and here it works.
So here is a working patch with the entity in the token.

Status:Needs review» Needs work

That's getting closer. Thanks for the hard work!

<?php
+          '#token_types' => array($instance['entity_type']) , // The token types that have specific context. Can be multiple token types like 'term' and/or 'user'
?>

You are hardcoding the token type as the entity type here, which is a wrong assumption. For example, tokens for the taxonomy_term entity are called term. The Entity API module provides us with a 'token type' key in the entity info. You need something like this:

<?php
$entity_info
= entity_get_info($entity_type);
$token_type = isset($entity_info['token type']) ? $entity_info['token type'] : $entity_type;
?>

Status:Needs work» Needs review
StatusFileSize
new4.33 KB
PASSED: [[SimpleTest]]: [MySQL] 66 pass(es).
[ View ]

That was a good catch. You nearly wrote the whole code ^^
So here it is again, with the use of the entity_get_info everywhere where we need the token type.

Status:Needs review» Needs work

Basic functionality works on node edit pages, however not on node add pages. This is because, in my case, [node:field-testing:nid] is not tokenified. I think instead "When the filter value is NOT available" should be triggered, so I made the following changes:

public function getReferencableEntities($match = NULL, $match_operator = 'CONTAINS', $limit = 0) {
  ...
+  $args = array_map('token_replace', $this->field['settings']['handler_settings']['view']['args'], array(array($this->entity_type_token => $this->entity)), array(array('clear' => TRUE)));
  ...
+  $result = $this->view->execute_display($display_name, (!array_filter($args) ? array() : $args));
  ...
}

Also it isn't able to pick-up field values that have been set with "entityreference_prepopulate".

How can we link this in with views ajax to get the select list autoupdated when, again in my example, the field-testing field is updated. This is an issue on both node add and edit pages.

Comments should probably be cleaned up as well, spaces after //, start with capital letter, finish with full stop, full sentences rather than fragments, no spaces after ( or before ).

Thanks for this great patch! Using Drupal 7 with Postgresql, if the module 'Entity tokens' is installed , the process of triggering the field edition interface will run forever until displaying an error message related to memory allocation (http://drupal.org/node/1215630). after switching off the module 'Entity tokens', I got the patch seems to do his wonderful job: I can select the view argument among the tokens ([node:field_leadingorganization]) that will be passed to my entity reference view. But after that I get swamped in the reference view : how do I set the default value for the contextual filter . Do I use 'Raw value from URL' (how to guess the argument nr?) or PHP code?

So I've been trying to figure out the whole "dynamically updating the form client-side" however upon rebuilding the form the value in $this->entity does not change. Am I right in thinking this is because $this->entity only contains the saved data? If so how can I access the new form data in getReferencableEntities?

StatusFileSize
new151.78 KB

Hi,
Thanks for the post # 20

public function getReferencableEntities($match = NULL, $match_operator = 'CONTAINS', $limit = 0) {
...
+ $args = array_map('token_replace', $this->field['settings']['handler_settings']['view']['args'], array(array($this->entity_type_token => $this->entity)), array(array('clear' => TRUE)));
...
+ $result = $this->view->execute_display($display_name, (!array_filter($args) ? array() : $args));
...
}

I currently need this piece of code to add and/or modify nodes, however after applying the changes following the instruccions a got the error included in the Error.JPG file.

I will really appreciate any comment you can provide about this.

Thanks in advance.

Wow, what a great patch. #19 is working for me.

I have a URL like: /admin/commerce/orders/8888/message/add

Under Field Settings / Entity Selection / View arguments I have: [current-page:url:unaliased:args:value:3]

And it's working great - passing the 8888 into the view as an argument.

This comment has been moved into #1826676: Using the wrong id as key in the returned view when using views selection as it turned out it had nothing to do with this patch.

Status:Needs review» Needs work
StatusFileSize
new16.23 KB

DISREGARD THIS COMMENT.

Status:Needs work» Needs review
StatusFileSize
new4.31 KB
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]

Rerolled. Cleaned up the comments and fixed some whitespace errors.

@akumustang: Could you try to implement your changes proposed in #20 in a changed patch?

StatusFileSize
new4.3 KB
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]

Hm, missed some whitespace.

StatusFileSize
new4.36 KB
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]

Moved comments above lines.

StatusFileSize
new4.87 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in sites/default/modules/entityreference/plugins/selection/EntityReference_SelectionHandler_Views.class.php.
[ View ]

DON'T USE THIS PATCH.

Status:Needs review» Needs work

The last submitted patch, view-argument-as-token-1699378-31.patch, failed testing.

StatusFileSize
new4.88 KB
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]

DON'T USE THIS PATCH.

Status:Needs work» Needs review

@Isolesen #31
There shouldn't be a check for the token module when doing token_replace(), because that function is in Drupal core (since Drupal 7). See also #13 of this thread.

@MegaChriz One learns something everyday. Thanks. Then #30 is the proposed patch. Though I still haven't been able to solve #25 in the patch.

It seems that the patch #30 does not have the changes the #20 to have the functionnality of views "When the filter value is NOT available" working, Why ? Does it needs more testing ? ( I will give it a go soon )

@guile2912 Because I was not sure how that worked and was not sure how to test it.

In think the changes in #20 are left out in #30 because of the problems noted in #23.

@MegaChris Though I could not reproduce what was reported in #23 when trying to include that change in the patch.

I am not sure either the #20 was the cause of the error #23 because #23 occurs because the view had problems beeing initialised ($view object does not exist ) and the #23 patch is just a rewrite of the argument string.

#21 is an error of entity_token, so we are good on our side.

I just tested #20 and it works great, providing the "When the filter value is NOT available" view behavior as expected.

So I guess we can put it in a patch and give it a go :)

StatusFileSize
new4.6 KB
PASSED: [[SimpleTest]]: [MySQL] 114 pass(es).
[ View ]

Now including comments in #23.

Status:Needs work» Needs review

StatusFileSize
new5.6 KB
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es).
[ View ]

I have tested the patch #41. I've found two problems with it:

  1. An error message is displayed when creating a new node when using [node:nid] as the View arguments.
  2. Only the first argument gets replaced with tokens from the entity.

An error message is displayed when creating a new node when using [node:nid] as the View arguments

I added an Entity Reference field to a node type and I had set the View argument to [node:nid]. When editing an existing node, this lead to the desired results: the Node ID was passed to the View. But when adding a new node, that node doesn't have an ID yet and this resulted into the following error message:

Notice: Undefined property: stdClass::$nid in node_tokens() (regel 112 van /Websites/drupal/drupalsites/drupal7/modules/node/node.tokens.inc).

That leads me to think the following: maybe we should only pass the entity to token_replace() when the entity has an ID?

Only the first argument gets replaced with tokens from the entity

Look at the following piece of code (part of patch in #41):

<?php
$args
= array_map('token_replace', $this->field['settings']['handler_settings']['view']['args'], array(array($this->entity_type_token => $this->entity)), array(array('clear' => TRUE)));
?>

This will result into that only for the first Views argument the entity will be passed to token_replace(). I have tested to pass two node tokens to Views and this resulted in the following error message:

Recoverable fatal error: Argument 2 passed to token_replace() must be an array, null given in token_replace() (regel 79 van /Websites/drupal/drupalsites/drupal7/includes/token.inc).

So my suggestion is to just use a foreach instead of array_map().

Patch

The attached patch addresses problem 1 and 2 (in addition of the patch in #41). Since token replacement happens in two places, I re-introduced the method handleArgs() (it was previously introduced by lsolesen in #31) where the token replacement takes place.
The entity will only be passed to token_replace() when the entity has an ID. This is checked by calling entity_extract_ids().

Disregard

Great! #43 Working like a charm! Thank you!

StatusFileSize
new5.6 KB
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es).
[ View ]

Quick change to fix a whitespace error, otherwise works.

Status:Needs review» Reviewed & tested by the community

This works wonderfully...I'm going to RTBC this myself as all I changed was whitespace.

Hi guys
I used the patch and it works fine for me.
The problem I am having now is that the field I am using for the token is another entity selection.
But when I change the selection of the field, the dynamic field does not change.
That is, I have a "location" field and a "Hotel" field.
I want the "hotel" field to populate according to the selection in the "location" field.
The "hotel" field draws its content from Entity selection view with a token argument (The token is the "location" field).
What I am looking for is to achieve an outcome in which the hotel field will change according to the selection in the location field.
Any help will be appreciated
Thanks,
sweethilit

Patch works like a charm. #48 looks like it should be in a separate feature/support request. It's out of scope for this patch.

RTBC++

Wow great, works for me, thanks!

Hi all,
I am a little bit confuse about how to implement this.
The user Crell at the begining of this threat said "The most obvious is "the node that this is on", allowing the view to filter based on the node itself".

If I try to update a content already created the view works fine because receives the contextual parameter (already saved in the database) before showing the content. As a result, the second control loads its content based on the saved value in the first control.

So, what I do not understand is the following, during the content creation, If I have two Entity Reference controls and the second is based on a view that receives a contextual parameter from the first Entity Reference, what would be the trigger for updating the view that loads the control. Currently, I assume that the second control waits for the parameter before showing the content, but it does not receive any value and if I change the value in first Entity Reference control does not make any change because the view is not updated.

I can understand how to make it work.

I would really appreciate any comment on this regard

#46 works as advertised RTBC

Status:Reviewed & tested by the community» Patch (to be ported)

#46 works wonderfully for me, too. Thanks!

Status:Patch (to be ported)» Reviewed & tested by the community

Will these patches be implemented into the next official release? I'm not big on patches in general as I don't want to worry about overwriting them on the next update.

Would it be possible to have in the Entity Reference view type an option "Argument Input" like the one for Panel Panes?

In this way Arguments would be fed by the context in a very cool way.

Thanks a lot for sharing,
I wonder if there is a way to "fill" the entityreference field with the corresponding view result during "create/edit" mode ?!

StatusFileSize
new37.43 KB

Great topic. This is a long-time wished feature improvement. Will try the patch because it would certainly help to solve some of the limitations.
Just one question, why not even trying to jump directly in the full dynamic arguments model, passed in PHP.
Attached a screenshot of what would be the ideal... I tried to realize it but I'm stuck with how this is handled afterwards...

Hello I was able to test patch #46 successfully (using the following Views arguments token expression "[node:nid],[node:content-type]") !

Thank you very much for this great new feature !

StatusFileSize
new5.31 KB
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es).
[ View ]

I was very happy to find this patch, but I don't understand why it's set up only to work for already existing entities?
// Check if the entity has an ID. If not, don't pass the entity to token_replace().

I made a new patch, and it works fine without this condition, and now it also works for adding new entities.
I've attached the slightly modified patch

@dysrama
Have you tested to use [node:nid] as a token argument? See also #43.

@MegaChriz
Thanks for your reply, I hadn't seen the comment in #43 and no, I haven't tested with node:nid.
The reasoning behind not replacing tokens at all when the entity is new because of 1 token not working seems flawed to me though? In my usecase for example, it makes the patch useless.

Project:Entity reference» Drupal core
Version:7.x-1.x-dev» 8.x-dev
Component:Code» entity_reference.module
Status:Reviewed & tested by the community» Patch (to be ported)

Sorry guys, but at this point we are going to need this to go into core first.

I agree with #65 as the notice seems to me a bug in core's token handling (if it is still an issue). Re: #66, I'll take a stab at 8.x shortly, should the component be views.module as selection plugins now live in their respective modules?

I think it's fine to keep it in the ER component. The problem with a 8.x patch is that it cannot include any of the module_exists('token') parts, which will make it a lot less useful :(

Indeed but right now doesn't the token module handle form alters for adding the token popup/help for core text areas that support replacement? It handles the field description form alter I believe. In that case I think it's fine to (at least attempt to) go in without those items unless I'm missing something (likely)...

It's definitely ok to go with what we can in core and leave Token to do its job, I was just saying that it's unfortunate that core won't/can't provide an experience as nice as D7 contrib.

Status:Patch (to be ported)» Needs review
StatusFileSize
new3.44 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/views/lib/Drupal/views/Plugin/entity_reference/selection/ViewsSelection.php.
[ View ]

^^ Indeed...

First pass to see what breaks.

Status:Needs review» Needs work

StatusFileSize
new3.44 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/views/lib/Drupal/views/Plugin/entity_reference/selection/ViewsSelection.php.
[ View ]

:) oops guess handleArgs() should be public

StatusFileSize
new3.54 KB
PASSED: [[SimpleTest]]: [MySQL] 54,464 pass(es).
[ View ]

How to waste the testbot 101... I need coffee...

Status:Needs work» Needs review

Any updates on this?

I don't currently have the time to test the 8.x version, so I am in no position to hurry anyone along. But I would like to know the roadmap/timeline for getting this back to 7.x.

Is this a small(ish), less important issue that needs more eyes? Or is it more complicated on the 8.x side? Does #67 - #70 mean that the backported patch will need to be redone to more closely follow the 8.x patch? Or will it be safe to use the 7.x patch (#46) in the meantime? I realise there's no "upgrade path" between that and the eventual patch, but I assume it should not affect the data that has been entered already?

Did anyone manage to figure out how to use the value of a previous form element to ajaxly update a views enabled entity reference list yet?

akamustang: I was just coming here to post about that. The patch in #63 seems to otherwise work fine. I am not really sure where to start to figure this problem out though.

Thanks for the patch works like a charm !

Okay, I implemented the AJAX discussion on a personal level using a combination of extending the EntityReference_SelectionHandler_Views class to have a setAjaxArgs method and telling its getReferenceableEntities method to prioritize that argument. I put the necessary AJAX code into a form alter and used the appropriate part of the $form_state['values'] to feed the selection handler class and regenerate the options list on every form call. It is clunky but functional.

I'm not sure if something like this is possible at the general level without a LOT of wizardry -- it would involve extending the selection handler class to accept a form_state variable and then doing logic on the fields present in the form_state to see if they somehow "match" the token that is set in the settings form -- it seems quite complex but I'm also not a mad wizard or anything so maybe someone has other (better) ideas.

@Kazanir .. any way you could share what you did - maybe someone can come up with a better way -- but I would love to just adapt to my needs.

I have two fields on a node add form. I want the second fields view argument to be updated when the user picks a value in the dropdown / checkbox of the first value

Thanks

Hi,

I have a group MY_GROUP and a content type TASK. TASK has a user-reference field: RESPONSIBLE.
When i make a new TASK i use an autocomplete field to chose the RESPONSIBLE user.

I dont want to assign TASK to anybody outside of MY_GROUP, so i just want to search for RESPONSIBE in user in MY_GROUP.

I set in TASK the field RESPONSIBLE: Entity selection on "Views: Filter by an entity reference view" and i chose the view GroupContributors (where i already defined a display type "Entity Reference".
But the view: GroupContributors needs a contexual filter, so i should give the ID of MY_GROUP from the URL to the field.) and type %1 for field:"arguments". But it does not work.

Have anybody some idea?
Thanx

For D7, #46 still works fine and apply cleanly

#46 works pretty good. Thanks.
Can I suggest to add an array_filter() before returning the $args.
This will support the 'Display all results for the specified field' option in Views core when the filter value is NOT available. An empty string I also consider as NOT available, but others may disagree.

Here my suggestion on top of D7 patch from #46:

+  protected function handleArgs($args) {
+    // Parameters for token_replace().
+    $data = array();
+    $options = array('clear' => TRUE);
+
+    // Check if the entity has an ID. If not, don't pass the entity to token_replace().
+    if ($this->entity) {
+      list($id, $vid, $bundle) = entity_extract_ids($this->instance['entity_type'], $this->entity);
+      if (!empty($id)) {
+        // Only pass the entity to token_replace() if it has a valid ID.
+        $data = array($this->entity_type_token => $this->entity);
+      }
+    }
+    // Replace tokens for each argument.
+    foreach ($args as $key => $arg) {
+      $args[$key] = token_replace($arg, $data, $options);
+    }
+    return array_filter($args);
+  }

Added reference to the same issue for the Drupal 7 version of Entity reference module.

It seems the patch #75 does not work on with the last version of entity reference 7.x-1.1 (2013-Nov-20).
Please could you confirm if there was an update.

Thanks in advance

#75 is for D8, the last D7 patch in this thread is #46

Issue summary:View changes

No, see #2010898: Use tokens for entity selection view arguments for the Drupal 7 version of the patch. I've updated the issue summary to clarify this.

#46 is ok for D7 but for my case I must to comment this line (216):

<?php
if (!empty($id)) {
?>

in
<?php
handleArgs
?>
method.
For my case Ive got line item with reference and I want to send product_id before line_item is create (in add to cart commerce process)