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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Amir Simantov’s picture

Need it too :)

anavarre’s picture

I'm also stuck with this and think it's not yet been implemented. A confirmation would be good though.

Barry_Fisher’s picture

Status: Active » Closed (duplicate)

This looks like a duplicate issue to me: http://drupal.org/node/1253776

webankit’s picture

Status: Closed (duplicate) » Active

These issues are not related

Gerard’s picture

Haven't found a solution either but I'm very interested too.

haydeniv’s picture

Title: Is there any possible way to use the entity reference field as an exposed filter select list in views? » Entity Reference does not offer select list as a views exposed filter, only text field for id number
Component: Miscellaneous » Code
Category: task » bug

There 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.

Amir Simantov’s picture

I 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

haydeniv’s picture

@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.

Amir Simantov’s picture

Thanks haydeniv, i see your points.

Why don't we try to port the taxonomy filters to entity reference so we get that goodness here too.

Isn't it better to generelaized the taxonomy filters to entity filters? Is it possible?

haydeniv’s picture

@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.

JvE’s picture

A workaround suggestion for the OP:

function modulename_form_views_exposed_form_alter(&$form, &$form_state, $form_id) {
  if (isset($form['field_client_target_id'])) {
    $form['field_client_target_id'] = array(
      '#type' => 'select',
      '#options' => modulename_get_clients(), // get array of 'client id' => 'client label'
      '#default_value' => $form['field_client_target_id']['#default_value'],
    );
  }
}

Adjust to module and scope of field to replace.
Not perfect, but it may hold the tide until we get something solid built-in.

nodecode’s picture

I'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.

haydeniv’s picture

@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.

Amir Simantov’s picture

@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.

JvE’s picture

@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

joachim’s picture

This 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.

joachim’s picture

Version: 7.x-1.0-beta3 » 7.x-1.x-dev
Status: Active » Needs review
FileSize
836 bytes

Twenty minute patch :D

Turns out we didn't even need a callback, there's one already in the module.

joachim’s picture

(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?)

joachim’s picture

Here's an updated version with that improvement.

Damien Tournoud’s picture

I 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.

haydeniv’s picture

@Damien Tournoud How many referencable entities is too large?

Damien Tournoud’s picture

@haydeniv: a couple of hundred would already be too much to render as a select field. I would recommend less then 50.

amitaibu’s picture

Category: bug » feature

@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');

amitaibu’s picture

Attached patch just adds module_exists() on plugin definition, and a description, so it would be clear when to enable/ disable behavior.

joachim’s picture

Status: Needs review » Needs work
+++ b/plugins/behavior/views-select-list.inc
@@ -0,0 +1,10 @@
+    'description' => t('When enabled Views filters of this field, will have a select list, instead of a text field. This should not be used when there are over 100 entities, as it might cause an out of memory error.'),

Way 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.'

bobslee’s picture

I 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.

Damien Tournoud’s picture

Status: Needs work » Fixed

Merged in 7.x-1.x.

nodecode’s picture

Has 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.

bmango’s picture

I'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.

gausarts’s picture

You 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

bmango’s picture

Thank 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.

kayelle’s picture

Here'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.

bmango’s picture

Thanks kayelle, that sounds like a good alternative.

rimen’s picture

#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.

rimen’s picture

Creating a new views display solved my problem (#35).

RuiMendes’s picture

Status: Fixed » Active

I think it would be nice to also have an autocomplete widget.

tim.plunkett’s picture

Status: Active » Fixed

Please open a new feature request.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kclarkson’s picture

I 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.

kclarkson’s picture

Status: Closed (fixed) » Needs review

changed to Needs Review

Has the patch in #25 been committed yet ?

haydeniv’s picture

Status: Needs review » Closed (fixed)

@kclarkson
Have you tried checking the box mentioned in Comment #31

trudog’s picture

gausarts, you're the man!

Dave Reid’s picture

Along 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".

haydeniv’s picture

@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.

Ananya MultiTech’s picture

hii..

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?

Christian DeLoach’s picture

Ananya - 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.

giorgio79’s picture

To make this scalable we could have an autocopmlete widget as well like this one http://drupal.org/project/term_ref_autocomplete

foopang’s picture

Doesn't seem to work with Search API.

miccelito’s picture

By 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

brockfanning’s picture

I also had the problem with Search API. Check out this issue for a patch: #1980450: Entity Property info is missing an 'options list' callback

lunk rat’s picture

#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:

  1. Add a contextual filter to your page view that filters based on entity ID.
  2. Create a separate view with a jump menu display which pulls up the entities that you want to filter on. Use rewrite field results to construct a URL for the jump menu using the URL of your page view + the entity ID of each row. Use other field(s) for the label of each option in the jump menu.
  3. Back on your page view, insert your jump menu view into the header as Global:View area. Tick the box for "inherit contextual filter values" (this will make your jump menu focus on the particular entity that is controlling filtering on the page view).

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!

Woodyjon’s picture

#52 is genious !!
First time I use jump menus, thank you for that explanation !

lunk rat’s picture

Sure thing Woodyjon, I came up with it because I needed what this issue was asking for. I find it quite useful

sashkernel’s picture

as 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?

rroose’s picture

Thanks gausarts (#31)! Just the answer I was looking for!

mericone’s picture

You 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.

Yuri’s picture

"Render Views filters as select list" is not working, using the latest dev. Can someone confirm this is still the case?
Thanks

ranelpadon’s picture

Thank you @gausarts (#31), it is the answer to my use case. The exposed filter now works as intended.

kitikonti’s picture

This is not working for me with taxonomy terms. Its only working with node reference. Whats wrong?

haydeniv’s picture

@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.

kitikonti’s picture

There is already one, with 5 month's of no response.

haydeniv’s picture

alex.skrypnyk’s picture

After #31, don't forget to clear cache!

JKingsnorth’s picture

#31 - perfect, thanks.

rcodina’s picture

#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

JKingsnorth’s picture

Would suggest a new issue that references this one, #31 in particular.

rcodina’s picture

Done. Just created it here.

alysaselby’s picture

#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.

el1_1el’s picture

I'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

pheraph’s picture

el1_1el's module works for my D8 installation - thanks!

Zythyr’s picture

#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...

alemileb’s picture

@Zythyr use better exposed filters module for that