Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.PHP Fatal error: Call to a member function getOriginalKeys() on a non-object in modules/contrib/search_api/contrib/search_api_facetapi/plugins/facetapi/adapter.inc on line 167
When I specify a longish string in the query like
/search?search_api_views_fulltext=ex1208312hex1208312hex1208312hex1208312hex1208312hex1208312hex1208312hex1208312hex1208312h234234234234234234234234234234234234234234
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | getsearchkeys_called-1670420-11.patch | 774 bytes | dorficus |
| |||
| #2 | current-search-on-nonsearch-pages-1670420-2.patch | 791 bytes | kyletaylored |
| #1 | 1670420--debugging-1.patch | 636 bytes | drunken monkey |
Comments
Comment #1
drunken monkeyHm, sorry, I can neither reproduce nor explain this. What backend are you using? And about how long does the search string have to be?
Could you install the Devel module, apply the attached patch to the Search API and then report back what you're seeing when you try to reproduce the bug?
Comment #2
kyletaylored CreditAttribution: kyletaylored commentedI actually had this exact same issue yesterday. I don't know why, but what was happening was the Current Search block was showing up on non-search pages. Devel didn't do anything because nothing was being passed to $search. This helped me out.
Comment #2.0
kyletaylored CreditAttribution: kyletaylored commentedworks even with a shorter string
Comment #3
sepehr.sadatifar CreditAttribution: sepehr.sadatifar commentedI get the same error when the path doesn't exists, for example when viewing http://site/products/clothes/socks I get this:
Fatal error: Call to a member function getOriginalKeys() on a non-object in modules/contrib/search_api/contrib/search_api_facetapi/plugins/facetapi/adapter.inc on line 174.
I checked "$search" variable and it's NULL.
Comment #4
drunken monkeyThe workaround from #2 would of course work for us. However, the actual issue seems to be deeper, i.e., in the Facet API. As I understand it,
getSearchKeys()shouldn't be called ifgetCurrentSearch()returnsFALSE(which should be the case here – but maybe you can debug that to make sure?). So, moving this to the Facet API queue for possible insights.I still can't reproduce this, so have little chance of helping to debug.
@ sepehr.sadatifar: Do you maybe have some setup that executes a search on 404 pages, or some other special 404 mechanism?
Comment #5
cpliakas CreditAttribution: cpliakas commentedTo me that logic makes sense since there shouldn't be search keys if Fact API doesn't know about any searches. Let's double-check the code and figure out the fix.
Comment #6
sepehr.sadatifar CreditAttribution: sepehr.sadatifar commented@drunken-monkey no module or custom code related to 404. the #2 patch works, I get no error just a page with no result.
Comment #7
sepehr.sadatifar CreditAttribution: sepehr.sadatifar commented#2 patch seems ok and I think should be commited.
Comment #10
dorficus CreditAttribution: dorficus as a volunteer commentedI'm running into the same issue. I'm going to be re-submitting a patch based on #2, but current with the latest version.
Comment #11
dorficus CreditAttribution: dorficus as a volunteer commentedMoving this back to Search API since the issue is coming from the Search API file and the patch I'm uploading is attached to Search API
Comment #12
dorficus CreditAttribution: dorficus as a volunteer commentedComment #13
dorficus CreditAttribution: dorficus commentedComment #15
drunken monkeyOK, since there hasn't been any activity in the issue on the Facet API side, I guess we might as well fix it on our side. (Should probably have done that right away, since it's a fatal error.)
So, thanks for re-rolling, and thanks again for the original patch, kyletaylored!
Committed.
Moving back to the Facet API, since the underlying issue remains.