Fatal Error: Call to a member function getOption() on a non-object

subscribing

I just updated the search_api module (7.x-1.6 to 7.x-1.11) a few days ago, and work on it without paying attention to the rest of the site.
But now most of my menu's link (which all lead to a view page) get to

Fatal error: Call to a member function getOption() on a non-object in \modules\contrib\search_api\contrib\search_api_views\includes\query.inc on line 251

Strange matter that some of the menu's links still work.

And this not even a kickstart profile. I didn't try to re-upload or run patch. And Rules, Views and search seems to work for me.
And mmmm well this is a d7 commerce site... But wasn't me who build it, but I can guess that it's start as a simple Drupal, and they download commerce after and then add about one hundred contrib' -- /me is embarassed --.

Hi

It seems I have found something rather interesting !
I was resolving another problem then I was looking on the taxonomy. I noticed that the URL alias in the taxonomy was link to the URL alias in the menu.
E.g.

URL Alias Taxonomy : chicken/egg
URL Alias Menu : taxonomy/tid654

I have tried to change the URL alias Menu as "chicken/egg", but after saving it came back to "taxonomy/tid654".

So I checked the "Generate automatic URL alias" box in URL Alias Taxonomy. After saving The URL Alias Taxonomy changed, but the alias "chicken/egg" got in the URL redirect. I did delete it this time.
Then I changed the URL Alias Menu and everything was allright.

Here a recap how I did :

1. URL Alias Taxonomy : Check the "Generate automatic URL alias", save.
2. URL Alias Taxonomy : Delete the URL redirect, save.
3. URL Alias Menu Link : Change the alias, save.

Sometimes I didn't event need to do the sept 1 and 2.

I hope, I was clear enough and that it will help you.

Well its seems we have that error on every URL Alias from taxonomy. And since URL alias Menu is redirecting on the taxonomy.

If someone else could confirm this, that will surely help debugging. (Structure -> Taxonomy -> 'Choose a Vocab' -> 'click on link' )

In a certain case I get the same error message as mentioned in #1 using a standard Drupal installation (without Commerce).

Module versions:

• Search API 7.x-1.11+4-dev incl. Search views
• Database search 7.x-1.2
• Search pages 7.x-1.0

When I use Search Pages everything is ok. But using the Views integration as explained in the documentation (with Database search instead of Fuzzy search), the error appears, namely on all pages, where the block with the exposed search form is shown.

The error in the OP looks like the index is using a server (machine name "frontend") which doesn't exist. Go to the Search API settings and see whether you have a server set up. If not, set one up. Then go to the "product_display" index and edit it to use the existing server.

Hi drunken money, as I understand, your answer refers to the first error mentioned in the original issue post (unknown server frontend). What do you think about the other error (Call to a member function getOption() on a non-object ...) , also mentioned in #1 and referred to in #5? Thanks in advance!

I refer to both errors mentioned – when no server is found, no query object can be created and therefore $query->getOption() would lead to the second error.

Hey, thank you for your answer! I had set up a server, but now I checked if my view used a server, and indeed: it did not!

Background: I had set up a combination of custom search index and database server which I tested successfully with Search Pages. When I added the view, by mistake I didn't chose the custom search index but another one which was without server.

Solution: I built a new view with the custom search index which has a server. (You have to choose the search index when you add the view. Couldn't find an option to choose the search index in the the views configuration itself.)

So, I don't know if the issue should be closed, but in my case everything is ok.

drunken monkey - Thank you for your answer. This was exactly my problem and I am under a lot of stress to complete a project that uses Search API. You really helped me out.

ALready i have the same error when disable a Job index take look

http://puu.sh/gbygO/867c1b4a70.png

[24-Feb-2015 20:10:42 ] PHP Fatal error: Call to a member function getOption() on a non-object in profiles/recruiter/modules/search_api/contrib/search_api_views/includes/query.inc on line 251

This server and index search i disable why i have lot of register in this server and index thaht disable and make a new index for my new register but already have this error page blank =(

I'm sorry, but I don't understand your post. Please try to find someone to translate for you.
Also, could it be that you are trying to view or edit a view which uses a disabled search index? What are you trying to do when the error occurs? Are there any relevnat entries in Drupal's logs?

I have the same error.

In fact the problem is with views integration.

If we remove an search index which is used in a view : Call to a member function getOption() on a non-object (...) error when using this view on the site (or in view admin page).

The fix should be : "be able to change search index of a existing view, not only when creating one."

Workaround is to create another view, using the right "new" index

:)

I had the same issue, but when adding Search Facets via panels - I was getting Fatal error: Call to a member function getOption() on a non-object - my temporary fix was to enable disabled indexes and search server. I guess the fix here should be to also check whether the object was instantiated and only then call this method - I will try to provide a patch for this asap.

I propose a simple patch here, it allows for graceful degradation where if there are errors with the SearchApiViewsQuery object it does not try to build the query and shows the error message to the user and logs it into log. This makes much more sense and provides a clue to administrator where the issue comes from.

Thanks for the patch, looks like a sensible way to at least prevent these fatal errors.
However, we already print the error further down, in execute(), so it's unnecessary to do the same in build(), too. Also, instead of wrapping the whole method body in an if, just bailing early if there are errors makes for nicer code, I'd say.

Revised patch attached, please review!

OK that definitely makes more sense, I didn't realise that execute() does the displaying already. I guess we can go with RTBC now, and get this committed to everyone getting these puzzling errors! :)

Good to hear, thanks for reviewing!
Committed.
Thanks again for your intiative here!