Boost by content type

I do think that would be a nice addition to the module, thanks a lot for posting it! People have frequently requested this feature, and with D8 it's now much easier to implement than before, so adding this processor makes a lot of sense.

However, there's still a lot of work to do before we can add this:

• This needs tests (both a unit test and an addition to ProcessorIntegrationTest) and a schema config.
• Instead of restricting to entities, we should just configure based on datasource and use their bundles (and bundle detection mechanism).
• Why would you want to exclude the default boost? That doesn't really make sense, since people can't force the setting to NULL.
• There are also some code style issues.
• Not an issue per se, but we generally use snake_case for variables in this module, and I think it would be better to stick to that.

There's also: https://www.drupal.org/project/search_api_bundle_boost not sure if we should look at that code as well as the provided patch?

Yeah, I agree it would be nice to get that in search api. We should probably open an issue in that module's queue with a request to do exactly that and link to this issue? Not sure how @drunken monkey usually handles this situation.

Yeah, I agree it would be nice to get that in search api. We should probably open an issue in that module's queue with a request to do exactly that and link to this issue? Not sure how @drunken monkey usually handles this situation.

Sure, makes sense. Thanks a lot for finding that other module! (Hard/Impossible to keep track of all of them.)
In any case, the requirements for inclusion are the same no matter where the processor comes from, but the version from the other module probably has a better chance of being stable.

I've recently build something similar to #1, however we had the need to boost on entity type level and in certain cases change the boost per bundle.

• Boosts can be set for an entity type.
• The global entity boost can be overwritten on bundle level if required (only if supported).
• Includes a schema configuration.
• Includes a ProcessorIntegrationTest.

The available entity types/bundles to set the boosts on are taken from the datasource.

This probably needs some polishing, but I think that it covers most of the points raised in #4.

I've started work for an EntityBundleBoostTest, but can't really figure out how to retrieve the item that is created to test that the boost is actually applied. Someone with a suggestion for that?

I think https://www.drupal.org/project/search_api_sort_priority could also be a solution for this.

Shit, stupid d.o site logged me out while I was writing and ate my comment. x___x

Short version: Sort Priority does sorting, while this does boosting, which are different use cases, I'd say. (And they require quite different code, so separating them does make sense at least code-wise.)

Also, this is a pretty good patch already, so thanks a lot for that! However, when applying I get: "error: corrupt patch at line 345". So also couldn't do a more detailed review yet.

For the test: With the test backend, you have several ways to get the indexed items: either from the search_api_test.backend.method_arguments.indexItems key in the site state, or by overriding the indexItems() method.
See: \Drupal\search_api_test\Plugin\search_api\backend\TestBackend::indexItems(), \Drupal\search_api_test\TestPluginTrait::logMethodCall(), \Drupal\Tests\search_api\Functional\ConfigOverrideIntegrationTest::testConfigOverrideIntegration().

Okay, thanks. I'll see when I've got some time to look at this, the code in this patch has been pulled out from some internal modules so might have made a mistake generating the patch.

I'll see whether I can figure out the test.

As a side note, in order for the patch in #9 to work when you use the solr backend you'll also need #2850160: Document level boost value not inherited from Search API item.

Unfortunately I haven't had time to look into the tests yet, but was also running into the patch apply issue so recreated the patch against the 8.x-1.x HEAD. Should apply cleanly now.

Thanks, applies fine now!
As said already, looks pretty good so far – thanks again!
However, the code was a bit complicated in some parts, should also use the datasource, not the entity type, as base setting (we have everything we need in the datasource, why make it more specific?) and you also used some PHP 7-specific functionality which we unfortunately can't use yet.
I also renamed the processor to "Type-specific boosting" (type_boost).

Please test/review and tell me if you have any issues!
And yes, would be great if you could still get those tests running!

#2850160: Document level boost value not inherited from Search API item is a blocker for this to work with Solr without implementing hook_search_api_solr_documents_alter().

I have been doing some testing and updated the patch in #14 with the following changes:

• A minor fix to the default value in the processor plugin form.
• Rewrite of testEntityBundleBoost().

Missed the changes in processor integration test. Rerolled the patch with a fix to this test case.

Rerolled the patch without the devel module requirement in TypeBoostTest. Not sure why it was there....

Great job, thanks a lot for that!
Seems completely fine now. Just had to remove one unused import and then committed.
Thanks again, everyone!

I have updated the Search API Bundle Boost project page with info about the new processor plugin in Search API core. After the next Search API minor release which includes the Type Boost functionality, will I mark the Bundle Boost project as unsupported.

Any chance of a backport to D7?

This is not really possible to do in Search API on drupal 7. It is possible in solr, but we don't have the needed hooks in place to do this with the database backend. At least - that's how I understand it. I recently had to do this on a custom project and ended up creating this entirely in solr code.