After installing Sarnia, adding a server, adding an entity, clearing cache (similar to here?) leads to this error and drupal becoming unreachable:

Additional uncaught exception thrown while handling exception.
Original

Exception: SolrPhpClient library not found! Please follow the instructions in search_api_solr/INSTALL.txt for installing the Solr search module. in SearchApiSolrService->connect() (line 235 of /home/quickstart/websites/dev.dev/sites/all/modules/search_api_solr/service.inc).
Additional

Exception: SolrPhpClient library not found! Please follow the instructions in search_api_solr/INSTALL.txt for installing the Solr search module. in SearchApiSolrService->connect() (line 235 of /home/quickstart/websites/dev.dev/sites/all/modules/search_api_solr/service.inc).

Latest dev of both modules and note that using a regular search_api_solr server and index does not result in this error occuring. To get the site back I marked sarnia disabled in system table and deleted the sarnia related records in sarnia tables/search api tables.

And yes I definitely do have SolrPhpClient installed under libraries with libraries module installed :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

7wonders’s picture

Project: Sarnia » Search API Solr
Issue summary: View changes

edit

dlcerva’s picture

Project: Search API Solr » Sarnia

The issue stems from search_api_solr_init(). It appears something is calling SearchApiSolrService->Connect() much earlier in the process than what Search Api - Solr intended. This can be verified by substituting hook_init() with hook_boot().

sanduhrs’s picture

Same issue here.

mgifford’s picture

As per:
$ vi sites/all/modules/search_api_solr/INSTALL.txt

I've also got the library up here:
$ ls sites/all/libraries/SolrPhpClient
Apache ChangeLog COPYING phpdocs tests

Still getting this error.

dawehner’s picture

Here is a small "backtrace" of the problem:

* bootstrap.inc:drupal_boostrap_full
* menu.inc: menu_set/get_custom_theme
* menu_get_item
* views_ui_cache_load
* views_get_view
* ... (the caches are cleared so the views caches as well)
* search_api_views_views_data
* entity_load of the sarnia entity
* SearchApiSolrService->connect() to load the actual important values

Alternative the menu cache might not be there, so it's rebuilt, so views has to load it's values as well.
It would be somehow automatically solved if the views data would be rebuild before menu.

dawehner’s picture

FileSize
39.29 KB

Sorry forgot to post the full backtrace screenshot

dawehner’s picture

Another possible way to solve this (beside replacing hook_init with hook_boot) would be to register the classes of search_api_solr directly in the drupal registry.

dawehner’s picture

Project: Sarnia » Search API Solr
Status: Active » Needs review
FileSize
2.3 KB

So here is a working patch for me.

jmdeleon’s picture

Patch in #7 doesn't work when installing and activating search_api_solr module, receiving following message:

LogicException: Function '_search_api_solr_autoload' not found (function '_search_api_solr_autoload' not found or invalid function name) in spl_autoload_register() (line 10 of /home/drupal/sites/all/modules/search_api_solr/search_api_solr.install).

jvns’s picture

Here's a patch which in addition removes the reference to '_search_api_solr_autoload' from search_api_solr.install.

After applying this patch search_api_solr still won't install because it thinks SolrPHPLibrary is not installed -- something seems to be going wrong with the class autoloading in class_exists('Apache_Solr_Service').

dawehner’s picture

