πŸ‡ΊπŸ‡ΈUnited States @daniel_j

Account created on 7 October 2010, over 13 years ago
#

Recent comments

πŸ‡ΊπŸ‡ΈUnited States daniel_j

Fully 11.x compatible in release 1.0.0.

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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.

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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.

πŸ‡ΊπŸ‡ΈUnited States daniel_j
$ 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 }

.

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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

πŸ‡ΊπŸ‡ΈUnited States daniel_j

@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.

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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.

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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.

πŸ‡ΊπŸ‡ΈUnited States daniel_j

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

πŸ‡ΊπŸ‡ΈUnited States daniel_j

Fixed one more D10 incompatibility.

Production build 0.69.0 2024