Answers.Body: <p>This can be reproduced on CiviCRM.org, which has both a search block and contribute pages.</p>
  
  <ol>
  <li>Go to <a href="https://civicrm.org/civicrm/contribute/transact?reset=1&amp;id=1&amp;action=preview" rel="nofollow noreferrer">https://civicrm.org/civicrm/contribute/transact?reset=1&amp;id=1&amp;action=preview</a></li>
  <li>Type "ponies" in the Drupal search box (top right)</li>
  <li>Hit <code>ENTER</code> and see fairly misleading error messages.</li>
  </ol>
  
  <p><a href="https://i.sstatic.net/5rBUB.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/5rBUB.png" alt="civicrm search error"></a></p>
  
  <p>I haven't looked into it in depth, but I'd <em>guess</em> something like this:</p>
  
  <ol>
  <li>Drupal's Block Search form uses the current page callback to submit its form to.</li>
  <li>CiviCRM intercepts form submissions to <code>/civicrm/*</code>, but can't handle form submissions in unexpected formats, so doesn't know what to do.</li>
  <li>Yellow Page of Malaise. (A play on WSoD here.)</li>
  </ol>
  
  <p>My suggested dodgy workarounds are:</p>
  
  <ul>
  <li>Add a form alter hook in CiviCRM, which identifies forms you use throughout the site and direct the form submit URLs elsewhere if the path contains <code>/civicrm</code>, OR</li>
  <li>Do not show those blocks on those paths at all.</li>
  </ul>
  
  <p>My wild clever idea solution is:</p>
  
  <ul>
  <li>Make CiviCRM return Fatal errors using Drupal page callback rather than bombing out to the YPoM. This might permit Drupal to then do whatever redirect happens as part of the normal flow for Drupal forms.</li>
  </ul>
  
  <p>My fantasy perfect solution is:</p>
  
  <ul>
  <li>Destroy all HTML QuickForm.</li>
  </ul>
  
  <p>This last is happening, albeit slowly. Please <a href="https://civicrm.org/participate/support-civicrm" rel="nofollow noreferrer">donate to CiviCRM</a>, avoid implementing new functionality in QuickForm, and support any efforts to remove QuickForm or improve the codebase which you are able to.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-07T00:42:49.857Z
Answers.LastActivityDate: 2015-09-07T00:42:49.857Z
Answers.UserDisplayName: Chris Burgess
Body: <p>Just spotted that if you have a Drupal search block on eg a Contribution page, and try to use it, it will either take you back in to CiviCRM with a qf key (back to the last thing i modified i think), and for logged out (non permissioned) users they get a long message ending with "Error type: Could not find a valid session key".
  How does a Drupal search trigger this outcome?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-08T19:07:39.683Z
Comments.Text: I have seen this due to an http vs. https conflict. Don't recall how it was resolved though...
Comments.UserDisplayName: Sonicthoughts
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-09T00:38:26.430Z
Comments.Text: thx - will check if the issue is only happening on https sites
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-10T02:28:42.057Z
Comments.Text: seeing this on sites without https too.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-07T00:52:32.557Z
Comments.Text: It's reproducible on CiviCRM.org, which suggests that it's not a misconfiguration.
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T19:21:48.873Z
Comments.Text: I know it is not explicitly related to https but when I recently enabled it on a site, this started happening again.  I tried changing everything to https AND base_url in drupal+civicrm and have not seen it since (but not holding my breath )
Comments.UserDisplayName: Sonicthoughts
Tags: <drupal><search>
Title: What sort of fix is needed to make Drupal Search work correctly on a civicrm page such as an Event or Contribution page
ThreadText: # What sort of fix is needed to make Drupal Search work correctly on a civicrm page such as an Event or Contribution page
  
  (Asked by: username_0 on 2015-07-08)
  
  Just spotted that if you have a Drupal search block on eg a Contribution page, and try to use it, it will either take you back in to CiviCRM with a qf key (back to the last thing i modified i think), and for logged out (non permissioned) users they get a long message ending with "Error type: Could not find a valid session key".
  How does a Drupal search trigger this outcome?
  
  **Tags:** drupal, search
  
  > **Comments:**
  > **username_1**: I have seen this due to an http vs. https conflict. Don't recall how it was resolved though...  
  > **username_0**: thx - will check if the issue is only happening on https sites  
  > **username_0**: seeing this on sites without https too.  
  > **username_2**: It's reproducible on CiviCRM.org, which suggests that it's not a misconfiguration.  
  > **username_1**: I know it is not explicitly related to https but when I recently enabled it on a site, this started happening again.  I tried changing everything to https AND base_url in drupal+civicrm and have not seen it since (but not holding my breath )  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2015-09-07. Score: 3 | Accepted answer
  
  This can be reproduced on CiviCRM.org, which has both a search block and contribute pages.
  
  1. Go to <https://civicrm.org/civicrm/contribute/transact?reset=1&id=1&action=preview>
  2. Type "ponies" in the Drupal search box (top right)
  3. Hit `ENTER` and see fairly misleading error messages.
  
  [![civicrm search error](https://i.sstatic.net/5rBUB.png)](https://i.sstatic.net/5rBUB.png)
  
  I haven't looked into it in depth, but I'd *guess* something like this:
  
  1. Drupal's Block Search form uses the current page callback to submit its form to.
  2. CiviCRM intercepts form submissions to `/civicrm/*`, but can't handle form submissions in unexpected formats, so doesn't know what to do.
  3. Yellow Page of Malaise. (A play on WSoD here.)
  
  My suggested dodgy workarounds are:
  
  * Add a form alter hook in CiviCRM, which identifies forms you use throughout the site and direct the form submit URLs elsewhere if the path contains `/civicrm`, OR
  * Do not show those blocks on those paths at all.
  
  My wild clever idea solution is:
  
  * Make CiviCRM return Fatal errors using Drupal page callback rather than bombing out to the YPoM. This might permit Drupal to then do whatever redirect happens as part of the normal flow for Drupal forms.
  
  My fantasy perfect solution is:
  
  * Destroy all HTML QuickForm.
  
  This last is happening, albeit slowly. Please [donate to CiviCRM](https://civicrm.org/participate/support-civicrm), avoid implementing new functionality in QuickForm, and support any efforts to remove QuickForm or improve the codebase which you are able to.
  
  
  ---
  
  