I'm using search_api 1.23 + search_api_solr 1.12 and search_api_page 1.4, connecting to a Solr 7.2.1 server.

Everything works fine with search_api 1.22, but after the upgrade to the recent 1.23 I get the following error:
SearchApiException while executing a search: Filter term on unknown or unindexed field node:status. in SearchApiSolrService->createFilterQueries() (line 1641 of sites/all/modules/contrib/search_api_solr/includes/service.inc).

This problem was introduced by #2566529: Add a "Content access" processor for "Multiple types" indexes.

Comments

jcnventura created an issue. See original summary.

jcnventura’s picture

jcnventura
Primary language English
commented
Component: Code » General code
Issue tags: +2902963

Not fixed by #2902963: "Bad request" error with nested queries containing tags.

jcnventura’s picture

jcnventura
Primary language English
commented
Issue tags: -2902963
Related issues: +#2902963: "Bad request" error with nested queries containing tags
jcnventura’s picture

jcnventura
Primary language English
commented
Issue summary: View changes
Related issues: +#2566529: Add a "Content access" processor for "Multiple types" indexes

Reverting #2566529: Add a "Content access" processor for "Multiple types" indexes fixed the issue.

jcnventura’s picture

jcnventura
Primary language English
commented

Just FYI, my index is not multi-entity. It's multi-bundle on 4 different content types of the 'node' type.

This makes it a "SearchApiEntityDataSourceController", and not the "SearchApiCombinedEntityDataSourceController", which the patch #2566529 was intended to address.

Furthermore, the condition will attempt to see if 'node:status' is 1, but no field is ever inserted with this name. If I add status as a fulltext field, it will get added as 'status', and that does prevent the exception during the filter creation, but it still doesn't return any results.

jcnventura’s picture

jcnventura
Primary language English
commented
Title: Anonymous can't access search page after search_api upgrade to 1.23 » Only admin can access search page after search_api upgrade to 1.23
Priority: Normal » Major

The only reason that admin can use the search page is because it has the 'bypass node access' permission and that enables it to bypass all of the code in _search_api_query_add_node_access().

jelle_s’s picture

jelle_s
Primary language Dutch
Location Antwerp, Belgium
commented

We had the same issue, had to revert to search api 1.22

akolahi’s picture

akolahi commented

Our users are reporting the same issue as well.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Priority: Major » Critical
Status: Active » Fixed

Thanks a lot for noticing and reporting this!
Indeed, the patch in the other issue looks just aweful, on closer inspection. I'm very sorry for letting that slip past me!
I've now reverted that patch and created a new release right away: 7.x-1.24. This should fix the problems, as you said. It will be up to the people who wanted that feature to come up with a proper patch for it.

If you want to help avoid such problems in the future, you can try out dev releases of this module now and again. That would help make sure that no such obvious problems are present in stable releases. Apparently this buggy patch has been in the dev release for more than three months without anyone noticing.
Or, even better, help by reviewing/testing patches proposed patches now and again. (But I of course know it's hardly possible to do that for all the modules one uses.)

In any case, I of course should also take more care reviewing patches. Seems I've become lenient lately regarding patches in D7, since few people ever seem to care anyways, so I'm reluctant to go back and forth numerous times with a new patch, or review/test it in detail.
So, again, my apologies! I'll try to be more careful again in the future.
And thanks again for reporting this!

jcnventura’s picture

jcnventura
Primary language English
commented

Thanks @drunken monkey!

Status: Fixed » Closed (fixed)

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