While testing #511594-49: hook_search_preprocess needs to be language-specific we found, by looking at dpm triggered in the function custom_search_preprocess() and logged in the watchdog, that search would search for the previous search (it's stored in the url) and what the new search term was in the search block.
There might be performance implications in that if this is fixed, some searches will be faster (by half?)
This might be related to this 6.x Solr issue #1481326: Queries run twice after submitting search forms on a custom search page
and might be related to this old support request from 2008 that had no resolution http://drupal.org/node/103909 (Strange Search block behavior - have to type search twice to work).
Comments
Comment #1
YesCT CreditAttribution: YesCT commentedHere are my notes from debugging that lead to noticing this problem.
why it it looking for "hello" when just search for "something"?
its a search problem, not a d8mi problem
investigate by:
clear watchdog
search for "word"
ok
search for "differentword"
watchdog sees "word" and "differentword"
if search box on search result page
form action is
but what we probably want is
But if the search block is on another page, we in fact do want
The menu callback handler for /search/node/foo should check if the POST contains
form_id=search_block_form
if yes it should prevent a search being made for 'foo' before it actually searches for the string in the POST (which comes from the block).
So if have done
/search/node/foo
and the search being done is in the block search for "bar",
then both a search for "foo" and "bar" happen (see in the watchdog).
The ui looks fine though, the block term is moved to the advanced search form, and the url of the page changes ok to /search/node/bar
This might be related to this 6.x Solr issue #1481326: Queries run twice after submitting search forms on a custom search page
and might be related to this old support request from 2008 that had no resolution http://drupal.org/node/103909 (Strange Search block behavior - have to type search twice to work).
Comment #2
julien CreditAttribution: julien commentedIt seems that it's doing two queries only because after a search, the block form action is set to the current url which is already search/node/blah, so on submit it will search for blah and the keyword.
@YesCT, can you explain to me why we should keep action="/d8-git/search/node/658578658765786" on other pages than the page results, because the keyword is not even used inside the form itself, i think.
Comment #3
julien CreditAttribution: julien commentedHere is a quick patch that at least fix the twice (or more) query thingie. Still need work to keep the normal url if the block is not on the result page.
Comment #4
julien CreditAttribution: julien commentedComment #5
julien CreditAttribution: julien commentedrecoded with wrapper_callback on hook_forms instead.
Comment #6
julien CreditAttribution: julien commentedpatch update.
Comment #7
Gábor HojtsyI vaguely remember we fixed this years ago in Drupal 6(?). Surprised it regressed... :/
Comment #8
larowlanBased on Gåbor's comments
Comment #9
jhodgdonI believe this will be fixed when we resolve #894486: Use the query string for search keys rather than appending them to the URL, so I am adding it to that issue and marking this one as a duplicate.
Comment #9.0
jhodgdonUpdated issue summary. to note there might be performance implications
Comment #10
jhodgdonAs a note, in 8.x this is actually related to
#2174521: Page processing order: form submits vs. main page content is inefficient if form submit is a redirect