Persistent Issue: Diacritics Ignored in Exact Search on AtoM 2.9.1 (Potential Override in arSearchQueryString.class.php)

[Rodolfo Peres Rodrigues]

Hello everyone,

I'm encountering a persistent issue on AtoM 2.9.1 (using Elasticsearch 5.x/6.x) where the exact search (after hitting Enter) fails to normalize diacritics, requiring users to type the exact accent to find a result (e.g., searching for "cafe" fails, but "café" works). The autocomplete suggestions, however, work correctly, indicating that the problem is specific to the Search Time query processing, not the Index Time.

I have implemented comprehensive fixes, including:

1. Complete Analyzer Configuration: The brazilian analyzer has been fully configured in search.yml with lowercase, brazilian_stop, preserved_asciifolding, and brazilian_stem.

2. Explicit Field Mapping: The field_map: section is correctly set to use analyzer: brazilian and, crucially, search_analyzer: brazilian for full_text, title, and name.

3. Reindexation: The search index has been rebuilt multiple times (php symfony search:populate).

The Code Override Hypothesis

The failure persists despite the correct Elasticsearch configuration, which strongly suggests that the AtoM application code is overriding the search_analyzer when building the final query_string.

My proposed solution/question is: Should we be explicitly forcing the analyzer on the query construction level?

Suggested Action: Inject the analyzer parameter into the array that builds the Elasticsearch query_string (likely within plugins/arElasticSearchPlugin/lib/model/search/arSearchQueryString.class.php).

Example of parameter injection:

$params = array( 
  'default_operator' => $this->getDefaultOperator(), 
  'analyzer' => 'brazilian', // FORCE THE ANALYZER HERE 

);

I would appreciate guidance from the community: Is this the recommended fix, or is there a known configuration flag or bug that is causing the search_analyzer defined in search.yml to be ignored in this specific AtoM version?

Thank you for your assistance.

Sincerely,
Rodolfo Peres Rodrigues