Problem/Motivation

It is currently only possible to create views based on the base table of the entity. It would be great to allow any views table for a particular entity type to provide selection views, such as Search API which can allow you to do a lot more advanced searching.

The piece of code that currently stops it is:
plugins/selection/EntityReference_SelectionHandler_Views.class.php::28

    $entity_info = entity_get_info($field['settings']['target_type']);
    $options = array();
    foreach ($displays as $data) {
      list($view, $display_id) = $data;
      if ($view->base_table == $entity_info['base table']) {
        $options[$view->name . ':' . $display_id] = $view->name . ' - ' . $view->display[$display_id]->display_title;
      }

This explicitly enforces only the base table, excluding all other possibilities.

Proposed resolution

Check the table's definition to see if it is has an entity type. This would allow other modules to provide tables that are compatible.

CommentFileSizeAuthor
#2 d7_entityreference_searchapi_selection.patch5.62 KBfago
#1 2098093-1-allow_non_base_table_views_tables.patch1.12 KBandrewbelcher
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

andrewbelcher’s picture

andrewbelcher CreditAttribution: andrewbelcher commented
Status: Active » Needs review
FileSize
2098093-1-allow_non_base_table_views_tables.patch1.12 KB

Here is a patch that implements the proposed resolution by checking whether the table is of the particular entity type:

      $table = views_fetch_data($view->base_table);
      if (isset($table['table']['entity type']) && $table['table']['entity type'] == $field['settings']['target_type']) {
andrewbelcher’s picture

andrewbelcher CreditAttribution: andrewbelcher commented
Issue summary: View changes

Add a file/line reference for the code quote

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Issue summary: View changes
FileSize
d7_entityreference_searchapi_selection.patch5.62 KB

Unfortunately the patch is not everything that's required to support search api based views.

Howsoever, attached is a patch which adds search api support, i.e. talks the search api query plugin. I've tested it with solr only, for search-api db backend support (or others) the wildcard character would have to be replaced accordingly (see @todo). (It's a pity search api has no support for handling wildcard queries itself)

The code would probably better live in a separate search-api specific sub-class, but it doesn't look like there is a simple way to switch display handler classes per query backend.

andrewbelcher’s picture

andrewbelcher CreditAttribution: andrewbelcher commented

I've a feeling this isn't necessary, but it's been a while since I looked at it.

Either way, I think any Search API specific code should probably go in Search API? The patch I posted allows other modules to implement what they need. For example, if more is necessary for Search API integration, it could extend the views class to do the additional work.

The better option would be to make sure that the use of views us back-end agnostic. #1989952: Allow match to be passed to exposed filters is a start on that by using exposed filters rather than the somewhat hacky way it currently works.

I'll try an take a look and see where I got up to, but I think the patch from #1 is the answer to this issue...

jason.fisher’s picture

jason.fisher CreditAttribution: jason.fisher commented

I am currently struggling with the same issue. I have "Indexed Node: Related (exposed)" for my field_related_ref entity reference field with Search API Solr and Views and cannot get it to appear as anything other than a text input.