When searching, in some cases I get this error:

Fatal error: Call to undefined method Zend_Search_Lucene_Search_Query_Insignificant::getSubqueries() in sites/all/modules/luceneapi/luceneapi.module on line 1170

CommentFileSizeAuthor
#3 luceneapi-724074-3.patch1.42 KBcpliakas

Comments

wimh’s picture

wimh commented

BTW this is only with 2.1. Doing the exact same search with 2.0 worked without problems.

cpliakas’s picture

cpliakas commented
Priority: Normal » Critical

Could you tell me what searches are working? What searches are not working? If there is some pattern to what is breaking the search, it will help me resolve this more quickly.

Thanks,
Chris

cpliakas’s picture

cpliakas commented
Status: Active » Needs review
StatusFileSize
new luceneapi-724074-3.patch1.42 KB

Hi wim.

I added some defensive coding to prevent the error, but my though is that if you are getting an insignificant query object, the parser is not able to parse the search terms for some reason. I would make 100% sure that there are no errors in admin/reports/status, and I would also verify that the iconv extension is available on the server. Please see if the attached patch fixes your issue.

Thanks,
Chris

wimh’s picture

wimh commented
Status: Closed (fixed) » Needs review

Hi Chris,

Your patch does solve the symptoms. But now that I was able to dig a bit further:

* the search query I was using came from the Search404 module, which I patched to use Lucene search: #603758: Use Search Lucene Content when available
* I browsed to the invalid path /aadmin/settings/mollom, which makes Search404 generate the search query "aadmin OR settings OR mollom" and pass it to lucenceapi_node_search
* this in itself works

The problem occurs in a *second* call of luceneapi_query_parse(), made by luceneapi_facet (I have a facet search block enabled)

* the $keys argument to this call is NULL, causing the Zend_Search_Lucene_Search_Query_Insignificant query object
* luceneapi_facet.module:luceneapi_facet_block_realm_render(), the one making the call to luceneapi_query_parse(), gets $keys from search_get_keys()
* since the search did not originate from the search form, search_get_keys() returns nothing.

The search404 module defines its own search404_get_keys(), which is duly passed to the first luceneapi_query_parse() call, but not to the second luceneapi_facet-initiated one.

To solve this properly, I would say that the luceneapi_facet module should get the search keys directly from luceneapi/luceneapi_node in some way, and not assume that the regular search form was used. But I have no idea if this is doable or even possible...

cpliakas’s picture

cpliakas commented
Status: Needs review » Reviewed & tested by the community

Hi Wim.

Thanks for the detailed use case! It is much appreciated. I agree with you that architecturally the search keys should not be dependent on search_get_keys(), and it is a great observation on your part. I am going to download the Search 404 module, apply your patch, and try to come up with a solution. I love it when developers integrate with other contribs, so I will do my best to come up with a working solution we all can live with. The search_get_keys() issue can get a bit tricky and is one of the problems with the core Search API, but my first though is there has to be a way around this.

Again, thanks for your great detective work!
~Chris

cpliakas’s picture

cpliakas commented

This patch will be applied as part of the #719836: Add defensive coding to the luceneapi_query_parse() API function task.

cpliakas’s picture

cpliakas commented
Status: Reviewed & tested by the community » Fixed

Fixed in issue #719836: Add defensive coding to the luceneapi_query_parse() API function.

Status: Fixed » Closed (fixed)

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

wimh’s picture

wimh commented
Status: Needs review » Closed (fixed)

FYI: the patch to use Lucene Search in the Search 404 module is included in their 6.x-1.9 release.

cpliakas’s picture

cpliakas commented

Thanks for the follow-up, Wim!