If a user puts a forward slash in the search box, then it affects the form redirect url.

Apachesolr module solves this in its apachesolr_search_form_search_submit() function. Can this same fix be applied to the custom search module custom_search_submit() function?

$keys = str_replace('/', '%2f', $keys);

Will supply a patch.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

johnennew’s picture

Status: Active » Needs review
FileSize
549 bytes

Patch supplied for review. Note after submission of a search containing a slash, the slash is replaced by %2F. This could be solved at the theme layer. I did the following in a custom theme function.

function MYTHEME_preprocess_search_block_form(&$variables) {
  $variables['form']['search_block_form']['#default_value'] = str_replace('%2f', '/', $variables['form']['search_block_form']['#default_value']);
  $variables['form']['search_block_form']['#value'] = str_replace('%2f', '/', $variables['form']['search_block_form']['#value']);
  template_preprocess_search_block_form($variables);
}
jdanthinne’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

uzuri’s picture

Hmm... I applied the patch and it still doesn't seem to be willing to handle a search like:

someword site:www.seas.harvard.edu/directory

(very useful if you're using GSS)

It's truncating the / and everything after it rather than encoding it.

jdanthinne’s picture

I've just reverted the changes in the dev version: http://drupalcode.org/project/custom_search.git/commit/4b8c914.
With this reverted, the search works as the core search.

uzuri’s picture

Just tried the latest dev and it's still truncating -- works find in the main search box, but doesn't work in a block. If you want to see what it's doing to me, you can have a look at http://seasdev.prod.acquia-sites.com/ The custom search block is the one up in the right corner, of course -- try either a someword site:www.seas.harvard.edu/directory or someword with the "People" button checked, they should bot end up at the same place and you'll see what's happening.

This is with Drupal 7 core up to date and right now I've got the latest dev version of Custom Search/Custom Search Blocks running on that site. Behaves exactly the same whether the patch is applied or not.

The regular searchbox happily takes a someword site:www.seas.harvard.edu/directory search without eating it. I tried to trace out where the truncation is occurring, but only got so far as to be able to tell that $form_state['redirect'] is what you'd expect it to be at the end of custom_search_submit. I don't quite know enough about the order things fire to know what might be manipulating it after that.

Edit: My example's no longer current as I turned off Custom Search and wrote a couple-line module to do what I needed for myself. Definitely was a problem w/ CSB, though -- I thought I might be able to get away with doing my manipulation of the search key and letting CSB do the rest, but when I turned CSB back on, it ate the /directory again. So I guess since I was only using a tiny bit of CSB's powers, I'll still with the hand-built module for the moment, but I will be keeping an eye on this project to see if you find out what was happening.