Status: Needs review » Needs work
+++ b/search_api_solr.moduleundefined
@@ -35,8 +28,8 @@ function _search_api_solr_solrphpclient_path() {
+      $dir =  $dir;

Review your own patch ... this line doesn't look correct.

becw’s picture

Status: Needs work » Needs review
FileSize
2.79 KB

I'm getting this problem, too. In some cases Sarnia tries to load entities from Solr before search_api_solr's hook_init() has run, so the Apache_Solr_Service class isn't available yet.

This solution or moving the spl_autoload_register() call to hook_boot() both work for me. Here's a version of the hook_registry_files_alter() patch from above, re-rolled without the extra $dir = $dir;.

becw’s picture

Title: Clearing cache results in fatal error » Clearing cache results in fatal error because autoloader isn't registered yet (patch)
Crell’s picture

The patch in #11 doesn't handle the installer properly. It's still trying to rely on a custom class loader.

The attached patch fixes that.

drunken monkey’s picture

Thanks for the help, everyone!
However, while the last patch looks pretty good (except for one typo, "Balaner.php") I don't really see the benefit of this approach compared to just using hook_boot(). Can someone explain why most here seemed to follow the more complicated route with hook_registry_files_alter()?

And could please some of the initial bug reporters test the attached two patches and see whether those solve their problems? (Both work fine for me on a "regular" install.) Thanks!

PS: Already spotted the not updated doc comment in the hook_boot() variant, that would be corrected before committing.

dawehner’s picture

The main reason for me to write the registry alter approach was that there is not additional autoloader required.
I'm not sure whether this is a bad thing for itself but at least this patch leads to a bit easier code in searchapi_solr.

cangeceiro’s picture

I am getting the following after updating to the latest version

Additional uncaught exception thrown while handling exception.

Original

Exception: SolrPhpClient library not found! Please follow the instructions in search_api_solr/INSTALL.txt for installing the Solr search module. in SearchApiSolrService->connect() (line 235 of /var/www/html/EDA/authoring_tools/sites/all/modules/search_api_solr/service.inc).

Additional

Exception: SolrPhpClient library not found! Please follow the instructions in search_api_solr/INSTALL.txt for installing the Solr search module. in SearchApiSolrService->connect() (line 235 of /var/www/html/EDA/authoring_tools/sites/all/modules/search_api_solr/service.inc).

appears to be related, but the patch in #14 didnt help.

drunken monkey’s picture

@ #15: I still think using an autoloader is the cleaner approach, and also the standard one in such cases. Or do you know modules in which this is done with directly altering the registry?

@ #16: Do you use Sarnia? Where did you put the SolrPhpClient library? From which version did you update?

Still waiting for reviews from the initial reporters …

sanduhrs’s picture

We are using the hook_registry_files_alter() variant of the patch in production.
All working seamlessly.

dawehner’s picture

@ #15: I still think using an autoloader is the cleaner approach, and also the standard one in such cases. Or do you know modules in which this is done with directly altering the registry?

The only example of usage of hook_registry_alter is ctools/panels which registers the plugins without the need to put them into the info file, but sure this is kind of a different example.

Lets go with the easier, so the hook_boot, approach.

drunken monkey’s picture

Lets go with the easier, so the hook_boot, approach.

So can you confirm this works as well?

Sorry this is still taking so long, but I don't want to commit this as long as no-one has really seen this working. And I also don't want an unnecessarily complex patch, modifying the registry directly, if this can just as easily be solved by a one-liner.

@ sanduhrs: Thanks for testing! Could you maybe also try the other patch?

Anonymous’s picture

I tried the hook_boot patch from #14 and it solved an issue I had.

I implemented a custom hook_update_N function to do some Search API Solr magic, using function search_api_track_item_delete(). Without the hook_boot patch it failed because it could not find the library. Using the hook_boot patch from #14 solved the issue and updates ran fine.

Thanks! It worked for me.

larowlan’s picture

The hook_boot patch did not work for me but the registry_alter one did.

Ben Howes’s picture

I've been wrestling with the overlay closing and redirecting when submitting a form and found the following error message in my nginx log: PHP Fatal error: Class 'Apache_Solr_Service' not found in /.../sites/all/modules/contrib/search_api_solr/solr_connection.inc on line 10", which only seems to happen on overlay pages.

The registry_alter patch fixed it for me, thanks!

phenaproxima’s picture

I used the patch in #13 and it worked beautifully for me. Thanks, Crell.

drunken monkey’s picture

Status: Needs review » Fixed

I guess this is fixed now with getting rid of the SolrPhpClient dependency?
Otherwise, please re-open.

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

Issue summary: View changes

added url to other issue