When a search term includes forward slash, _entity_properties in the views result set becomes an array of empty fields.
The end result of this in my case is that the results have no titles.

This happened on a setup with
search_api 7.x-1.11
search_api_solr 7.x-1.4+10-dev

And also on another site with
search_api 7.x-1.13
search_api_solr 7.x-1.6

This issue might belong in the search_api_solr module, but my first guess would be that it has to do with the views integration.

CommentFileSizeAuthor
#4 search_api-highlighter_escape_forward_slash-2427923-4.patch650 bytesOWast

Comments

broon’s picture

broon
Location Potsdam
commented

I actually got this problem with the "Apache Solr Search" module, "SearchAPI" with "SearchAPI Solr" work fine for me.
The former is called through /search/site (opposing to Drupal core search at /search/node, which works fine as well by the way).

For example, on an archiving website we are digitalizing and storing old school files (as in a filing cabinet). The corresponding nodes' titles just have the original file ID, e.g. "2012/08/634" for the 634th case of August 2012.
Entering that title into the Drupal core search results in /search/node/2012/08/634 and the correct file pops up in the results list.
Accessing Apache Solr Search, entering "2012/08/634" in the text field and hitting enter leads to /search/site/2012%252F08%252F634, so this time it's urlencoded but it shows the correct result as well.
The SearchAPI Search page created with views is located at /supersearch and putting the title in the search term box results in /supersearch?find=2012%2F08%2F634 showing the correct file.

Now comes the catch. On all three searches, there is the filter for content type. Clicking on a content type to filter the results, leads to different behaviour.
For example, clicking on "medical" in SearchAPI Search leads to /supersearch?find=2012/08/634&f[0]=type%3Amedical, still showing "2012/08/634" in the search box and the file I am looking for in the results list.
For the Drupal core search, I am redirected to /search/node/2012/08/634%20type%3Amedical. The search box now reads "2012/08/634 type:medical" and shows the correct file.

However, Apache Solr Search leads to /search/site/2012/08/634?f[0]=bundle%3Amedical (which looks correct). The search box however only contains "2012" instead of the full search term "2012/08/634". The results list is full of files from 2012, the file I am looking for is not even on the first page of search results.

My setup:
Drupal 7.34
SearchAPI 1.14
SearchAPI Solr 1.6
Apache Solr Search 1.7

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

I cannot reproduce the behavior from the original post. (The one in #1 describes a bug in Apache Solr Search, so should maybe be reported there.) Please provide more details so I'll hopefully be able to reproduce the problem.

The only irregularity I could find is when you use a contextual filter for the keywords – then, of course, a slash in the keywords will lead to the keywords being truncated to the portion before the slash (and if the view has arguments, cdhaos might ensue). That's a problem with Views, though, not with this module.
In no case can I reproduce the missing properties, though.

OWast’s picture

OWast
Location Ljusvattnet, Burträsk, Sweden
commented

Yeah, #1 is definitely not related.

I'll explore if the views bug you describe could cause this. Otherwise I'll dig a little deeper and see if I can find more info, or a solution.

OWast’s picture

OWast
Location Ljusvattnet, Burträsk, Sweden
commented
Component: Views integration » Plugins
StatusFileSize
new search_api-highlighter_escape_forward_slash-2427923-4.patch650 bytes

Turned out that the culprit was the highlighter. It performs a regexp on the keywords that can't handle forward slashes. It might be better to rewrite the regexp, but here is just adding an escape for the / character.

OWast’s picture

OWast
Location Ljusvattnet, Burträsk, Sweden
commented
Status: Active » Needs review
drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Needs review » Needs work

Huh. Curious. In theory, that's exactly what the preg_quote() calls in the line above your change are there for. In my tests, your patch even broke this again, since it changed \/ to \\/ – i.e., instead of an escaped slash, an escaped backslash followed by the end of the pattern.
Could you maybe try out what $keys contains before and after both that line and your new one? I can't really understand how that might be the problem.

Otherwise, escaping would of course be the correct solution – I just really thought we already did that. (Also, using preg_quote() is a better way to escape the keys, since otherwise you run into exactly the same problem with other PCRE special characters.)

OWast’s picture

OWast
Location Ljusvattnet, Burträsk, Sweden
commented

True dat! Very weird. The preg_quote should do it. But:

before =>  2009/100
after preg_quote => 2009/100
after new line => 2009\/100
drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Version: 7.x-1.13 » 7.x-1.x-dev

Weird stuff. I now tested the complete setup (previously I just tested whether that statement works), but I still can't reproduce this problem. From how it looks to me, this shouldn't be possible. (I also couldn't find any reference to the $delimiter parameter of preg_quote() being absent in earlier PHP versions, which I considered as the sole possible reason.)
Please try to find out how this is going wrong in your setup, and how we might fix this properly (if necessary). Please also try the latest dev version of the Search API, if you haven't already – maybe that will fix it?

OWast’s picture

OWast
Location Ljusvattnet, Burträsk, Sweden
commented
Status: Needs work » Closed (duplicate)

Okay, I understand the problem now.

The preg_quote in 1.11 specifies no delimiter:

    $keys = implode('|', array_map('preg_quote', $keys));

The current dev, however, does:

    $keys = implode('|', array_map('preg_quote', $keys, array_fill(0, count($keys), '/')));

Since the forward slash isn't an actual regex special character, it's not escaped in the first version.

This is fixed in 2168713

Sorry to bother you, I should have tested with the latest version before I started digging in this again.