Add an option to deactivate the site hash filter

Is this patch waiting to be tested, before it can be commited?

I can confirm that the patch works as designed, thank you @drunken monkey.

Well, I don't know the module too well either but seems like the other maintainers are missing in action :)

Patch looks fine to me and works, according to #7. Thanks for the patch and testing. Committed.

Thanks @Berdir! I can't see the code in the latest dev-version 8.x-1.0-alpha1+7-dev from 2016-01-06 though...

Uh, indeed, sorry about that. I guess I forgot to push or so.

Unfortunately, the patch doesn't apply anymore.

I am confirming "the patch doesn't apply anymore.". Not sure what action item pending in this ticket.

It needs a reroll I think.

I tried updating the single line that is different, which changed in this patch: http://cgit.drupalcode.org/search_api_solr/commit/?id=c717068

@@ -1110,7 +1104,7 @@ class SearchApiSolrBackend extends BackendPluginBase {
   protected function extractResults(QueryInterface $query, Result $result) {
     $index = $query->getIndex();
     $field_names = $this->getFieldNames($index);
-    $field_options = $index->getOption('fields', array());
+    $fields = $index->getFields();

I have attached the patch, feel free to test it.

@drunken monkey: I can confirm that the patch in post #13 applies cleanly to the latest dev-version 8.x-1.0-alpha1+8-dev:

$ cd ../Desktop/search_api_solr/
$ wget https://www.drupal.org/files/issues/2596421-13--optional_site_hash_filter.patch
$ git apply -v 2596421-13--optional_site_hash_filter.patch
Checking patch README.txt...
Checking patch config/schema/search_api_solr.backend.schema.yml...
Checking patch src/Plugin/search_api/backend/SearchApiSolrBackend.php...
Hunk #1 succeeded at 171 (offset 2 lines).
Hunk #2 succeeded at 190 (offset 2 lines).
Hunk #3 succeeded at 303 (offset 2 lines).
Hunk #4 succeeded at 557 (offset 6 lines).
Hunk #5 succeeded at 671 (offset 8 lines).
Hunk #6 succeeded at 722 (offset 7 lines).
Hunk #7 succeeded at 767 (offset 7 lines).
Hunk #8 succeeded at 919 (offset 9 lines).
Hunk #9 succeeded at 960 (offset 1 line).
Hunk #10 succeeded at 1065 (offset 1 line).
Hunk #11 succeeded at 1112 (offset 4 lines).
Hunk #12 succeeded at 1529 (offset 6 lines).
Checking patch src/Utility/Utility.php...
Hunk #1 succeeded at 174 (offset 1 line).
Checking patch tests/modules/search_api_test_solr/config/install/search_api.server.solr_search_server.yml...
Applied patch README.txt cleanly.
Applied patch config/schema/search_api_solr.backend.schema.yml cleanly.
Applied patch src/Plugin/search_api/backend/SearchApiSolrBackend.php cleanly.
Applied patch src/Utility/Utility.php cleanly.
Applied patch tests/modules/search_api_test_solr/config/install/search_api.server.solr_search_server.yml cleanly.

I think what he meant is if it actually works :)

You are probably right :-) And unfortunately it doesn't - I get a "Server error 500" if I try to perform a search, and in the logs it says:

RuntimeException: Autoloader not found: modules/search_api_solr/vendor/autoload.php in Drupal\search_api_solr\EventSubscriber\AutoloaderSubscriber->registerAutoloader() (line 63 of /var/www/html/website.local/public_html/modules/search_api_solr/src/EventSubscriber/AutoloaderSubscriber.php).

My set up:

• Drupal core 8.0.2
• Admin Toolbar 8.x-1.11
• Search API 8.x-1.0-alpha9+34-dev (2015-nov-24)
• Search API pages 8.x-1.0-alpha6
• Search API Solr Search 8.x-1.0-alpha1+8-dev (2016-jan-08)

I updated to latest dev-version of Search API, and am still getting the "Server 500" error, but no longer the Autoloader error. In stead I get this in the logs:

Notice: Undefined index: entity:node/body in Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend->search() (line 740 of /var/www/html/webiste.local/public_html/modules/search_api_solr/src/Plugin/search_api/backend/SearchApiSolrBackend.php).

Updated set up:

• Drupal core 8.0.2
• Admin Toolbar 8.x-1.11
• Search API 8.x-1.0-alpha11+23-dev (2016-jan-12)
• Search API pages 8.x-1.0-alpha6
• Search API Solr Search 8.x-1.0-alpha1+8-dev (2016-jan-08)

I'm not sure if search_api already made changes again. Try to use the alpha version. And if that works, open a new issue to fix compatibility (again ;)).

Thanks @Berdir, I'll try with the Search API alpha version, and report back. I just need to restore my dev-site first, the field-definitions of my Solr index got lost somehow, which probably explains the Notice: Undefined index: entity:node/body.

All fields and processors are removed after I upgrade Search API from 8.x-1.0-alpha9+34-dev to 8.x-1.0-alpha11:

$ drush @website_dev up search_api

Update information last refreshed: fre, 01/15/2016 - 14:35
 Name                     Installed Version      Proposed version  Message                
 Search API (search_api)  8.x-1.0-alpha9+34-dev  8.x-1.0-alpha11   Update available 

Code updates will be made to the following projects: Search API [search_api-8.x-1.0-alpha11]

The pages admin/config/search/search-api/index/index/fields and admin/config/search/search-api/index/index/processors are now empty.

Yes, fields and processors moved out of options into their own top-level elements.

Search API has no upgrade path yet. So you're on your own when updating. It would be better to test this patch on a new installation to avoid issues that are actually upgrade problems.

Thanks for the feedback from both of you.

I updated to the latest dev-version of Search API and Search API Solr, and applied the patch in #13 cleanly to Search API Solr. Subsequent tests went fine, and items were indexed to a shared Solr index.

I am having trouble getting a View to work afterwards though, and can't get an exposed filter to show up ... But that's probably another story. I get an "Server Error 500" and this in the log: PHP Fatal error: Cannot access empty property in /data/www/dev.example.org/core/modules/views/src/ResultRow.php on line 44, referer: http://dev.example.org/

By the way, I like the new way of selecting fields for the index, it's easier to quickly see which fields are activated.

Yeah, pretty sure that's a separate issue. Committed.