SearchApiViewsQuery->execute() does not return results when using both exposed text filter and facets

Based on the documentation provided for SearchApiQueryInterface->execute(), I expect that $results['results'] should be provided (if even just as an empty array). Specifically, "Additional metadata may be returned in other keys. Only 'result count' and 'result' always have to be set, all other entries are optional."

You're right, that's definitely a bug – see #2632426: Always include a "results" key in search results.

However, this can only occur when there are actually no results, so it doesn't really help with your problem. Could you please provide some details about your setup?

- How are the used Search API fields configured (fields used for the filter(s) and facet)?
- How exactly are the filters on your view set up?
- What search backend are you using, Solr, DB, Elasticsearch, … ?

I have the same problem.

I use:

Search API 7.x-1.16
Search API Database Search 7.x-1.5
Facet API 7.x-1.5
Facet API Pretty Paths 7.x-1.4

I attach these images with the settings:
- Problem_5.jpg
- pretty_path.PNG
- facet.PNG
- views.PNG

You can see this url:
sportnlife.club/buscador/profesional-centro-privado-salud-deporte?nombre=rosal&ubicacion=madrid&especialidad=

Could be the problem because I do not use SOLR and I use Database Search API?

The above patch "search_api_views-exposed-text-and-facet_WORKAROUND.patch" do not work for me. Thanks anyway

I'm sorry, I still cannot reproduce this problem. Even with two "Search: Fulltext search" filters, the search works as expected, with both DB and Solr backend.
However, I'm not using Pretty Paths, so that might be what causes the problem. Could you maybe try disabling that functionality and see if the problem persists?
Do you also get a correct result count, but no actual result objects? Otherwise, this would probably be a different issue.
In any case, if your fulltext searches work on just one field, maybe try adding a filter on that specific field instead of a "Search: Fulltext search" filter. The interaction between several "Search: Fulltext search" filters might also cause issues.

(Also, a tip: by clicking the "Upload" button next to the attachment file selector you can actually upload multiple files in a single post.)

First of all thank you for your answers and apologize for attaching files in more than one message.

- I disabled the module Pretty Paths and still does not work.

- I have added a filter instead Fullttext search and still does not work.

I do not know what it could be. The result URL is correct but no actual result objects. You can try in this URL: sportnlife.club/buscador

- First search: "Profesional o centro privado"= rosal (the result is three users)

sportnlife.club/buscador/profesional-centro-privado-salud-deporte?nombre=rosal&ubicacion=&especialidad=

- If you add a second search: "Ubicación" = madrid (the result is two users)

sportnlife.club/buscador/profesional-centro-privado-salud-deporte?nombre=rosal&ubicacion=madrid&especialidad=

- If you add a third search with facet: "Filtrar por sexo" = Mujer (no result but the url is correct)

sportnlife.club/buscador/profesional-centro-privado-salud-deporte/sexo/Mujer?nombre=rosal&ubicacion=madrid&especialidad=

Thanks for your time!

That's very curious. Could you maybe apply the attached patch to your site? It should, for admin users, print the details of the search query on each search page. Maybe you see something wrong right there, otherwise please just post the output here and I'll take a look.

I'm having the same problem, using an exposed filter (full text search) and facets together

Adding the suggested line to query.inc prints out the folowing:

Index: podcast_index
Keys: NULL
Filters:
    [search_api_viewed = 'Refugees']
  AND
    [field_podcast_type = '40']
Sorting: search_api_relevance DESC, created DESC
Options: array (
    'parse mode' => 'terms',
    'conjunction' => 'AND',
    'filter class' => 'SearchApiQueryFilter',
    'search id' => 'search_api_views:podcast_browse:page_podcast_search',
    'skip result count' => false,
    'offset' => 0,
    'limit' => 10,
    'search_api_facets' => 
    array (
      'field_disciplines' => 
      array (
        'field' => 'field_disciplines',
        'limit' => '-1',
        'operator' => 'and',
        'min_count' => '1',
        'missing' => '0',
      ),
      'field_podcast_type' => 
      array (
        'field' => 'field_podcast_type',
        'limit' => '-1',
        'operator' => 'and',
        'min_count' => '1',
        'missing' => '0',
      ),
    ),
  )

However after enabling the devel module's query log I discovered something:

