Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Hi there, looks to be a very useful module but Im having problems setting this up and hoping you can help.
Drupal 7.18
commerce 7.x-1.4
Commerce Search API 7.x-1.0-rc2
Apache Solr search 7.x-1.1
Facet API 7.x-1.2
Search API 7.x-1.3
Search facets 7.x-1.3
Search ranges 7.x-1.4
Search sorts 7.x-1.3
Search views 7.x-1.3
Solr search 7.x-1.0-rc2
not using:
apache solr search
apachesolr commerce
approx 10k products with various attributes
I have successfully set up the solr instance and can connect, have been able to set up search API add server and then add index (and index content) after having some problems because I was using the wrong solr xml files from Apache Solr search module and not the Search API Solr search versions i managed to - this post was very useful re setting up solr http://zugec.com/73-how-setup-search-api-apache-solr and search API.
Im following the instructions in the how to video (which is great) but when I try and enable this module I get the following error:
Fatal error: Call to a member function supportsFeature() on a non-object in /mnt/web/www/sites/hswalsh/html/sites/all/modules/contrib/search_api/contrib/search_api_facetapi/search_api_facetapi.module on line 56
Any help would be much appreciated...
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 1879196-8--indexes_with_invalid_server.patch | 927 bytes | drunken monkey |
| #5 | search_api-1879196-5.patch | 1.23 KB | mrded |
Comments
Comment #1
jsacksick commentedHi there,
This module has nothing to do with the apachesolr module, this module create a preconfigured index with all the product attributes indexed in order to facet on them.
This module was covered on "Commerce Module Tuesday", you can view the screencast here.
+ If you carefully read your error, it seems to come from the search api submodule called "search_api_facetapi", perhaps you should move the issue to this issue queue.
Comment #2
kevster commentedHi jsacksick - thx for replying, I watched the screencast which is very useful. I didnt realise there was a separate issue queue for the search_api_facetapi as it seems to come bundled with the search api module. There is also a facetapi module which looks to be needed for this to work?
[edit] - the error occurs specifically when I turn on the search facets module (search API already on, search ranges and search views fine)
[edit] - after doing some more investigating, updating modules to latest dev etc I was still getting the error but noticed in the log:
SearchApiException: Unknown server database_search specified for index product_index. in SearchApiIndex->server() (line 377 of /mnt/web/www/sites/hswalsh/html/sites/all/modules/contrib/search_api/includes/index_entity.inc).
This was referencing an old index (product_index) that I had deleted as the only one current is all_nodes_index. I ended up going in to the database and clearing out 2 old indexes in the search_api_index table, they were not showing under search API indexes. I also deleted related records in the search_api_index table.
This seems to have cleared my issue and I can now enable the commerce_search_api module which has created the new product display index.
Comment #3
mrded commentedHere's the patch.
Comment #4
mrded commentedComment #5
mrded commentedNew version.
Comment #6
drunken monkeyThanks for providing a patch for this issue!
However, enabled indexes should always have a valid server, we should be able to rely on that. If you managed to delete a server (in a correct way, i.e., not just removing it from the database manually) without its indexes being removed and marked as disabled, that's the bug that should be fixed. However, I'm pretty sure this cannot happen in newer versions, so probably that's just old data that ended up this way due to an old bug. If you can reproduce this state with the latest module versions, then please report the steps you took and we'll try to fix that. Otherwise, this is "works as designed", I'd say.
At maximum, we could add an update hook that would do a sanity check on all indexes (and maybe servers, too) to ensure that no such old buggy data is present in the database.
Comment #7
mrded commentedUnfortunately, I cannot provide to you reproducing steps because it's bug from our real project, that probably has old indexes (as you said). With clean Drupal installation it works perfectly.
I think button into settings that will clean old indexes will be really useful.
Some warning into 'Status report' page will be useful as well.
Thank you!
Comment #8
drunken monkeyOK, good to hear. Then I guess we should just clean up the database in an update hook once. Patch attached.
Sadly, it can only check for illegal/unknown servers for indexes, not for unknown item types or servers' service classes (since we can't call hooks from update functions). But that should eliminate at least most of the problems. Otherwise, you should be able to just delete the offending server or index (maybe after applying #1227702-29: Improve error handling).
Anyways, please test whether running
update.phpafter applying the attached patch correctly disables the offending index and gets rid of that warning/error.Comment #9
drunken monkeyComment #10
mrded commentedIt's great, but what if indexes breaks again? There should be a way to check indexes and clean up tables.
Comment #11
drunken monkeyNo, there shouldn't. We should just take care that this doesn't happen anymore. If another module, custom code or custom manipulation leads to this happening, I don't think we are responsible.
I don't know of anywhere else where there is a "Fix faulty data" button.
Comment #12
drunken monkeyCommitted.