Fatal error: Class 'searchQuery' not found ..

Do you have search.module enabled?

This class is part of drupal core, so i have no idea how to help here.

Could it be that some kind of cache isn't cleared often enough ;)

Wow.

This really worked for me all the time. Commited the patch.

Which version of php did you used? Perhaps this is just special for a new version of php. Here i use php 5.3 and it worked fine.

Did you tryed to add a filter manually to the view before the patch?

Just wanted to know...

i have the same problem, but appears only if i DISABLE core search module.

If you disable the search module and you are still using a view handler that's expecting the SearchQuery class, you will probably get issues. I think you either need to remove any search handlers from your view, or re enable the search module.

So you disable search.module but you don't clear any caches?

I would bet that if you clear the views caches, the problem would go away...

Well one thing you could do is to wrap the class with a module_exists().

I'm not sure where the documentation could be placed to be able to be found as this is quite a special problem.

Well, here we are, October 2013, and this issue has reared its head. Ironically, I disabled search to try to solve a different problem (too many modules). Ah well, at least the answer is easy to find, but a more graceful failure mode would be lovely.

I have this problem, and I need to disable search module. October 2014, but problem isn't solved yet?

I am a neophyte Drupal user so treat the following with some patience. It might be useful info. I got to installing the Enterprise Blog module and related modules. I encountered this Fatal Error when enabling the modules. I surmise I was trying to enable too many modules at one time with limited amounts of shared memory.

I saw a Fatal Error message indicating that I was out of memory and that something had failed to allocate. I hit the browser back button and tried again, which is when I saw the:

Fatal error: Class 'SearchQuery' not found in ......modules//search/views_handler_filter_search.inc on line 201

error message. The site crashed, and I did not appear to be able to log in or access the administration menus. But after a lot of nail-biting, poking around on the web and sleeping on it, I was able to recover it. It seems the crash caused a lot of the core modules to be disabled, but I had an administration session open which allowed me to access the Modules page and re-enable them incrementally, along with rebuilding some of the databases. A lot of the content was gone but (fortunately) I had set up Backup/Migrate a few days ago and I was able to restore 95% of what was missing.

FYI I ran into this on a Windows server that was running wincachedrupal, I had to reboot the server to force the cache to clear, even Drush was triggering the error.

BTW I ran into the problem after disabling the core Search module after building a replacement with Search API.

FWIW, we had the same issue as #21, hitting on this error with a site that uses core search.module and had Search API and Search API Solr stood up after that. Attempting to disable core search.module returns this error.

@vinmassaro: It was a bit weird - on my local Mac/MAMP install it worked again after just clearing cache_views, but the Windows server took extra prodding,

I was working with Vincent, and here's how we disabled search. A bit of a workaround:

/**
 * Disable search module.
 */
function custom_update_7000(&$sandbox) {
  // We cannot just run a module_disable, because of class dependencies.
  db_update('system')
    ->fields(array('status' => 0))
    ->condition('name', 'search')
    ->condition('type', 'module')
    ->execute();
  views_invalidate_cache();
  cache_clear_all();
}

The proper fix in the code, I think is to wrap the views class in an IF exists check.

Like so?

I was having this issue after disable the core search module in favor of search_api implementation and tried the @agentrickard workaround that worked perfectly. Thanks.

Same issue as #26 and the patch in #25 fixes the issue for me.

Sorry for the harsh words.

I don't think this is a good idea

1. You can solve it really fast using drush rr, or even running update.php can't you?
2. I think supporting disabled modules is stupid, especially with search module. You can drop the data without any issues.
3. If you really want to fix it, put the additional class in its own file, register it properly ... this would be the right solution.

Talked with dawhener about this, agree totally with what he is saying ^^. Wrapping the class definition is a module_exists() is not a good plan...

#24 worked for me.

I ran drush rr.
Then I disabled the search module.
That seemed to work for me.

#24 worked for me with modifications. I had to clear the cache_bootstrap bin.

/**
 * Implements hook_update_N().
 *
 * Uninstall the search module.
 */
function hook_update_N() {
  db_update('system')
    ->fields(array('status' => 0))
    ->condition('name', 'search')
    ->condition('type', 'module')
    ->execute();
  views_invalidate_cache();
  cache_clear_all('*', 'cache_bootstrap', TRUE);
  drupal_uninstall_modules(array('search'), TRUE);

  return t('Uninstalled the search module.');
}
// End of hook_update_N.

I ran drush rr.
Then I disabled the search module.
That worked for me.

I had run drush rr with the search module already disabled, but continued to get the error. Once I enabled search and then ran drush rr, I was able to disable the search module with no errors.

There are some cases where none of the patches here will solve it. (other than the class/module exists wrappers)

Take this example, with Date module, _date_views_fields() (search module has been disabled, rr has been run)

  // We use fields that provide filter handlers as our universe of possible
  // fields of interest.
  $all_fields = date_views_views_fetch_fields($base, 'filter');

  // Iterate over all the fields that Views knows about.
  $fields = array();
  foreach ((array) $all_fields as $alias => $val) {
    [ ... snip ... ]

    // If we don't have a filter handler, we don't need to do anything more.
    if (!$handler = views_get_handler($table_name, $field_name, 'filter')) {     <---- boom
      continue;
    }

Date iterates over all the fields and tries to check if there is a filter for it also.

Because of this, the views_handler_filter_search.inc is included and triggers a fatal:

PHP  22. views_get_all_templates() /home/devin/docker/www/ethos7/sites/all/modules/contrib/views/views_ui.module:56
PHP  23. calendar_views_templates() /home/devin/docker/www/ethos7/sites/all/modules/contrib/views/views.module:1421
PHP  24. date_views_fields() /home/devin/docker/www/ethos7/sites/all/modules/contrib/calendar/includes/calendar.views_template.inc:33
PHP  25. _date_views_fields() /home/devin/docker/www/ethos7/sites/all/modules/contrib/date/date_views/date_views.module:159
PHP  26. views_get_handler() /home/devin/docker/www/ethos7/sites/all/modules/contrib/date/date_views/includes/date_views_fields.inc:55
PHP  27. _views_prepare_handler() /home/devin/docker/www/ethos7/sites/all/modules/contrib/views/views.module:1296
PHP  28. _views_create_handler() /home/devin/docker/www/ethos7/sites/all/modules/contrib/views/includes/handlers.inc:87
PHP  29. class_exists() /home/devin/docker/www/ethos7/sites/all/modules/contrib/views/includes/handlers.inc:34
PHP  30. spl_autoload_call() /home/devin/docker/www/ethos7/sites/all/modules/contrib/views/includes/handlers.inc:34
PHP  31. drupal_autoload_class() /home/devin/docker/www/ethos7/sites/all/modules/contrib/views/includes/handlers.inc:34
PHP  32. _registry_check_code() /home/devin/docker/www/ethos7/includes/bootstrap.inc:3403
PHP  33. include_once() /home/devin/docker/www/ethos7/includes/bootstrap.inc:3498
Drush command terminated abnormally due to an unrecoverable error.                                                                                       [error]
Error: Class 'SearchQuery' not found in /home/devin/docker/www/ethos7/sites/all/modules/contrib/views/modules/search/views_handler_filter_search.inc,
line 201

Date isn't doing anything specific to Search and is using standard Views functions.

Clearing all caches/invalidating the Views cache does appear to fix the problem but other modules might make it pretty difficult.

Resolution #12 worked for me. Thanks.