SELECT COUNT(*) AS expression FROM (SELECT DISTINCT t.item_id AS item_id, '1000' AS score, 1 AS expression FROM search_api_db_podcast_index t LEFT OUTER JOIN search_api_db_podcast_index_field_podcast_type t_2 ON t.item_id = t_2.item_id WHERE (( (t.item_id IN (SELECT t.item_id AS item_id FROM (SELECT t.item_id AS item_id, SUM(score) AS score FROM search_api_db_podcast_index_text t WHERE (word IN ('refugees')) AND (field_name IN ('search_api_viewed')) GROUP BY item_id) t)) )AND( (t_2.value = '40') )))

CREATE TEMPORARY TABLE db_temporary_0 Engine=MEMORY SELECT DISTINCT t.item_id AS item_id FROM search_api_db_podcast_index t LEFT OUTER JOIN search_api_db_podcast_index_field_podcast_type t_2 ON t.item_id = t_2.item_id WHERE (( (t.item_id IN (SELECT t.item_id AS item_id FROM (SELECT t.item_id AS item_id, SUM(score) AS score FROM search_api_db_podcast_index_text t WHERE (word IN ('refugees')) AND (field_name IN ('search_api_viewed')) GROUP BY item_id) t)) )AND( (t_2.value = '40') ))

SELECT t_2.value AS value, COUNT(DISTINCT t.item_id) AS num FROM db_temporary_0 t INNER JOIN search_api_db_podcast_index_field_disciplines t_2 ON t.item_id = t_2.item_id WHERE (t_2.value IS NOT NULL ) GROUP BY value ORDER BY num DESC

SELECT t_2.value AS value, COUNT(DISTINCT t.item_id) AS num FROM db_temporary_0 t INNER JOIN search_api_db_podcast_index_field_podcast_type t_2 ON t.item_id = t_2.item_id WHERE (t_2.value IS NOT NULL ) GROUP BY value ORDER BY num DESC

SELECT DISTINCT t.item_id AS item_id, '1000' AS score FROM search_api_db_podcast_index t LEFT OUTER JOIN search_api_db_podcast_index_field_podcast_type t_2 ON t.item_id = t_2.item_id WHERE (( (t.item_id IN (SELECT t.item_id AS item_id FROM (SELECT t.item_id AS item_id, SUM(score) AS score FROM search_api_db_podcast_index_text t WHERE (word IN ('refugees')) AND (field_name IN ('search_api_viewed')) GROUP BY item_id) t)) )AND( (t_2.value = 'refugees') )) ORDER BY score DESC, t.created DESC LIMIT 10 OFFSET 0

In the final query, t_2.value should be 40 (as it is in the first two), instead it has the exposed filter's text value refugees

Running the query in the database with t_2.value correctly set to 40 yields the correct results.

(Drupal Panopoly distribution 1.20: Core 7.36, Search API 1.14, Facet API 1.5, Views 3.10)

Upon further investigation, dumping the query string and arguments at various points in SearchApiDbService::search() sometimes showed that the last placeholder in the query string is incorrectly named db_placeholder_0 and the last argument is missing from the list of arguments ($db_query->getArguments())

I noticed that running dpq() early fixes the issue and after digging deeper I figured that the last argument gets removed in SearchApiDbService::getFacets() on the line $results['search_api_facets'] = $this->getFacets($query, clone $db_query); unless the query is compiled first.

SelectQuery::compile() is protected so I'm running it indirectly:

if ($query->getOption('search_api_facets')) {
  //Run SelectQuery::compile() indirectly to avoid removal of argument
  $db_query->getArguments();
  $results['search_api_facets'] = $this->getFacets($query, clone $db_query);
}

I imagine there must be a better way, but this is as far as my time and skills allowe me to go.

Ah, yes, the Drupal DB layer has been broken for years (since the beginning, really) regarding more complex queries – see #2142107: Complex cloned query dependent on __toString() call for a patch which should fix this.
As always with Core, no-one seems interested in actually committing this, though.
Please report back whether the patch worked for you, both in that issue and here.
In any case, thanks a lot for you detailed analysis!

(Anyone else having such an issue should of course also try out that patch.)

Thanks @drunken monkey :)
Your patch in https://www.drupal.org/node/2142107#comment-9103911 works for Drupal 7.56

OK, thanks a lot for reporting back!
Then let's just close this issue as a duplicate, since none of the original commenters reported back.

it patches but does not solve the problem of losing results in "Fulltext search exposed view filter"