Block search form action is incorrect for searching (w/ suggested fix) [#1595254]

This issue has been intermittent. Every once in a while the block search form stops working. From the end user standpoint, no matter what term is entered, clicking on the Search button results in a seemingly random page from the site. For example, you're on the home page, you enter "hospitals" in the search box expecting a search results page, but end up at an article page that has nothing to do with hospitals.

Once the bug occurs it is persistent until cache is cleared (multiple times). When it's happening, the same form action uri, and thus the same result page, is seen across multiple pages, users and machines. The behavior can be different for anonymous users vs. authenticated.

The attached screenshot shows firebug displaying the bogus search URI.

I see in the .module that the first thing done upon form submission is unsetting any destination. Could it be that this is still the D6 way of doing things?

function google_appliance_block_form_submit($form, &$form_state) {
                          
  // kill any dynamic destinations, as the results page is always the destination
  if (isset($_GET['destination'])) {
    unset($_GET['destination']);
  }

I've seen a blog post that says drupal_static_reset may be necessary (and maybe drupal_get_destination, too?):

  unset($_GET['destination']);
  drupal_static_reset('drupal_get_destination');
  drupal_get_destination();

But that's only a guess. Hope it helps.

Comment	File	Size	Author
#5	google_appliance_remove_search_block_caching-1595254-5.patch	441 bytes	mpgeek
#5
#4	google_appliance_remove_search_block_caching-1595254-1.patch	441 bytes	mpgeek
#4
#1	google_appliance_remove_search_block_caching-1595254-1.patch	441 bytes	mpgeek
#1
	google appliance form has bogus action uri.png	365.73 KB	rt_davies

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

mpgeek CreditAttribution: mpgeek commented 6 June 2012 at 17:53

Assigned:

Unassigned

» mpgeek

File	Size
google_appliance_remove_search_block_caching-1595254-1.patch	441 bytes

The desired behavior for that form action attribute is that it always points to the current page. The fact that you see a bogus form action across multiple pages, users, and machines makes me think this is a caching problem (if the block got cached via a request from a different page than you are currently on, you would get the wrong uri in the form action). Disabling block caching on /admin/config/development/performance seems to help, but i think that is a bunk solution.

The better way, i think is to set the block search form to DRUPAL_NO_CACHE. A patch for that is attached. Please do post back here and let us know if this helps.

Comment #2

mpgeek CreditAttribution: mpgeek commented 6 June 2012 at 18:17

@rt_davies: also note that if you are caching pages for anonymous, neither the block cache setting, nor asking Drupal not to cache the block, have a real effect.

Comment #3

iamEAP CreditAttribution: iamEAP commented 6 June 2012 at 20:52

Something wonky happened with your patch in #1, mpgeek. It's removing something that doesn't exist and replacing it with what's already there.

That being said, I'm not sure the form cache setting is going to have much of an effect. The dynamic destination is being stripped in a submit handler. I think rt_davies' code may be the right way to do it. Unsetting the destination may just not be enough.

Something else to investigate, rt_davies, is to make sure you don't have any rogue submit handlers on this form that are being called after this module's that are doing additional redirecting. I know I'm doing this intentionally on my installation, but it's possible one of yours may have snuck in.

Comment #4

mpgeek CreditAttribution: mpgeek commented 6 June 2012 at 21:25

File	Size
google_appliance_remove_search_block_caching-1595254-1.patch	441 bytes

@iamEAP, yep, i botched that patch.... diff'd backwards. New one is attached. I would agree that the form cache setting in the module doesn't have that much of an effect, and it really depends upon the overall caching scheme and what gets cached when and where. In my use case, turning off block caching either via admin settings for all blocks or using the patch, makes the wrong-uri problem go away, along with my Varnish 'form outdated' problems.

I thought following how core search sets up it's search block was a good idea, so i guess the patch is more for posterity and completeness. But it'd be interesting to find out how it affects @rt_davies problem.