Alter minimum length field to handle total character count instead of individual word count

Created on 14 October 2024, 2 months ago

Problem/Motivation

The minimum keyword length is causing validation to fail for compound words and proper nouns.

Steps to reproduce

- Configure /search view and add value for minimum keyword length e.g 3
- Go to search and enter a keyword that satisfies the minimum keyword length e.g St john
- See that an error is thrown 'You must include at least one keyword to match in the content, and punctuation is ignored.'

Proposed resolution

Alter the SearchApiFullText validation to validate the entire input length instead of validating the individual word length.
This change will allow the minimum keyword length to be honoured whilst also allowing compound words and proper nouns to be used in the search.

Remaining tasks

- Make this configurable to allow both options.

Feature request
Status

Active

Version

1.0

Component

General code

Created by

🇬🇧United Kingdom sabrina.liman

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @sabrina.liman
  • 🇦🇹Austria drunken monkey Vienna, Austria

    drunken monkey made their first commit to this issue’s fork.

  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for reporting this issue!

    However, I think the “minimum word length” option already works exactly as you describe: For minimum length 3 and input “st john” it will discard the “st” but keep “john” and not display any error message. The message will only be displayed if all words were removed that way (which makes sense since then the user will just see completely unrelated items from the index).

    I think what might be happening is that you’re using Search API Autocomplete and, while you type, Javascript sent a request with just “st” as the keywords. The way Autocomplete works internally it seems like this would also trigger the form validation and even, confusingly, display the resulting error message on the next page load.
    To check this, you can use XDebug to place a breakpoint on the relevant (i.e., second) $form_state->setErrorByName() call in SearchApiFulltext::validateExposed() and then see when that gets triggered.

    If this is indeed the cause of the problem for you, this would be a bug report for the Search API Autocomplete module. Feel free to move it accordingly. it does seem like a bad idea to display Views exposed form validation errors triggered during autocompletion. We might just want to call \Drupal::messenger()->deleteAll() after $view->build() in \Drupal\search_api_autocomplete\Plugin\search_api_autocomplete\search\Views::createQuery().

Production build 0.71.5 2024