If the user get the error: "You must include at least one positive keyword with 3 characters or more."
Then if the user enters another search text that is bigger and press search then the user get the same error and it shows the previous search text.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | error.png | 5.62 KB | Munavijayalakshmi |
| #2 | form-error-cant-submit-again-2250105-2.patch | 1.53 KB | yingtho |
Comments
Comment #1
yingtho commentedComment #2
yingtho commentedSee attached patch to fix it. It properly could be done more correctly but at the moment I can't see a better way.
Comment #3
yingtho commentedChange status.
Comment #4
jdanthinne commentedPatch seems ok, but I'd like to find where does this bug comes from at the first place… Are you using the default search block, or a custom block?
Comment #5
yingtho commentedI'm using the default custom search block from custom search block module. (I have only one block)
Comment #6
markgifford commentedJust chiming in to say I can't reproduce this error with a custom search block - Custom Search 1.16, core 7.27.
When I type two characters in the search field, hit enter and I get the "You must include at least one positive keyword with 3 characters or more" message. Add a couple of characters so the search term is at least 3, hit enter, and I just get no results, no warning message as expected.
Comment #7
yingtho commentedDo you have translation enabled and multilingual content when you test?
Comment #8
markgifford commented@yingtho: no, neither
Comment #9
rebecca904 commentedThis patch works well for me to clear the error message of the keyword limits. Thanks, yingtho.
The search form on the result page is the default search not the custom search, if you enter more than 3 characters, it will get no warning message. But if you write a new custom search form on the result page by yourself, it will need you to clear the error message first and then to work.
Comment #10
rebecca904 commentedThe $language in the patch is not enough, it only gets the current language. We should consider if "current language and language neutral" is selected in "Search content from".
I changed as below:
// Add language if custom search i18n is included.
if (module_exists('custom_search_i18n'))
{
$i18n_search_language = variable_get('custom_search_i18n_search_language', 'all');
if ($i18n_search_language == 'current') {
$keys = search_expression_insert($keys, 'language', i18n_language()->language);
}
elseif ($i18n_search_language == 'current_neutral') {
$keys = search_expression_insert($keys, 'language', i18n_language()->language . ',und');
}
$q[count($q) - 1] .= $keys;
}
Comment #11
Munavijayalakshmi commentedError in the posted image is not coming after applying the patch. Patch is working fine, moving to RTBC.
Comment #12
Munavijayalakshmi commentedComment #13
loon commentedD7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.
Everyone can apply the patch above (tested by the community) to their D7 projects.
If the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.
Thanks!