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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

YesCT’s picture

Here 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

<form id="search-block-form" class="search-block-form search-box" accept-charset="UTF-8" method="post" action="/d8-git/search/node/658578658765786">

but what we probably want is

<form id="search-block-form" class="search-block-form search-box" accept-charset="UTF-8" method="post" action="/d8-git/search/node">

But if the search block is on another page, we in fact do want

<form id="search-block-form" class="search-block-form search-box" accept-charset="UTF-8" method="post" action="/d8-git/search/node/658578658765786">

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

julien’s picture

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

julien’s picture

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

julien’s picture

Status: Active » Needs review
julien’s picture

recoded with wrapper_callback on hook_forms instead.

julien’s picture

Gábor Hojtsy’s picture

I vaguely remember we fixed this years ago in Drupal 6(?). Surprised it regressed... :/

larowlan’s picture

Issue tags: +Needs tests

Based on Gåbor's comments

jhodgdon’s picture

Status: Needs review » Closed (duplicate)

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

jhodgdon’s picture

Issue summary: View changes

Updated issue summary. to note there might be performance implications

jhodgdon’s picture