🇺🇸United States @daniel_j

Duplicate of #3469827

Thanks, fixed in 1.0.4.

Fixed in 8.x-1.x-dev

Fully 11.x compatible in release 1.0.0.

Fixed in release 1.0.3

Fixed in release 1.0.3

I believe this should be resolved in release 1.0.3, which reports on blocks embedded via the block_field and layout_builder modules.

This appears to be a shortcoming of OpenSearch itself, not the Drupal module. Perhaps in the short term it would be advisable to hide type-specific boosting when OpenSearch is the SearchAPI backend.

It may be possible to code a workaround for OpenSearch 2.9 or higher, using script score queries. This would involve adding a numeric field to the index, and then using its value as a multiplier.

daniel_j → created an issue.

daniel_j → made their first commit to this issue’s fork.

Re-rolled the patch in #14 to apply cleanly to 1.x-dev

The failure reported in #3 is entirely unrelated to this issue.

daniel_j → created an issue.

So, to flog a dead horse, the syntax currently in search_api_opensearch.services.yml is supported by Symfony 6, which D10 ships with, but not by Symfony 4, which D9 ships with.

$ drush en --yes search_api_opensearch
The following module(s) will be enabled: search_api_opensearch, search_api

 // Do you want to continue?: yes.                                                                                      

In YamlFileLoader.php line 293:
                                                                                                                                                                        
  A "tags" entry must be an array for service "search_api_opensearch.synonyms_subscriber" in modules/contrib/search_api_opensearch/search_api_opensearch.services.yml.  
   Check your YAML syntax.

This is occurring on a Drupal 9.4 install. I did not see this error in Drupal 10. But for backwards compatibility, the entry should be

tags:
  - { name: event_subscriber }

.

Fixed in version 1.0.2

Bah, the last patch had a careless bug in it.

@kim.pepper: If you are willing to reconsider, this patch allows configuring the logging threshold for the OpenSearch client.

This patch also solves one additional problem. Drupal's logger instances expect the keys of the $context array to be prefixed placeholders which are also present in the $message. PSR-3 makes no such requirements, and therefore the OpenSearch client places vital pieces of debug information in the $context without adding placeholders for them. This custom LoggerChannel implementation prefixes the context keys with '@' and adds them to the $message to be logged.

Without this last detail, the debug messages generated by the OpenSearch client are almost entirely useless.

Here's a LoggerChannel subclass that I wrote a couple weeks ago to for this. It drops all INFO and DEBUG logs.

namespace Drupal\opensearch_log_silencer;

use Drupal\Core\Logger\LoggerChannel;
use Drupal\Core\Logger\RfcLogLevel;

/**
 * Logger to drop all INFO and DEBUG entries.
 */
class NoDebugLogger extends LoggerChannel {

  /**
   * {@inheritdoc}
   */
  public function log($level, $message, array $context = []) {
    if (is_string($level)) {
      // Convert to integer equivalent for consistency with RFC 5424.
      $level = $this->levelTranslation[$level];
    }
    // Drop all levels less severe than NOTICE. This currently means no INFO or
    // DEBUG log entries.
    if ($level > RfcLogLevel::NOTICE) {
      return;
    }
    parent::log($level, $message, $context);
  }

}

It would be nice if something like this were integrated into the module.

The attached patch fixes the .info.yml file, as well as updating Twig syntax. Since the "apply" keyword was added in Twig 2.9, and Drupal 8 shipped with Twig 1.x, this means we need to drop D8 support. Drupal 9.0.0 required a minimum Twig of 2.12.5, so we should be good requiring any D9 or D10 version.

daniel_j → created an issue.

Re-rolled patch to apply to 2.0.0-beta3

Fixed in 2.0.0-beta3

Fixed in 2.0.0-beta3.

@quietone I have updated the CR to address your concerns.

Fixed one more D10 incompatibility.