Entity Reference works great so far. I replaced my field that had used the References module with an Entity Reference field. I was easily able to replace any contextual filters with the new field. The only problem is that I can't replace my exposed filter that the References module allowed.
I have a client content type and a project content type. Within the project content type is a select list called Client which is now an Entity Reference field instead of a Node Reference field. On the projects view (page view) I need an exposed filter that will be a select list so the user can filter projects by client. The way I had it setup through the References module allowed it so the user could select a client from the select list and then only that client's projects would be displayed on the page.
It seems that under Filter criteria I can only select (target id) or (target type) for my Entity Reference field which are both text fields that take values.
If this functionality is not available yet for the Entity References module that is fine. I just wanted to make sure there isn't something that I'm missing or if there is any other solutions or add-ons to make this happen. I am trying to do away with References module completely but I can't unless I figure something out for this.
Comments
Comment #1
Amir Simantov CreditAttribution: Amir Simantov commentedNeed it too :)
Comment #2
anavarreI'm also stuck with this and think it's not yet been implemented. A confirmation would be good though.
Comment #3
Barry_Fisher CreditAttribution: Barry_Fisher commentedThis looks like a duplicate issue to me: http://drupal.org/node/1253776
Comment #4
webankit CreditAttribution: webankit commentedThese issues are not related
Comment #5
Gerard CreditAttribution: Gerard commentedHaven't found a solution either but I'm very interested too.
Comment #6
haydeniv CreditAttribution: haydeniv commentedThere are a couple things in the current views implementation that are a little strange. I'll take a stab at this as I need this too and see if I can scrape from references what we need.
Comment #7
Amir Simantov CreditAttribution: Amir Simantov commentedI second #4 posted by webankit - this issue does not relate to the linked issue.
A workaround I have though about, is to use taxonomy as the content type. As a fieldable entity, it can have fields. Exposed filter then is supported using all kinds of widgets. Does anyone can see any drawback to this?
Thanks,
Amir
Comment #8
haydeniv CreditAttribution: haydeniv commented@Amir Simantov I see a few drawbacks to this.
1) Taxonomy requires a description field, not all entities are taxonomy.
2) Taxonomy is and entity, an entity is not taxonomy. If we go that route then we are back to everything is a node mentality which didn't work out so well.
3) We don't need the overhead of the taxonomy system when all we needs is entities.
Why should taxonomy get all of the goodness of exposed filters and all other referenced entities not take advantage of it.
When I was thinking about this in the shower it hit me where I saw this behaviour before, it was taxonomy. Why don't we try to port the taxonomy filters to entity reference so we get that goodness here too.
and yes to #4 these issues are completely unrelated. One is a field that gets it's data from views, this is creating filters in views for views. However on my wishlist would be to be able to use a view as a filter so that you could limit the available options for the filter and use different fields for the value of the select list as title tends to not be unique.
Comment #9
Amir Simantov CreditAttribution: Amir Simantov commentedThanks haydeniv, i see your points.
Isn't it better to generelaized the taxonomy filters to entity filters? Is it possible?
Comment #10
haydeniv CreditAttribution: haydeniv commented@Amir I talked to merlinofchaos last night and he did not sound optimistic about what we are trying to accomplish. He said that the taxonomy filter was one of the least favorite experiences he had creating views and taxonomy is more consistently structured than entities. Here are a few things so far that I have found that will need to change to make this happen.
Modules:
entityreference
entity (api)
views
and possible Drupal core
We need to determine a way to generate unique entity titles. What happens if two entities have the same title when you use auto complete. Most likely this will be accomplished by using a second or third field from an entity to create the search list (list of titles to choose from). Some of this may get figured out by Add views support for providing a list of entities or bundles (views filtering, relationships, etc). Still that could get tricky trying to get views to let us filter on a view that may or may not exist yet.
Either way, taxonomy is currently hard coded into the views module and I don't believe the api is very good yet in the views filter world for doing something like this. I could be wrong though I have not dug too far into views yet.
I see entity (api) need to expose a few more things as well to make this happen although I have not figured out just what yet.
At the end of the day I think we are going to need to get this issue some visibility from each of those module maintainers to get this done.
Comment #11
JvE CreditAttribution: JvE commentedA workaround suggestion for the OP:
Adjust to module and scope of field to replace.
Not perfect, but it may hold the tide until we get something solid built-in.
Comment #12
nodecode CreditAttribution: nodecode commentedI'd love to see this.
Could the following module be a source for code ideas? http://drupal.org/project/entityreference_view_widget
To be honest I don't know exactly what that project is trying to accomplish but if it's what is being talked about here, I think they're rather nuts to develop a separate module just for this functionality.
Comment #13
haydeniv CreditAttribution: haydeniv commented@nodecode
entityreference_view_widget is a separate way of choosing entities on the edit form. It is an alternate approach to #1253776: Add views support for providing a list of entities or bundles (views filtering, relationships, etc) which lets you use a view as a select list or autocomplete field data source for the entity reference. This issue is about using an entity reference field as an exposed filter of a view. Views filters allow to you limit the data that is displayed on a view.
Comment #14
Amir Simantov CreditAttribution: Amir Simantov commented@haydeniv
Thanks for investigating it further down; it looks like it will not be implemented before d8. We will have to find other solutions.
@JvE
What should the modulename_get_clients() function return? And can it be with autocomplete, instead?
I do not care for multiple items having the same title.
Thanks.
Comment #15
JvE CreditAttribution: JvE commented@Amir:
For #select #options you need an array with client entity ids as keys and client entity labels as values.
How you get these is not really in the scope of this issue.
I suppose you could get this use-case specific custom workaround to work with autocomplete using a #textfield with #autocomplete_path entityreference/autocomplete/single/client_target_id/node/client
Comment #16
joachim CreditAttribution: joachim commentedThis really shouldn't be rocket science; it's just a question of providing a custom filter handler for the Views filter.
All it has to do is find out which entity type and bundle(s) can be referred to by the field in question, and do a query to get those titles. That's entirely analogous to how the taxonomy filter loads all the terms for the vocabulary the field uses.
(merlinofchaos's horror stories about taxonomy support in Views are probably to do with supporting hierarchies and all that stuff which we don't need to worry about.)
EDIT: in fact might not even need a custom class; views_handler_filter_in_operator lets you define an 'options callback' in its views data definition.
Comment #17
joachim CreditAttribution: joachim commentedTwenty minute patch :D
Turns out we didn't even need a callback, there's one already in the module.
Comment #18
joachim CreditAttribution: joachim commented(Though adding a wrapper around entityreference_options_list() so we store just the field name rather than the whole field array in views data might be a nice touch maybe?)
Comment #19
joachim CreditAttribution: joachim commentedHere's an updated version with that improvement.
Comment #20
Damien Tournoud CreditAttribution: Damien Tournoud commentedI re-implemented the same idea as a behavior. This cannot be the default, because it will not scale as soon as the number of referencable entities is too large.
Comment #22
haydeniv CreditAttribution: haydeniv commented@Damien Tournoud How many referencable entities is too large?
Comment #23
Damien Tournoud CreditAttribution: Damien Tournoud commented@haydeniv: a couple of hundred would already be too much to render as a select field. I would recommend less then 50.
Comment #24
amitaibu@Damz,
EDIT:
I couldn't apply your patch -- is it a full patch or an interdiff?Minor: The plugin definition should be inside a
module_exists('views')
;Comment #25
amitaibuAttached patch just adds module_exists() on plugin definition, and a description, so it would be clear when to enable/ disable behavior.
Comment #26
joachim CreditAttribution: joachim commentedWay too many commas in that ;)
'When enabled, Views filters of this field will have a select list instead of a text field.' is how it should be.
Though I tend to think that phrases like 'when enabled' add no meaning at all and are just noise. So:
'Provides a select list for Views filters on this field.'
Comment #27
bobslee CreditAttribution: bobslee commentedI tried patch #25 and it works. Thanks!
However I had to clear the Views cache, before the selectlist of operands appeared in the View's filter form.
Comment #28
Damien Tournoud CreditAttribution: Damien Tournoud commentedMerged in 7.x-1.x.
Comment #29
nodecode CreditAttribution: nodecode commentedHas this been committed to dev or beta-5?
I've tried both versions, cleared my caches, and I still can't figure out how to make this work. There simply is no option for a select list. Could somebody provide a step-by-step or a screenshot showing how to make this work for an existing view? Thanks.
Comment #30
bmango CreditAttribution: bmango commentedI'm having the same problem as in #29. I'm using a view with an entity reference relationship between two custom content types and can't find any options for using a select list. I only get the option for a blank text field. If I use a relationship to the user then I am getting an autocomplete box.
I'm using 7.x-1.0-beta5. I've checked the files and the files I have seem to be the updated code with the select list function.
Any help would be much appreciated.
Comment #31
gausarts CreditAttribution: gausarts commentedYou may want to revisit the Manage fields page, and tick a new option:
Enable Render Views filters as select list
at the end of the field edit page:
admin/structure/types/manage/TYPE/fields/field_NAME
Comment #32
bmango CreditAttribution: bmango commentedThank you gausarts for your help. Coincidentally, I just stumbled upon it. However, when I enable the render views filter as select list I then get an error when I try and add an exposed filter based on that field to my view, and the view won't save. The error I get is "The operator is invalid on filter: Content: Assignment" (Assignment is my field). I've tried deleting the filter and adding it again but still having the same error. When I disable the render views filter as select list option the filter works fine.
Comment #33
kayelle CreditAttribution: kayelle commentedHere's my work around for this (D7 but I've done something similar in 6 too):
I have a list of users that have an entity reference field. I created a page view using an entity reference as the contextual argument that lists the users.
Then I created a block with the nid and title of the content type that is being referenced. Each title links to the page view of the users with the nid as the argument. The block displays on the page view.
It's not real filtering but it allows for similar functionality.
Comment #34
bmango CreditAttribution: bmango commentedThanks kayelle, that sounds like a good alternative.
Comment #35
rimen CreditAttribution: rimen commented#32
I have the same problem.
Error occurs even if the field is not used in filter.
All that I have found is that validate() function in views_handler_filter_in_operator get defailt operator method "=" instead of "in" ( $this->operator).
Entitity referenced field is used in Field collection.
Comment #36
rimen CreditAttribution: rimen commentedCreating a new views display solved my problem (#35).
Comment #37
RuiMendes CreditAttribution: RuiMendes commentedI think it would be nice to also have an autocomplete widget.
Comment #38
tim.plunkettPlease open a new feature request.
Comment #40
kclarkson CreditAttribution: kclarkson commentedI am not seeing a select list when using it in the Views Filter Criteria section.
Basically the only option I am getting is auto complete.
Comment #41
kclarkson CreditAttribution: kclarkson commentedchanged to Needs Review
Has the patch in #25 been committed yet ?
Comment #42
haydeniv CreditAttribution: haydeniv commented@kclarkson
Have you tried checking the box mentioned in Comment #31
Comment #43
trudog CreditAttribution: trudog commentedgausarts, you're the man!
Comment #44
Dave ReidAlong with the last couple of comments on this issue I'm having trouble getting this actually working. New issue filed at #1778368: Views filter as select list does not work due to "The operator is invalid on filter".
Comment #45
haydeniv CreditAttribution: haydeniv commented@Dave Reid see #1778368: Views filter as select list does not work due to "The operator is invalid on filter" for an answer to the problem even though it probably needs some love to update any views that are using the field before the check box is checked.
Comment #46
Ananya MultiTech CreditAttribution: Ananya MultiTech commentedhii..
i used your idea and it really worked. But it gives 'An illegal choice has been detected. Please contact the site administrator.' error while loading the page for 1st time. But when i select the option and Apply then it doesn't give any error. Can you guide me here please?
Comment #47
Christian DeLoach CreditAttribution: Christian DeLoach commentedAnanya - This may be because you have "Select all" as one of the check options when configuring the field in the views filter criteria.
This enhancement is a little buggy. If you check "Select all", the view results in an error on initial display as you have identified. If you leave all options unchecked, the views administration complains that "No valid values found on filter [...]". We shouldn't have to check records in the options list since the list is almost always going to be dynamically changing.
Comment #48
giorgio79 CreditAttribution: giorgio79 commentedTo make this scalable we could have an autocopmlete widget as well like this one http://drupal.org/project/term_ref_autocomplete
Comment #49
foopang CreditAttribution: foopang commentedDoesn't seem to work with Search API.
Comment #50
miccelito CreditAttribution: miccelito commentedBy enabling 'Render Views filters as select list' at Manage fields >> field (Entity Reference) >> edit, I get
Notice: Undefined index: field_***_target_id in views_handler_filter->accept_exposed_input() (line 1260 of /***/sites/all/modules/views/handlers/views_handler_filter.inc).
And by disabling 'Render Views filters as select list' at Manage fields, I get a text field as exposed filter which can only search by ID as mentioned in the very beginning of this thread.
Edit: Got the exposed filter work now after reading linked thread #44
Comment #51
brockfanning CreditAttribution: brockfanning commentedI also had the problem with Search API. Check out this issue for a patch: #1980450: Entity Property info is missing an 'options list' callback
Comment #52
lunk rat CreditAttribution: lunk rat commented#33 is a good workaround. Here is another recipe that uses a similar technique with the Jump menu display type, which results in a very functional select-list filter:
Now you have a nice filter at the top of your page view that is highly configurable in terms of the labels for each option in the list!
Comment #53
Woodyjon CreditAttribution: Woodyjon commented#52 is genious !!
First time I use jump menus, thank you for that explanation !
Comment #54
lunk rat CreditAttribution: lunk rat commentedSure thing Woodyjon, I came up with it because I needed what this issue was asking for. I find it quite useful
Comment #55
sashkernel CreditAttribution: sashkernel commentedas I filter criteria in view I can see all strings as "Array" instead of the Node Title.
v Select all
v Array
v Array
v Array
v ...and so on
Am I missing something here?
Comment #56
rroose CreditAttribution: rroose commentedThanks gausarts (#31)! Just the answer I was looking for!
Comment #57
mericone CreditAttribution: mericone commentedYou can use Entityreference Views Filter to generate a list of referenced entities that can be exposed to the user. With Better Exposed Filters you can select to display the results as select-lists, links or radio-buttons/check-boxes. This way you can use a block display without any workaround.
Comment #58
Yuri CreditAttribution: Yuri commented"Render Views filters as select list" is not working, using the latest dev. Can someone confirm this is still the case?
Thanks
Comment #59
ranelpadon CreditAttribution: ranelpadon commentedThank you @gausarts (#31), it is the answer to my use case. The exposed filter now works as intended.
Comment #60
kitikonti CreditAttribution: kitikonti commentedThis is not working for me with taxonomy terms. Its only working with node reference. Whats wrong?
Comment #61
haydeniv CreditAttribution: haydeniv commented@kitikonti Please open a new issue using the "Support Request" category for your problem. This issue is already closed and fixed so it won't get very many people looking at it.
Comment #62
kitikonti CreditAttribution: kitikonti commentedThere is already one, with 5 month's of no response.
Comment #63
haydeniv CreditAttribution: haydeniv commented@kitikonti I responded to the issue over there: #2268805: "Render Views filters as select list" not working for taxonomy terms in views exposed filter
Comment #64
alex.skrypnykAfter #31, don't forget to clear cache!
Comment #65
JKingsnorth CreditAttribution: JKingsnorth commented#31 - perfect, thanks.
Comment #66
rcodina CreditAttribution: rcodina commented#31 works for me too, however if I mark an Entity Reference exposed filter as mandatory I can't save the view because view's complains about "No valid values found on filter [...]". It is the same message that was commented on #47. If I uncheck the mandatory checkbox all works like a charm.
I think this issue may have to be reopened to fix this. Another option is to create another issue. What do you think?
I'm using Entity Reference 7.x-1.1
Comment #67
JKingsnorth CreditAttribution: JKingsnorth commentedWould suggest a new issue that references this one, #31 in particular.
Comment #68
rcodina CreditAttribution: rcodina commentedDone. Just created it here.
Comment #69
alysaselby CreditAttribution: alysaselby commented#31 worked for me. Just make sure you have removed the exposed filter in your view before you go to the content type and update the Entity Reference field. Flush caches and then go back to your view and add in the exposed filter.
Thanks #31 I spent hours trying to figure this one out.
Comment #70
el1_1el CreditAttribution: el1_1el commentedI've created a UI configurable d8 module for this based on https://antistatique.net/en/we/blog/2015/10/06/entity-reference-filter-w.... Feel free to test/comment/criticize/fork etc - https://www.drupal.org/sandbox/el/2698765
Comment #71
pheraph CreditAttribution: pheraph commentedel1_1el's module works for my D8 installation - thanks!
Comment #72
Zythyr CreditAttribution: Zythyr commented#31 worked for me also however it only provided a select list display type. There is no ability to change it to Autocomplete, radio, etc...
Comment #73
alemileb CreditAttribution: alemileb commented@Zythyr use better exposed filters module for that