Hi,
Entity Reference is great and it even became greater now it is possible to dynamic generate select lists with a view.
A while ago it was only possible with the old References module and only for user or node references.
My problem now is very strange. I create a view that gives perfect results (an array of several items). When I select this view as list for my entity reference field I always only get to see the last item of the view result.
This strange behaviour only appears when I use a contextual filter in my view AND when I create a view to select users.
So when I do the same to select nodes, it works perfect!
Does anybody know why it is not possible to use a view to populate a select list for an entity reference field to a user in combination with a contextual filter?
(I'm using Drupal 7.14, views 7-3.3 and Entity Reference 7-1.x-dev from June 18th 2012)
Comments
Comment #1
maxplus commentedHi,
I'm starting to think that the problem is not related to the entity reference module but rather to the Field Collection module.
I did all kinds of tests:
- using contextual filters and not using contextual filters
- using relations and not using relations
- using target entity's; users, field collections, nodes
=> when I still keep using contextual filters and relations in views but my target entity is a Node: it works.
=> even when my source is a entity reference field inside a field collection
Comment #2
maxplus commentedHi,
my solution was finally very simple: just use the contextual filter right away to filter on the reference field instead of first using a relation in the view and then use a contextual filter to enter the user.
Comment #3
that0n3guy commentedI can verify this bug.
To reproduce:
The entity add form will only show the last term in the list...
Comment #4
dysrama commentedI had this problem as well and figured out what caused it, at least in my case. The entity_reference plugin display assumes the base_table and base_field used as unique key to always be node.nid. When you use relationships in your view, this is not true anymore.
I've attached a patch that makes it possible to define what base_table and what base_id to use when pointing to the view. If you're in doubt what this is in your case, turn on the "view sql" in views settings and check your query.
Hopefully this patch works in other cases than my own.
Comment #5
dysrama commentedJust found a minor error in above patch, new one attached
Comment #6
Zorath commentedHad the same issue, tried out the patch and it works like a charm.
Thanks a million
Comment #7
noopal commentedcan somebody upload the patched files, I tried but m not seeing anything different.
Where do I set the base table?
Comment #8
ivfc commentedHello,
Can I kindly request some help with this as well? I applied the above patch and have the same problem as #7, I do not see anything different and am not sure where to define the base table and base id. Could you please clarify how to get this working?
Thank you so much for your help in advance!
Comment #9
JvE commentedComment #10
drone.ah commentedThe base table and fields are on the "edit field" page. However, this does not solve the problem completely.
I have a case where I join a field_collection_item table -> node to another -> field_collection_item table. In this context, this patch cannot help.
In any case, I believe there to be a simpler way of solving the problem. I've run out of time, so will just provide my findings in case it helps someone else.
in entityreference_plugin_style::render(), within the nested for loop, there is a line (:60),
$results[$values->{$id_field_alias}] = filter_xss_admin(preg_replace('/\s\s+/', ' ', str_replace("\n", '', $this->row_plugin->render($values))));
The use of the id_field_alias to build an associative array means that you will get only one result per unique row of the content type of the view is built upon.
In other words,
If you create a view of nodes and there is a filter to limit to to a nid (say 5 for arguments sake), each entry in the view would have the id_field_alias of 5. Each entry would then be put into the same key within the result array and returned.
One way of solving this would be ensure that the relevant id field is output as part of the fields and then reference that in the code. It could perhaps be another field to select within the settings of the display.
Alternatively, restructure the view so that the entity on which the view is built is the one that is output, and not one based on relationships.
I hope this makes sense...
Comment #11
Goofy2k2 commentedsubscribe
Comment #12
drupup commentedOkay, let's say this is my query:
SELECT node_field_data_field_languages.title AS node_field_data_field_languages_title, node.title AS node_title
FROM
{node} node
LEFT JOIN {field_data_field_client} field_data_field_client ON node.nid = field_data_field_client.field_client_target_id AND (field_data_field_client.entity_type = 'node' AND field_data_field_client.deleted = '0')
LEFT JOIN {node} field_client_node ON field_data_field_client.entity_id = field_client_node.nid
LEFT JOIN {field_data_field_client} field_client_node__field_data_field_client ON field_client_node.nid = field_client_node__field_data_field_client.entity_id AND (field_client_node__field_data_field_client.entity_type = 'node' AND field_client_node__field_data_field_client.deleted = '0')
LEFT JOIN {node} node_field_data_field_client ON field_client_node__field_data_field_client.field_client_target_id = node_field_data_field_client.nid
LEFT JOIN {field_data_field_languages} node_field_data_field_client__field_data_field_languages ON node_field_data_field_client.nid = node_field_data_field_client__field_data_field_languages.entity_id AND (node_field_data_field_client__field_data_field_languages.entity_type = 'node' AND node_field_data_field_client__field_data_field_languages.deleted = '0')
LEFT JOIN {node} node_field_data_field_languages ON node_field_data_field_client__field_data_field_languages.field_languages_target_id = node_field_data_field_languages.nid
WHERE (( (field_client_node.nid = '3101' ) )AND(( (node.status = '1') AND (node_field_data_field_languages.type IN ('language')) )))
ORDER BY node_title DESC
In this case, I've got a nested relationship: first to client, then to language, so I can access only the languages that have been selected for that client. Based on this table, what, specifically, would I enter into the "ID field if not nid" and "the base table" fields? I've tried a couple of things, but I'm still getting errors in the edit screen where the view is being rendered, so I'm obviously not using correct syntax.
Comment #13
leeresglas commentedThanks a lot for the patch, but it did only provide a partial solution to my problem which is the one of #10, namely that the wrong field_alias_id is used in a specific context (a view with relationships and contextual filtering). I implemented what drone.ah supposed to do and which works in my actual setting. Besides the fact that all of this is really a hack (one should not expect end-users to enter some database-related stuff anywhere), there is a big problem: it does not work with autocomplete! Since until now a select-list does the job for me, I have not looked further into the query-function which should handle this stuff, but maybe I will in the future.
In my actual setting, I added the content nid to my view (and excluded it from display) and used the field identifier as field_alias_key (or id_field_alias to use the syntax of entity_reference). Adding the base_table and base_field stays necessary, as the reference field would not accept the entries otherwise.
In my impression, the bug which relates to this behavior might be outside of entity reference (but then again, why should the results show up correctly in Views UI, which they do in my case?), however I'm not that familiar with how exactly Views works so I didn't dig that deep into the problem.
Comment #14
leeresglas commentedOkay, new stuff: As I had the additional problem, that adding items in a field collection multiple view (see https://drupal.org/node/2198831#comment-8785703) rendered the view items invalid, I had another look into the problem.
It turned out, that the functions getReferencableEntites and validateReferencableEntities don't have access on any arguments which renders results from a view that uses a flexible contextual filter (like node ID from URL) invalid. I therefore wrote a new patch, that references the FieldCollectionEntity in the EntityReference_SelectionHandler_Views and provides the HostEntityID as argument to Views. In my case, this solved the problem that wrong or no results were shown (which renders the patch #13 obsolete, at least in my case) . It also resolved the add another issue (mostly).
Comment #15
robcarrThanks @leeresglas - I'd encountered an issue that I thought was related to Field Collection #2198831: Add another button breaks Entity Reference values. Your patch #14 worked perfectly fine for me - and thanks for flagging up this issue queue. I've not found any other issues with the patch.
The patch gets my vote. More reviews for RTBC please!
Comment #16
inno81 commentedThis patch does not work for me: i have a node with 1 field collection, and 1 field collection nested inside another field collection, both with an entity reference field populated by an entityreference view display (the same for all the ER fields). In particular:
- The non-nested field collection initially shows the options fine. When "add another", the first entry is preserved (doesn't disappear anymore), but the new one is empty.
- The field collection nested in the other field collection is now empty since the beginning (it was initially populated fine without patch).
- The reference field setting page gives this error:
I applied the patch to latest dev.
Comment #17
biarr commentedThe patch in 14 does not work for me either. I'm getting the same error
Comment #18
inno81 commentedComment #19
robcarrI'm seeing WSOD for an entity reference field with same fatal error as reported at #16 and #17. However, the [non-node] entity being referenced does not contain any field collections.
This is the problem code (which is added by the patch at #14):
And it's the call to
$this->entity->hostEntityId()that's the line 109 flagged up. Which suggests that the patch at #14 has unintended consequences with the Entity Reference module.hostEntityId()is a function in the Field Collection module to identify the entity hosting the field collection... and this is causing the issue with an entity (object) that is not a field collection.Comment #20
inno81 commented@arrrgh or anyone else: did you manage to fix the issue somehow? Is there any update?
Comment #21
digitgopher commentedI found this thread because my view is correct when I preview it, but only shows one result on the node edit page.
I have a content type with 2 entityreference fields. On the second entityreference field I use 'Views: Filter by an entity reference view'. Then in the view I'm reading field_parent (the first entityreference field) in a contextual filter, and then have an 'Entity Reference: Referencing entity' relationship on field_parent. This gives me the results I want when I preview. But then only the last result shows up on the node edit page.
Here is the sql:
I've tried all the patches here, none of them work. The base table issue in #5 doesn't help as my view's base table is node. Field collection issue in #14 only breaks with no field collection here. There has to be a deeper issue here, but I don't know views (or entityreference) well enough to track it down.
Hoping someone can help resolve this!
Comment #22
digitgopher commentedHere is what I found after digging into this.
The issue is in entityreference_plugin_style, render function. The key snippet is
$results[$values->{$id_field_alias}] = .......
$results needs to be keyed with the actual node ids. So change $id_field_alias to the nid field *based on the relationship*, and now they have their correct nids rather than all the same.
So this is similar to the base_table issue expressed in #4, except the view output works fine - no need to pass a base table to the view. It's passing the correct table/field info to the style plugin and validation that doesn't work.
1) How to have a generic solution?
2) Validation breaks, how to fix it? Doesn't look like it handles relationships?
Comment #23
dca123 commentedSubscribe
Comment #24
caldenjacobs commentedLike others, my Views Entityreference filter display queries the proper result list, but will only pass one result to the actual EntityReference field calling it. I'm stumped. Anyone have any ideas about how to solve along the lines of #22?
Comment #25
caldenjacobs commentedComment #26
caldenjacobs commentedUh oh. This *may* actually work as designed.I was able to get everything working by reversing the way I did things.
I.e.
1. Utilizing a reverse relationship
2. Adding a contextual filter using the reverse relationship
Anyone else have any luck with this approach?
Comment #27
duckydan commented@caldenjacombs That worked for me. Even though I was using a Taxonomy term VBO selector, I had a content view providing the possible results. By reversing it and using a term view that related to the content (instead of a content view relating to terms), it works perfectly now.
It seems odd that doing it the "wrong" way even returned a single result.
Thanks for the tip!
Comment #28
adrianavaz commentedhi @maxplus
I know this was 4 years ago but I am having the exact same problem and I can't figure it out...
What do you mean by this:
"my solution was finally very simple: just use the contextual filter right away to filter on the reference field instead of first using a relation in the view and then use a contextual filter to enter the user." ?
I am also trying to display a list of users with a contextual filter. Users that belong to the group (Group Module) of the logged in user.
Thanks!!
Comment #29
caldenjacobs commentedHi @adrianavaz — Could you post an export of your View here?
Comment #30
adrianavaz commentedHi, yes here:
In the view is working just great, all users appear. But when I add the view to the entity reference field, it displays only on value - the last added user.
Thanks!
Comment #31
caldenjacobs commentedThanks @adrianavaz!
As discussed, it seems that because of the nature of how Entityreference interprets Views results, we must Contextually filter using Relationships instead of using Fields dependent directly on Relationships in our Entityreference Views displays.
See the following example, which with some modification might work for your use case:
Comment #32
adrianavaz commentedHi, thank you for this.
It appears like this:
But it doesn't do what the other view was doing:
1. I just want "Empresa A1" to appear not all of the "Member Empresa A1 in Empresas grupo 1"
If I add Name in the fields only the logged in user name appears.
2. I need the filter "Only has the member role" to be active but when I do that the results disappear.
Do you know how to work around this?
Thanks!
Comment #33
adrianavaz commentedOk I managed to get the 2. to work.
But I still need this:
"1. I just want "Empresa A1" to appear not all of the "Member Empresa A1 in Empresas grupo 1"
In the display these are the options:
http://imgur.com/a/zF4N4
Comment #34
caldenjacobs commentedAh, apologies to all for (sort of) hijacking the thread — perhaps at this point it might be best to move this discussion to the Group module's queue. At the same time, hopefully documenting how to alternatively query Views using Contextual filters on top of Relationships will be helpful to other folks researching this rendering issue.
@adrianavaz — it looks as if you'd like to reference Users directly, instead of Group Memberships. This being the case, you'll want to create a new View, and set it to query the User table instead of Group Memberships. I'll provide an export below as an example, but you'll have to reapply your role filters and other custom settings as I created this from scratch.
You'll also likely need to create a new entityreference field, and be sure Users are selected as the Target Type, and then you'll be able to filter through this new View:
Cheers!
Comment #35
Ramirez commentedThis is just a workaround.
Using https://www.drupal.org/project/entityreference_view_widget as a widget, the problem does not occur.
Obviously, it does not solve the original long pending issue. However, you may give it a try as a last resort.
Comment #36
adrianavaz commentedThank you all.
@caldenjacobs it worked! thanks
Comment #37
Ramirez commentedAfter a long and demanding search, I resolved the issue for my project regarding OG group and members.
To summarize it up: in views you should not use the relationships directly in the fields. Instead, you should use contextual filters to narrow the list according to the needed result.
So you should use relationship + contextual filters (and NOT relationship directly in fields).
Comment #38
rakesh.nimje84@gmail.com commentedI was facing the same issue.
After trying the tweak proposed in #37, it started working.
Comment #39
electrokate commentedFor Drupal 8, following the guide for Business Rules here, using entities instead of taxonomy, this issue is still happening. I tried using the entity reference views select module with the patch that is applied specifically for this issue and the problem remains. Does anyone have any insight?
edited:
@caldenjacobs I have tried add a relationship and contextual filter as you described above but it does not work, it stops pulling any values rather than just 1.
-my view with just a contextual filter of "Content: Title" works but the select list is populated only with one of the multiple values displayed in the view preview
-adding a relationship of "Content referenced by the parent field" and then adding the contextual filter of Title based on that relationship then pulls in no values.
-tried ENTITY REFERENCE VIEWS SELECT module for Drupal 8, but get the same results. There is a patch in that module for this issue but it doesn't appear to work.
-the multiple fields that are not all showing up are Paragraphs fields
Comment #40
electrokate commented@drone.ah
The Drupal 8 render function in Views (EntityReference.php) is this:
It is still referencing the $id_field_alias like you mentioned above (#10) for Drupal 7:.
Perhaps a patch for this would fix this issue in Drupal 8? Is their comment about not displaying grouping info relevant to this issue?
Comment #41
felubraI was able to make it work using the approach of #26 , thanks @caldenjacobs!