Type boosting no longer works with Search API 4.3.x

We have test coverage for boosting and sort by relevance.
And some bigger installations run on the 4.3.0 code base since two more than a month without such issues.

But it is essential that you re-create the core (or the collection in case of Solr Cloud) using the configsset.

This module needs to implement EventSubscribers instead of hooks. These will work with 4.2 and 4.3.

I followed the instructions in this guide page → to move the logic into an EventSubscriber, and also added a composer.json file to specify the version of search_api_solr that is needed.

I haven't actually had a chance to test this yet, so any feedback is appreciated.

Thanks for the analysis and the patch, which unfortunately does not quite work for me yet. My setup looks like this: Drupal 10.1.4, Search API 4.3.x, PHP 8.1.x, nginx. The patch is applied cleanly, however after reindexing the index, the search results (filtered by relevance) are not output, which are configured with Search Overrides.

In detail, when viewing and e.g. a cache clear via drush cr, the following error message comes up, this actually only occurs when the patch is applied. Without the patch, everything works normally, except for the search overrides of course. It is true that I did not test it with a fresh installation, but directly in my project to have some database and simulate the productive environment.

In CheckDefinitionValidityPass.php line 61:

  The definition for "tags" has no class. If you intend to inject this service dynamically at runtime, please mark it as synthetic=true. If this is an abstract definition solely used by child definitions, please add abstract=true, otherwise specify a class to get rid of this error.

Symfony\Component\DependencyInjection\Exception\RuntimeException: The definition for "tags" has no class. If you intend to inject this service dynamically at runtime, please mark it as synthetic=true. If this is an abstract definition solely used by child definitions, please add abstract=true, otherwise specify a class to get rid of this error. in Symfony\Component\DependencyInjection\Compiler\CheckDefinitionValidityPass->process() (line 61 of /var/www/html/vendor/symfony/dependency-injection/Compiler/CheckDefinitionValidityPass.php).
Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object) (Line: 767)
Symfony\Component\DependencyInjection\ContainerBuilder->compile() (Line: 1335)
Drupal\Core\DrupalKernel->compileContainer() (Line: 934)
Drupal\Core\DrupalKernel->initializeContainer() (Line: 1186)
Drupal\Core\DrupalKernel->rebuildContainer() (Line: 503)
drupal_flush_all_caches() (Line: 205)
Drupal\admin_toolbar_tools\Controller\ToolbarController->flushAll()
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 592)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 182)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 49)
Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Apologies for that. Looks like it was a YAML problem in the services.yml file. Please try it again.

Thanks for the update: yes, looks good now, no errors, the results on production with Search API 4.2.x resemble the Search API 4.3.x with the patch. Everything seems to work fine.

So from my side gladly a RTBC++

Great! Merged this in, and will roll a new release shortly.

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