Hello,

It happened when I tried to update SearchAPI to latest 7.x-1.0-rc1 right after running update.php at /update.php?op=info. 

Additional uncaught exception thrown while handling exception.
Original
SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1244 of /sites/all/modules/search_api/search_api.module).
Additional
SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1244 of /sites/all/modules/search_api/search_api.module).

Now website is not available at all. Could you please advice what can be done in order to restore it? Thank you!

Comments

drunken monkey’s picture

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

This is strange indeed. It seems the update function was successfully executed, but the cache was not cleared afterwards. Therefor, the hook implementation is not found.
Try to manually clear the cache, or to disable and then re-enabled the Search API module.

yurg’s picture

yurg commented

Thank you, will do: as far as I could see even node deletion relates from SearchAPI status now. Just found some records like this in Watchdog: 

SearchApiException: Search server with machine name search specifies illegal service class search_api_db_service. in SearchApiServer->ensureProxy() (line 133 of /home/admin/public_html/beta/sites/all/modules/search_api/includes/server_entity.inc).

Guess it's because update wasn't finished. SO just leaving error message here in order to help other searchers with same issue.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Category: bug » support
Priority: Major » Normal

See #1313088-9: Fatal error: Class name must be a valid object or a string in drupal/includes/common.inc on line 7522 and install the Database search module.

yurg’s picture

yurg commented
Category: support » bug
Priority: Normal » Major

Spoke too soon unfortunately: still get an issues with illegal service class search_api_db_service. in SearchApiServer->ensureProxy() (line 133 of.. even after disabling module - clearing cache - enabling module & disabling search server.

Additionally An error occurred while trying to index items on index contentsearch: Search server with machine name search specifies illegal service class search_api_db_service. error started to appear. Previously I resolved it by completely module re-installing, guess I have to repeat it now and afraid that will have to do it after next module update?

yurg’s picture

yurg commented

Ok, thank you! Will give it a try: let's see how it will work with "Search views" also.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Category: bug » support
Priority: Major » Normal
janip’s picture

janip commented

The "Unknown or invalid item type node." issue occurs in our project too during profile installation after upgrading to 7.x-1.0-rc1.

drunken monkey’s picture

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

During installation? OK, that's really weird, I can't imagine how that could ever happen. Could you maybe get a stack trace of the error?
Otherwise I'd have to conclude this is some weird hidden bug in core, not properly clearing the module_implements() cache or such.

janip’s picture

janip commented

I will do some debugging. The actual error message in our case is "Unknown or invalid item type .", so the type seems to be missing.

Our search index is exported as a feature (using older versions), so I think that is the problem. The exported index does not contain item_type and may be missing other important data as well.

drunken monkey’s picture

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

Our search index is exported as a feature (using older versions), so I think that is the problem. The exported index does not contain item_type and may be missing other important data as well.

As update functions naturally don't touch exported data, you should never do this anyways. Import the index, execute the update function, export the index again.
In this case, replacing all occurrences of 'entity_type' with 'item_type' should, however, also work.

Oh, apart from the fact that the field and workflow settings will be wrong, too. So yeah, just do the update the right way and you should have no problems.

Jujubre’s picture

Jujubre commented

I also have this issue during my installation process.

Jujubre’s picture

Jujubre commented

Reverting to beta10 allow me to pass the error.

yurg’s picture

yurg commented

Guess I should continue here. So, after Database search module installation I tried to configure SearchAPI and received these errors after saving Search Index: 

1. SearchApiException: Unknown server search specified for index contentsearch. in SearchApiIndex->server() (line 371 of /home/admin/public_html/beta/sites/all/modules/search_api/includes/index_entity.inc).
2. Notice: Undefined property: stdClass::$timestamp in _drupal_session_write() (line 175 of /home/admin/public_html/beta/includes/session.inc).

Additionally, after that I tried to configure (mean edit first and disable/delete after) my View which uses SearchAPI and received this on WSOD:

Fatal error: Call to a member function query() on a non-object in /home/admin/public_html/beta/sites/all/modules/search_api/includes/index_entity.inc on line 395

Will probably continue researches, but this time even don't know where to start from.

drunken monkey’s picture

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

Guess I should continue here.

Continue from where? And how is your error similar to the one discussed here?
Please don't randomly hijack issues!

yurg’s picture

yurg commented
Status: Active » Closed (won't fix)

Thank you for your help and sorry for hijacking: I just tried to follow your advises and continue posting results here in order to provide as much as possible issue details. Issue could be closed anyway: I decided to use core Search since my tasks don't require all SearchAPI power.
Thank you again and sorry for disturbance.

Kodiak’s picture

Kodiak commented
Version: 7.x-1.0-rc1 » 7.x-1.0-beta2
Status: Closed (won't fix) » Active

I have the same problem, I don't even know how it happened but when trying to create a new index, the "item type" dropdown only shows the type "user".
And when I try to access a previously created index on nodes, I get this very error.

SearchApiException : Unknown or invalid item type node. dans search_api_get_datasource_controller() (line 1334 in [...]\drupal-7.18\sites\all\modules\search_api\search_api.module).

The same error occures when I try to uncheck Search API in the module list... So I can't even uninstall it.

EDIT: sorry, my version of Search API is 7.x-1.3, not beta2

Kodiak’s picture

Kodiak commented
Version: 7.x-1.0-beta2 » 7.x-1.4

Reproduced with 1.4

Todd Young’s picture

Todd Young commented

Ditto. Something I've installed - either Search API or Commerce Search API has tried to create an index during install, but the index it created has no name or other fields populated. Can't delete it, can't populate & save it.

ajlozier’s picture

ajlozier commented

This may be completely unrelated, but I had this same error. Once I disabled APC cache the problem went away.

vaccinemedia’s picture

vaccinemedia commented

I get:

SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1336 of /var/www/vhosts/commerce.pix/httpdocs/profiles/commerce_kickstart/modules/contrib/search_api/search_api.module).

When installing Node Export and UUID on Commerce Kickstart (no demo store).

ruski’s picture

ruski commented

Upgrading to the latest dev version of UUID fixed this for me.

BParticle’s picture

BParticle commented

Same here, latest dev of UUID fixed this ugly error.

drupalninja99’s picture

drupalninja99 commented

Does search api have some kind of dependency on uuid? I am running into the same issue. I really don't want to have uuid installed if I don't need it. Is it a situation where uuid either needs to be a) upgraded or b) uninstalled?

