Store SolrPhpClient in Libraries folder

Yes, that would probably be a better option. I thought so as soon as I saw that some modules use that folder (unfortunately that was after creating the whole Solr backend the wrong way).
I don't really know how to do this the "right" way, and also couldn't really find any information regarding that. Could you maybe point me in the right direction, or give a quick summary? Or, of course, create a patch yourself, if you are up to it. ;)

However, I also feel that another solution might be to just dump the whole library altogether and code my own Solr connection classes. As I had to hack about half of the SolrPhpClient anyways, and could just insert the other bits into my classes as well, this would also solve the issue and make the module considerably easier to use …

In any case, this will take some time. So if it's urgent for you, either try to fix this yourself or use the workaround of replacing the SolPhpClient files for the apachesolr module with empty ones – through the autoload functionality, the classes will still be available for the apachesolr module.

I'd just leave it open for now, until the library either was moved to the right place (and included the right way) or has become obsolete.

Any progress on this?

Drush deletes all the files in a modules directory when updating modules. It's not too much work restoring (git checkout) the SolrPhpClient-directory after updating the module through drush, but it's an added risk of something failing in the process.

Sorry, not really. This isn't very urgent, and also hasn't had much attention regarding subscribers, so I've had my hands full with various other issues.
If you know how to do this properly, or could find it out for me, we could probably get things going, though.

+1.. Just installed the Apache SOLR and almost forgot about all the features that the search api offers.....
Reducing these barriers to use makes search api with solr more enticing.

I know that the suckerfish module uses the libraries API, but that is all I know in this regard atm. Perhaps an easy way to figure it out is to look at suckerfish.

Attached patch adds an autoloader to the search_api_solr module. It takes care of looking for the path, for now it checks first for the library in the module folder - I guess this is currently the most common use case. As soon as this changes we should check the library path first - this will bring a tiny performance gain ;).
Since the autoloaders are append this shouldn't have an impact on the performance on loading the other classes / interfaces.

+++ b/search_api_solr.module
@@ -1,6 +1,34 @@
+}
+spl_autoload_register('search_api_solr_autoloader');
+

Is this really how you add an autoloader, not using an init hook or something? Writing function calls directly in the .module files doesn't seem very clean to me.
Do you have some documentation or other examples for that?

Otherwise, looks good. Of course, we should then also remove the SolrPhpClient files from the .info file, and update the INSTALL.txt accordingly.

The core registers its autoloaders in _drupal_bootstrap_database(). And as far as I know there's no common way how to register autoloaders.
I've moved the autoloader registration into search_api_solr_init() and it seems to work. Currently I can't think of a scenario where this would fail - the only critical thing could be cache relevant stuff. Any ideas / concerns?

INSTALL.txt and search_api_solr.info are changed too.

The attached patch contains some clean-up, but otherwise this looks fine to me.
Anyone else can test and confirm this works?

A minor flaw is that you still can't put the library in site/[SITE]/libraries, but I guess, unless we want to switch to the Libraries API, it's better this way.
Or, how do you find out whether there's a site-specific directory, does anyone here know?

Ah, damn, forgot to actually attach the patch! Could you please test this one, too? If it works for both you and Peter, I think we can savely commit it. Is about time, more than half a year after the issue was created …

Thumbs up, it works for me too. I actually don't mind Libraries API, should be a core feature to my opinion.

I agree – but as long as it isn't, I rather hesitate to add another contrib project as a dependency.

Committed, thanks!

I forgot to change the implementation of hook_requirements().
Attached patch fixes that - the code now relies on _search_api_solr_autoload().
I've added some special code for the install phase - but I'm not sure if the runtime phase needs this code too.

Just struggled over another issue on install - patch in progress...

Install worked fine now with attached patch.
It seems that search_api_solr_init() isn't called during the whole installation.

Ah, good catch! Committed, thanks!

Works perfectly. Tested on two different sites with Library API and client files moved to the libraries folder. Thanks a bunch. SAPI is really an amazing piece of work.

@jpeu: I'd suggest you take a look into the INSTALL.txt - The section "Download Solr PHP client" describes where the library has to be placed.
For further support a more detailed description of your environment would be necessary - besides that for such a support request a dedicated ticket would be the right place.

+++ b/search_api_solr.module
@@ -1,4 +1,45 @@
+  static $path, $lookup_cache = array();

why the static cache? The autoload functions are only called if a class hasn't been loaded, so what's the point?

+++ b/search_api_solr.module
@@ -1,4 +1,45 @@
+      require_once $file_path;

why "require_once" and not just "require"? If one file only contains one class and the autoloader is called we can be sure it has never been included before.

As core's _registry_check_code() does it the same way, in both cases, I think this can be considered kind of a „best practice“ here. And better safe than sorry, right?
I know, Rasmus Lerdorf would disagree, but in the end the performance cost of both is negligible.