I don't understand the relationship.

gmclelland’s picture

gmclelland commented

@drupalninja99 - There's no dependency. If you use UUID, then it needs to be upgraded. At least I think that is what fixed it for me.

drupalninja99’s picture

drupalninja99 commented

OK well one problem I discovered was that I was using the wrong schema.xml. I had copied the apachesolr one instead of the search_api_solr schema which is different. So this might be a search_api_solr issue. I thought that would fix the problem but sadly it didn't.

drupalninja99’s picture

drupalninja99 commented

OK I found my problem:

My server setting at /admin/config/search/search_api/server/dev_solr/edit was different than the search configured with the apache solr module. So I just had to fix that. I had dumped a production site that I was setting up locally so I had to change the solr server info and that's what was breaking.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Active » Fixed

OK, seems like no-one has any problems here anymore?
For UUID users, as said, please use the newest dev version (and maybe go to #1663390: Roll a new UUID stable release and help trying to talk some sense into the maintainers).

Status: Fixed » Closed (fixed)

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

texas-bronius’s picture

texas-bronius commented

Just sharing with the world.. Latest uuid 1.0-alpha and then -dev, still no joy.

My situation:
Developing locally, mysqldump and restore to remote Pantheon server: Kablammo! Every time I visit a particular index's Status page I get the error:

SearchApiException: Unknown or invalid item type denormalized-node. in search_api_get_datasource_controller() (line 1705 of ... search_api.module).

Not reopening, per se, as I've never had problems like this before-- just sharing more forensics in hopes it helps someone else. (or me) I did in fact just delete the Index (which initially produced the error again, but hitting back gave 404 on that index, and up one level showed the index gone: no more error).

divined’s picture

divined commented
Version: 7.x-1.4 » 7.x-1.11
Issue summary: View changes
Status: Closed (fixed) » Active

SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1853 of /sites/all/modules/search_api/search_api.module)

divined’s picture

divined commented
Status: Active » Fixed

Search API Attachments Field Collections module problem.

divined’s picture

divined commented

Nope.
At evening all was fine. Open site at morning and i get:
SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1705 of ... search_api.module).

divined’s picture

divined commented 
 $datasources = &drupal_static(__FUNCTION__, array());

return zero array();

drunken monkey’s picture

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

… What?
Is this fixed now or active? In the latter case, what do you want to say with the last comment?

divined’s picture

divined commented

It's active.

Is this fixed now or active? In the latter case, what do you want to say with the last comment?

Try to find error.

divined’s picture

divined commented

Any manipulation with modules (Install or Uninstall) fix error on a few days.
And after few days of site inactivity i get this error again.

divined’s picture

divined commented

it's entity module problem.

/includes/entity.property.inc
20 function entity_get_property_info($entity_type = NULL)

32 cache_get("entity_property_info:$langcode") not return "node" info

something broke this cache ((

Status: Fixed » Closed (fixed)

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

zuernbernhard’s picture

zuernbernhard commented

Same Problem here:

SearchApiException: Unknown or invalid item type profile2

zuernbernhard’s picture

zuernbernhard commented
Status: Closed (fixed) » Needs work
drunken monkey’s picture

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

@ zuernBernhard: Please provide a bit more detail and context. When does this happen?
Better still, please close this again and open a new issue. This one is too full of year-old bug reports which probably haven't got the same cause as your issue.

zuernbernhard’s picture

zuernbernhard commented

Ok,

haven't seen the problem during the last 3 or 4 days. WIll open a new issue if it occurs again. Thank you anyway !

zuernbernhard’s picture

zuernbernhard commented
Status: Needs work » Closed (cannot reproduce)
mrded’s picture

mrded commented

I can confirm this problem on 7.x-1.11 version.
7.x-1.13 seems to solve the problem,

dergachev’s picture

dergachev commented

Just an FYI we're having the same problem, and after hours of debugging it was caused by this:
https://www.drupal.org/node/496170

In our case we had upgraded to php 5.3, which caused some depreciation warnings very early in the bootstrap due to watchdog.
This too-early use of watchdog polluted (corrupted) the module_implements() caches.
The solution for us? Fix the warnings in the code. But obviously it's a really thorny issue and I'm hoping that in a few months/years it's properly addressed in core.
That hook caching scheme is pretty complicated and the errors it causes are hard to track down, which might explain why that bug hasn't been fixed for so many years.